I’ve been on the go quite a bit the last couple months, and my posting here (or lack thereof) bears witness to that.  I’ve had lots of thoughts too share, but little time and energy to put them into words.

These hurried times included a trip to France, and one of the highlights was visiting the Paris Coding Dojo, the origin of the term.  What an enjoyable evening!  No trip to Paris would be complete without it.  (Well, maybe that’s not true for everyone.)

The short version of the story is that the coding dojo takes a little bit of time to thoughtfully examine our craft and the way we practice it.  The comments made during the dojo were a reflection of the importance that small nuances have in the pursuit of effective programming.  I advise everyone in the software development community to find ways to hone their craft outside of the daily grind of delivering work.

And many thanks to the participants of the Paris Coding Dojo for conducting the meeting principally in English for my benefit.

Bob Payne has release another of our conversations.  This one take off from my post, 3 Legs to Standing Up an Agile Project.  This is your opportunity to hear Bob’s thoughts on these ideas.

Ooh, it’s got some stuff about including UX specialists in the development process. I’d forgotten talking about that.

This article on InfoQ bothers me.  It seems to draw only from Dave Nicolette’s blog post and the subsequent comments.  Dave’s post is similar, in my mind, to a trip report that someone might give to an organization after a class or conference.  He goes into some detail about what happened at the first ever Certified Scrum Developer course, and muses about what he learned.  The bulk of the comments are an interchange between Dave and Tobias Mayer where, it appears to me, Tobias doesn’t think that the course comes up to the standard of the CSM course.  This is, of course, based on Dave’s description, as Tobias wasn’t present at the course.

The InfoQ article mentions me by name, but doesn’t mention other participants other than Dave.  It also misquotes Dave [now edited without any indication of doing so], and implies that the learnings that Dave got out of our retrospective conversation after the course was a list agreed upon by both of us.  There was apparently no fact checking done on this article.  Certainly no one spoke with Ron Jeffries or with me about it.  I find the article misleading enough that I need to respond.

I had planned to write about the course, but this isn’t the article I’d planned.

On Twitter, [a person who now wishes to be anonymous] took exception to Ron Jeffries’ comments on InfoQ and on Twitter about the article failing basic tenets of journalism.  [He] is an editor at InfoQ, but thinks that he (and Vikas) are not journalists.  Ryan Slobojan, Chief Editor at InfoQ, expressed a similar opinion in an email to me.

I have no formal training as an editor, I’m not a journalist, and before I became Chief Editor in August 2009 I was doing it on the side in addition to my full-time job – this is a common pattern for all of our editors, and it’s how we end up with a diverse team of experts from (literally) all over the world.

I have important information for both [Anonymous] and Ryan.  They are journalists, whether they have trained to be, or think of themselves as journalists, or not.  They are participating in the business of “the collection and editing of news for presentation through the media.”  The fact that they do not realize that’s what they do, that they have not trained themselves in the basics of journalism, and that they sometimes do it badly, doesn’t change the fact that they are journalists.

In a way, that brings us full-circle on the developer training/certification/craftsmanship issue.  It’s not only developers that can benefit from a certification class to give them some basic knowledge.  When Ron mentioned “Journalism 101″ he was talking about that very thing.  Neither Ron (I checked my facts) nor I have a degree or certificate in journalism.  Clearly, though, we both think that there are some journalistic standards that should be observed.

The difference between our viewpoint and that of [Anonymous] and Ryan reminded me of Jerry Weinberg’s classification of software development organization cultures (taken from page 9 of Quality Software Management: First Order Measurement)

0. Oblivious: “We don’t even know that we’re performing a process.”
1. Variable: “We do whatever we feel like at the moment.”
2. Routine: “We follow our routines (except when we panic).”
3. Steering: “We choose among our routines by the results they produce.”
4. Anticipating: “We establish routines based on our past experience with them.”
5. Congruent: “Everyone is involved in improving everything all the time.”

It occurs to me that these same levels can be applied to individual software developers, to journalists, and to publishers.  [Anonymous] and Ryan are journalists at level 0; they don’t know they’re performing journalism.  I’m perhaps at level 1 or 2 in journalism.  Perhaps that’s enough for the depth of my involvement with journalism.

Software developers sometime do not realize that’s what they are, also.  Consider the case of the businessman who tweaks his spreadsheet.  He’s writing software, but doesn’t think of it that way.

In Ron and Chet’s CSD class premier, I would expect that everyone who participated generally operates at level 4 or 5.  Even such knowledgeable and experienced practitioners, however, can panic under time pressure. It takes time to calmly evaluate a situation and make a decision.  It takes more time to do so as a team.  If you fail to take that time, your decisions will suffer from the lack of evaluating enough of the situation.  I think that’s one of the many things that was going on in that class.

As I said, this is not the article I’d intended to post about the class.  That article will have to be written another day.  I think this one has some value, too–value far beyond the disclaimer that Vikas Hazrati’s article is not a valid representation of the CSD class.

I’ll still try to find the time to write that article.  In the mean time, if you’re writing software, I think you’ll find value in the CSD class.  If you’re reporting the news, I think you’ll find value in learning a little about journalism.

I recently wrote on The Importance of Precise Estimates.  This is a related topic.

Mark Levison called my attention to an article by Michael Hugos subtitled ‘Agile projects require more planning and coordinating than waterfall projects‘ on CIO.com.  In this article he advocates answering the question, “Has the scope of any project task changed?” at every daily standup.  He uses this information to update a detailed Gantt chart to provide to senior management.  In Michael’s words,

It also gives senior managers who are not on the project (but who are still ultimately responsible for what happens) the information they need to feel comfortable. And that saves project team members from being distracted by endless management questions and misplaced advice (and nothing kills agility faster than endless management questions and misplaced advice…).

Michael, in LOLspeak, “Ur doin it wrong.”

You’d do well to review Hubert Smit’s presentation on Five Levels of Agile Planning.

A Gantt chart is way too much work to keep up to date with such volatile and detailed data.  I suggest using a burn-up chart, instead.  Developer tasks is way too detailed a view for senior management.  Steering the company requires a higher level view.  A task level view by senior management invites the very micromanagement Michael fears, and suggests that middle management isn’t doing useful work.  If middle management is tracking individual tasks at a daily level, then they are also micromanaging, and destroying the development team’s ability to self-organize.

For Agile development to work, you have to delegate appropriate levels of organization to the people doing work at that level.  You have to treat people as living, thinking beings–not just a pair of hands to do your bidding.  It’s not a means to drive them harder, squeezing the slack out their days.

The good news is that letting people organize their own tasks frees you to look at a bigger picture.  You can track if and when a project is going astray much more easily that way, than you can by presuming you’re the only person who knows all the tasks that need to be done, in what order, and by whom.

A while back, I wrote 3 Legs to Standing Up an Agile Project from the perspective of an Agile team just getting started.  Lately, I’ve been thinking about the same sort of thing, but from the perspective of a coach or an executive that wants to transform the organization.  At first glance, this seems no different. Further reflection, however, reveals that this is less about “how to work in an Agile fashion” and more about “how to introduce change in the way people work.”  The earlier post was a description what an Agile project needs.  This one is a recipe for creating what an Agile project needs.

Teamwork

The fundamental practice of teamwork remains essential.  Agile succeeds in large part by reducing wasted effort, and much wasted effort is the result of various people pulling in different directions.  Even slightly different directions will create enough friction to noticeably slow the project.  It’s well worth spending some time and effort on building an effective team within the context of the project.  The two practices most essential for supporting teamwork in an Agile transition are working with a whole team in a common area.

Whole Team

While collaborative teamwork among all the developers, for example, is beneficial to any project, it’s not enough to accomplish a transition to Agile.  At a core, you’ll need high-bandwidth collaboration between your Product Owner, Scrummaster, and Developers.  This is the minimum, in Scrum terms.  In most organizations, Developers really includes both programmers and testers; in some it includes user experience designers.  Yours may include people with other titles, such as architect, database administrator, security officer, system administrator, operations engineer, technical writer….

Your project community will also consist of other stakeholders, such as executives, customers, end users, support personnel, other development teams, facilities maintenance…. There are a lot of people with interest in the project or the things that the project team is doing.

The boundary between the core team and the rest of the project community is rarely distinct.  One useful distinction is whether a person is focused principally on the project, or whether the project is just one of many things with which the person is concerned.  This distinction is not without peril, however.

All too often an organization will assign multiple projects to people where it would be much better if they were focused on one.  If you give your Product Owner, your programmers, or your testers multiple simultaneous projects, you’re likely headed for trouble.  You may be headed for trouble if you multi-task in some of the other specialties, but there’s more variation from one context to another.  As a rule of thumb, if there is any way to let someone focus on only one project, then you should do so.

Common Area

Building a team, which is different from a mere work group, takes a lot of work.  With skill, you can facilitate that teambuilding to help it happen more reliably and a little faster.  If you don’t have a skilled facilitator, though, you’re still in luck.  People have practiced self-organizing into small groups for their common good for millennia. If they’re working together for a common goal in a common area, distinct from those working on other goals, they’ll likely build a gelled team without an outside facilitator.  There are many reasons for this, from trust building to osmotic communication.

“But we can’t do that,” I hear you cry!  Why not?  Is this project, this Agile transition, so unimportant that you can’t sit together?

“Our Product Owner has an office elsewhere, and needs to attend to other things.” Maybe you’ve chosen the wrong product owner.  Maybe the Product Owner can sit in the team room for part of the day.

“Our project team is scattered around the globe.”  Don’t do that.  While it’s possible for people scattered around the globe to work together, it’s much harder.  The odds of making that work while also making an Agile transition are slim to none.  If you must do distributed projects, set up a collocated team at each location and minimize the working dependencies between the teams.

“We don’t have a space that supports that.”  Find or make one.  Move furniture.  Take down cube walls.  Set up temporary or movable partitions.  If the furniture arrangement is more important than the project, consider canceling the project.

Visible Progress

In order to see whether or not we’re headed toward our goals, we need visibility into the progress.  Usually, this boils down to the questions “Are we going to get everything done?” and “Are we going to get done in time?”  If the answer to one or more of these questions is “no” then we can make adjustments to how we’re doing things, how much (and which things) we expect to get done, and what time we expect to have them done.  We can subdivide this visibility into two simple practices: taking baby steps and getting things done.

Baby Steps

Everything we do, from releasing interim versions down to validating the code we write, we should do in small steps.  Working in small steps gives us a much finer-grained view of the progress.  It lets us view the initial trends sooner.  It lets us view changes in the trends sooner.  It gives us more opportunities to make corrections or course changes.  It gives us more practice and comparing where we’re going with where we want to go, so we get better at doing that.  It requires less work before we see that we’re doing something wrong, or doing the wrong thing, therefore there is less work to be thrown away and redone.

Done

There’s little point in measuring something as progress unless we know that it actually contributes toward reaching our goal.  Measuring amount of work done doesn’t tell us that.  Consider this scene from the movie, Captain Ron:

Captain Ron: We should be okay. ‘Cause I know we’re near land.
Martin Harvey: Great, Cap. Great. Ya hear that? We’re almost there. Explain to the kids how you know that, Captain Ron. Someone translate for General Armando.
Captain Ron: Alright, now stay with me: When we left, we had just enough fuel to make it to San Juan. And we are out of fuel.

The gap in that logic is immediately obvious, but plan-driven projects attempt the equivalent all the time. We must measure relative to the goal, not relative to the path we’ve taken.

It’s important that we measure functional slices. It’s often tempting to measure tasks that have been accomplished. Sometimes, however, these tasks turn out to be unnecessary, and they don’t contribute to accomplishing the goal.  Sometimes, while they look right in isolation, they turn out to have flaws when we look at the bigger picture.  Sometimes they don’t quite meet with other tasks, and there is a gap to be filled between the tasks.  Such a gap in unknown undoneness.

We need ways of seeing progress that won’t like to us about how much progress we’ve made, or how much is left to do.  We want to measure functional slices that go all the way through the system.  It’s easy to neglect some of the things that people think of “someone else’s responsibility” after the system is “complete.”  These things might include an installation procedure, or deployment to a different computing environment.  Sometimes people neglect something so basic as testing that the system works.

We want to see functional progress–something we can demonstrate and test, something we know is desirable.  Expending the amount allotted is not such an indication.  Getting most of the way to the goal is no guarantee that we’ll get the rest of the way there–particularly when the remaining part is fundamentally different than what we’ve been doing.  We want to always, or at least at frequent intervals, be able to stop and have something that can be used, even if incomplete.

Putting these together can be difficult for a team making a transition to Agile.  It’s hard enough to get everything working, but much more so when you’re having to do that all the time.

Fortunately there are a lot of well-known engineering practices to support combining baby steps with getting to done at each step.  I’m starting with the assumption that the team is already capable of creating working software using whatever techniques they already know.  Eventually they’ll need to learn other practices to support this new way of working, and even to get better in general.

Continuous Improvement

Being able to work as a team and measure progress in a visible manner is only the start.  At first, we’ll do these things in a rather rough manner.  As the system grows in size and complexity, that rough manner won’t sustain forward progress.  We’ve got to get better in order to keep moving.

And there’s no limit to how good we can get.  No matter how practiced we are, there’s further improvement we can make.  If we conscientiously practice our techniques, we’ll see places where we can improve them.  We can then practice those improvements, so they become a part of our routine, and we do them even when distracted by the latest disaster.  When things go wrong, it’s no time to ease off on the practices that make us more effective.

As a team, we need to take stock from time to time to see the longer term trends, both good and bad, and the issues that only become visible in retrospect.  Holding retrospectives at various tempos–each iteration, each quarter, each release–will give us various views into what we’re doing, and result in different insights.  We must use these insights to plan ways in which to improve in the future.

From these starting points of teamwork and visible progress, and proceeding with a program of continuous improvement, we can learn all of the practices that support Agile development.

Grabbing a handful of wet, saturated sand, I let it dribble through my finger tips.  I watch each drop pile on top of the previous, draining away the water and leaving a new building block of solid sand.  Too much water and the previous drip will be washed away.  Too little and the sand cracks and refuses to hold together.  I watch the sand grow, getting into a rhythm that ensures just the right amount of water, without thought.

My thoughts are not on the mechanics of building a drip castle with sand.  Instead, I’m thinking of the spire that I’m building.  Can I build these two spires toward each other and form an arch?  Can I make this slender spire taller?

Frequently I fail and a part of the castle slides down, becoming part of the landscape again.  Or becoming a foundation for a new part of the castle.  No matter.  It’s the building of the castle that brings me joy–not the owning of it.  For I will never own it.  The sea soon comes and takes it away.

Last weekend, I drove six hours down to Floyd, Virginia for a Code Retreat organized by Gustin Prudner and led by Corey Haines.  There, I joined thirty-some people working in pairs and threes on Conway’s Game of Life for forty-five minutes at a time.  Then, Corey would call time, and we would wash away all traces of what we’d built.

Does that sound like a waste of time?

It wasn’t, for we weren’t building code.  We were building castles.

We weren’t concerned with completing the program, any more than I’d be concerned with completing a sandcastle before the sea washes it away.  Instead, we were paying attention to how it went together.  We were noticing how the small choices we made affected the structure that resulted.  How the structure made it easier, or not, to build to greater heights.

In my pairs and triplets, I started differently each time.  Let’s organize around the cell, and see where that leads us.  Now, start with the playing board–a grid of locations.  Then with the relationship of neighborhood.  In each case, writing a simple expectation of that object, implementing it, repeating, simplifying, making the intent and responsibilities clear, lead to a unique castle of code.  We were not so much writing tests and code, as thinking about the problem and expressing those thoughts directly in tests and code.

I noticed that by emphasizing what we were doing, rather than how we were doing it, gave us simpler, more malleable, and more robust code than we might get if we were trying to “get it done.”  The awareness of the ephemeral nature of what we were creating freed us from mere concern over the construction–resulting in a construction better suited for an enduring achievement.

It’s a marvel that I’m still pondering.

And while we repeatedly build these fleeting castles of code, I noticed many other things.  I noticed how easy it was to share ideas by typing them as code.  I noticed how one choice affected the next.  I noticed that when my thoughts became muddled, it was easier to back up to a point of clarity and start forward again.  I noticed the joy of working together with others, fully engaged in the same endeavor.

While all the code has been washed away, the way I felt and the things I learned remain.

Thanks to all of you at Code Retreat Floyd.  My future work will be better for having shared this weekend with you.

In my recent posting on estimation precision, I briefly mentioned how you can estimate when certain features will be done, or estimate what features will be done by a given date, using a burn-up chart.  Some people don’t find this an obvious and easy thing to do.  Let me explain in more detail.

I’ll start with the assumption that you have a list of features you want to add to an application.  Some of the things you want to add may not be properly called features–they might be bug fixes, for example.  And the application might be brand-new, with zero functionality so far.  That’s OK, we can handle cases like that.  Let’s walk through how I do this…Here we see a burnup chart showing the development of the first feature of a project. This “Feature 1″ took the team 4 iterations to complete.

Now we want to develop “Feature 2.”  Is it about the same size as Feature 1? Bigger? Smaller? It’s really hard to say, isn’t it?

We could head down the path of precision estimates, looking at the detail of the work to implement Feature 1 and the imagined detail of the work to implement Feature 2.  We could measure the person-hours spent on Feature 1, and apply adjustments for sick day, holidays, planned hiring, and a myriad of other factors.  I find that such an approach not only doesn’t help me answer the questions I have, it distracts me from them.

Instead, I like to estimate features in “T-shirt sizes.” A simple range of small, medium, large, and extra-large is “close enough.”

When we’re just starting out on a new project, we don’t have enough information to make wise choices. So let’s make quick ones.  I’m going to call Feature 1 a “medium” feature.  Given the lack of detail about Feature 2, let’s call it “medium” also.

So we project another increment of work, the same size, accomplished at the same rate. Surprise, surprise, surprise! We project it will take another 4 iterations.  We didn’t need a burnup chart to tell us that.

Pessimism

It’s also likely that we don’t really believe this projection. Sure, it’s the best information we have at the moment, given that we know so little, but it seems prudent to explore the “what ifs” a little.  What if the feature is really 50% bigger?  What if the team is slower this time around?

Yikes! Now we’re looking at 10 iterations as a pessimistic estimate.

Optimism and the Zone of Probability

What if the Feature 2 turns out to be smaller than Feature 1? And the team is more productive because they’ve got some momentum as a team?

Our most optimistic estimate suggests that we’ll only take 2 iterations to implement Feature 2. By extending both our feature size and our team velocity estimates, we see the bounds of the Zone of Probability.

A range of 2 iterations to 10 iterations is a pretty wide variation. We’ve got such a large variation because our uncertainties are large with regard to both the size of the feature and the capacity of the team.  We have these large uncertainties because we’re extrapolating from a single data point–the time it took this team to produce Feature 1.

In time, we’ll have more data and can reduce the range of our uncertainty.  (Or the data will show that we really are that uncertain in our delivery.  Delivering at a more reliable pace is a topic for another day.)  If you want more predictability, sooner, then work in smaller chunks.  If the features are smaller, then the picture comes into focus much more quickly.

For now, I’ll leave it as an exercise for the reader

• how to handle Feature 3 and beyond
• how to handle features of different sizes
• how to sort a large stack of planned features into buckets for different sizes
• how to handle uncertainty in size when projecting further into the future

and other such issues.  If you have any questions, don’t hesitate to ask.

We’ve got a rather old bathroom scale. I’ve found advertisements for this model ranging from 1949 to 1954.  My wife inherited it from her mother.  When we first got it, we set the “zero” weight to three pounds to give the “correct” weight.  Now it’s set closer to five pounds when nothing is on it.

The readings it gives are a little inconsistent.  When you bounce lightly up and down, you may get a different reading.  (I tend to take the smallest number I can get.)

My weight seems to vary from day to day, also.  Some days I eat more.  Some days my body seems to be bloated with water.  I’m up two pounds one day and down two the next.  This can happen within a day, also, prompting my wife to warn me, “Never weigh yourself in the evening.”

We’ve talked about getting a new scale.  I almost did, once.  But this one works pretty well, all things considered.  It’s good enough for me to “watch my figure” as the advertisements put it.  I don’t need to “know right away” if I gain or lose a pound.  There’s that much noise in the data, and precise measurements won’t take it out.

In fact, knowing that the measurement is imprecise makes me worry less about the small variances.  I don’t try to calculate the percent gained or lost in a day.  Instead, I just watch the trends.  And this scale is great for that.

Recently I was talking with a client who wanted to estimate what functionality his team could release within the next 18 months.  He was concerned that they were only estimating stories for the next iteration.  I showed him how you stack the features on the vertical axis of a burn up chart, graph the features already done, and eyeball what could be included in the next 18 months.  In fact, if you wanted to, you could indicate the potential size range of a feature, and plot both a slow and fast development rate, giving an approximate trapezoid of possibility.

He wanted a mathematical calculation. <sigh/>  You can do that, of course.  You can convert everything to numbers.  You can apply adjustment factors and confidence percentages.  And you can calculate some very precise numbers.  You can recalculate them daily and worry over small changes in those numbers.

But what does it change?

The estimation of the size of the work, even after it’s done, is a guess.  The measurement of progress is fraught with inaccuracies and unknowns.  This means that any precise number you calculate from your estimates is still a guess.

Why spend all that effort?  A precise guess is of no more use than a rough idea.  Maybe less, because the rough idea makes it plain that these results are just the best guess we have at the moment.  Precise numbers have a way of hypnotizing you into thinking you know.

My advice is to

• measure your progress
• watch the trends
• project the trends tentatively into the future

and relax.  It’ll work out the best it can.  False precision won’t make it any better.

Some of the smartest people I know are ranting that certification doesn’t prove the person is worthy.  Well, of course it doesn’t.  No certification does that.

It only says you’ve met the requirements for the certificate.

Of course, they really know that.  So I don’t know why they’re making such a fuss.

A number of them have made public statements that they discriminate against people who hold certifications.  That really saddens me.

It’s true that I’ve found a pretty strong inverse correlation between collecting certifications and ability to do the work. I’m not sure I ever found a job applicant with Certified Java Programmer on their resume who passed muster when I asked them to write some code.  I am sure that I gave everyone an equal chance.

The skills to do well at collecting certifications and the skills to do well at the work are different things.  But having a certification is no indication of incompetence.  I have a CSM certification.  I also have an MS in Computer Science.  I don’t make a big deal of either one, and the classes I took for them pale in comparision to all the other things I’ve learned.  But I also learned valuable things while qualifying for both of those certifications.

I don’t collect certificates, but I do have a few.  I got the MSCS to give me credentials for work I was already doing.  Sometimes it counted against me in job interviews that my degree was in English.

Well, I’m here to tell you today that things I learned getting that English degree have been a great help in my career of software development.  There’s more similarity between a good essay and a good program than you might imagine.

And while neither my MSCS nor my CSM have opened any doors for me to my knowledge, neither should they count against me.  I implore my bigoted friends who see certification as a blot on a person’s character to reconsider.

On Twitter, my good friend Mike Sutton said, “CSD is a misnomer. The value of existing Certifications needs to be justified before new ones are released.”

Many of the terms we use are misnomers.  For example, “acceptance testing” is a misnomer because it doesn’t indicate acceptance if the tests pasts–it indicates lack of acceptance if the tests fail.

What is the misnomer in the phrase “certified scrum developer?”  I can’t really tell, because the phrase is so ambiguous.  Developer, in this usage, means “software developer.”  Scrum is referring to a particular “product or system development framework.”  Certified means “received a certificate.”  There’s not much overlap between these concepts, though, so the combination takes more explanation.  The phrase itself does not communicate a clear concept from one person to another.  The debate over the phrase has proved that point.

“Wait a minute,” you say, “Certified means more than ‘received a certificate!’”

Then what does “certified” mean to you?  It seems to carry different connotations for different people.

Well, what’s the denotation?  I looked it up in the dictionary:

certified
Function: adjective
Date: 1611
1 : having earned certification <a certified gemologist>
2 : genuine, authentic <a certified big shot> <certified intellectuals>

Looking up certification takes us in a circle, leading right back to certified.  I also looked at certify, certifying, and certificate.  They all come from the Latin certificare which derives from the earlier certus which means “certain.”  The general gist of all of these is

to attest authoritatively, usually in a written statement, and especially one carrying a signature or seal.

But what is being attested and by whom?

One example of certification that frequently comes to mind is that of doctors.  Note that certification of doctors is different from a medical license, though the granting of a medical license may require certification.  Graduating from medical school (or any school) is a certification and they generally give you a nice diploma (a certificate) as tangible evidence that you’ve met their requirements.  There are other certificate programs that attest to education, practice, and testing beyond that of a medical license examination.  Clearly some certificates are backed by years of study, supervised practice, rigorous examinations, and have the force of law requiring them.

But what about that “certified gemologist” in the dictionary definition?  That’s a certificate offered by the American Gem Society, a non-profit trade association promoting competence and ethics in the jewelry industry.  That’s good stuff, right?  Membership in the American Gem Society also requires that “at least one full-time employee who has studied and completed an Accredited or Graduate Program from the [Gemological Institute of America] or Gemological Association of Great Britain.”  Seems they’re open to charges similar to the Scrum Alliance, that it’s a grab for tuition dollars rather than a sincere desire for improving the marketplace for jewelry.

In truth, any attempt to create a program to differentiate practitioners of whom you approve from ones you consider unscrupulous charlatans is a blend of both altruism and self-interest.

And then there are “diploma mills” that skip faking competence at the practice, and go right to faking competence at teaching and evaluating.  There are already organizations in the field of software development that I suspect might fall into this category, at least, by my standards.  And I don’t know any way to prevent them from doing so.  I would certainly hate for governments to start issuing licenses to write code and regulating whose certification was allowed.

Instead, I’d like for people to make their own judgments.  Instead of blindly trusting someone to be competent because they hold a certification, I’d like them to consider who is behind that certification and what are they certifying.  I’d also like them to consider that instead of blindly distrusting someone because they hold a certification.  And since the number of available certifications cannot be held to zero, I think the best way to get people to give such consideration is by having the number of available certifications greater than one.

In any even, it’s not the certificate that matters.  That’s just a tangible token.  It’s what’s behind it.  If what’s behind it is only that they attended a two or three day class with a reasonably good instructor, and that instructor thought they showed some understanding of the material, then that has some value to me.  In fact, it has more value to me than certifications that someone has passed a test showing they’ve memorized a lot of detail about the Java library.

Like a story card, the certificate is an invitation for a conversation.  “Where did you get that certificate?  Who was the instructor?  What was the course like?  What did you get out of it?”  In that regard, a course taught by Ron and Chet would carry some weight with me, because I know and respect Ron and Chet.  A certification has no more value than the signature or seal making the assertion.  I could look at the material the course covered and evaluate that coverage using the catalog of the Agile Skills Project.  But most importantly, asking “What did you get out of it?” and listening to the response will tell me a lot about their engagement and what they consider important.

And isn’t that what’s important when evaluating an unknown developer?

A recent post on the scrumdevelopment yahoogroup got me thinking about the age-old problems of distributed software development.  The author of the post described having a Product Owner in California, developers in CA, TX, NC, & India, and QA in India.  (No mention if all of the workers in India were in the same place.)  I’m not picking on this individual.  I’ve heard similar stories many times.

It reminded me of something I’d read in Martin Fowler’s book, Patterns of Enterprise Architecture.  On page 88, figure 7.1 shows a common but distressing architectural design of distributed objects.  In the diagram, the components for Invoice, Customer, Order, and Delivery are each deployed to separate machines.  Why do it this way?

• Because the vendor said you could.
• Because you think it can scale by adding more hardware to a component that’s overloaded.

Martin points out that such a design “will usually cripple performance, make the system much harder to build and deploy, or, usually, do both.”

The primary reason that the distrubution by class model doesn’t work has to do with a very fundamental fact of computers.  A procedure call within a process is very, very fast.  A procedure call between two separate processes is orders of magnitude slower.  Make that a process running on another machine and you can add another order of magnitude or two, depending on the network topography involved.

As a result, the interface for an object to be used remotely must be different from that for an object used locally within the same process.

The same, and more, are true of human interactions.   Ken Crow reports, “a study in 1977, researching the effect of distance on technical communication, found that the probability of communication rapidly decreases within the first ten meters.”  The notice for the CSCW 2008 Workshop on Supporting Distributed Team Work says,

It doesn’t take much distance before a team feels the negative effects of distribution – the effectiveness of collaboration degrades rapidly with physical distance. People located closer in a building are more likely to collaborate (Kraut, Egido & Galegher 1990). Even at short distances, 3 feet vs. 20 feet, there is an effect (Sensenig & Reed 1972). A distance of 100 feet may be no better than several miles (Allen 1977).

Can your software development team stand such a drag on interpersonal communication?

That’s not to say that you can’t get anything done with a distributed group of people.  A small group of motivated people can overcome huge barriers, and they will because they want to do so.

The point is that if you’re organizing work for a group of people large enough that there seem to be economies to spreading the work around the globe, then spreading the work by task or skill set is not the best form of distribution.  And it’s an order of magnitude less desirable if you have any hopes of agility.

Agile software development gains much of its advantages from improved communications between the people specifying the software, the people developing the software, and the people checking that the software is as specified.  These people need to communicate a lot if they are to stay in sync.  If they have to write things down to communicate, it’s going to go a lot slower and the communication will happen in bigger chunks, with less opportunity for clarification.  Talking daily, face to face, offers a much higher communication bandwidth.  It allows for non-verbal confirmation of the spoken word, and non-verbal clues that the spoken word has been misinterpreted.  Working together in a team room ups this bandwidth by a couple more orders of magnitude.  You can ask a question the moment it occurs to you, and get an immediate response.  You can validate your understanding of each sentence of that response, if that’s what you need.

If I have an address class, a good interface will have separate methods for getting the city, getting the state, setting the city, setting the state, and so forth.  A fine-grained interface is good because it follows the general [Object Oriented] principle of lots of little pieces that can be combined and overridden in various ways to extend the design into the future.

A fine-grained interface doesn’t work well when it’s remote.  When method calls are slow, you want to obtain or update the city, state, and zip in one call rather than three.  The resulting interface is coarse-grained, designed not for flexibility and extendibility but for minimizing calls.  Here you’ll see an interface along the lines of get-address details and update-address details.  It’s much more awkward to program to, but for performance you need to have it.

See how Martin Fowler’s description of system design mirrors the communications design of a software development team?  So what does he recommend?

In most cases the way to go is clustering.  Put all the classes into a single process and then run multiple copies of that process on the various nodes.  That way each process uses local calls to get the job done and thus does things faster.  You can also use fine-grained interfaces for all the classes within the process and thus get better maintainability with a simpler programming model.

The analog for people is to create a team at each location, complete with specifiers, developers and testers.  A common way of doing this when they’re all working on one system is to have feature teams.  Each team works on a single feature.  Of course there still may be some overlap in the code the feature teams have to modify, but this is a much smaller communication need than between developers working on the same feature.  Development teams are smart, and they can figure out how to work together.  Creating a continuous integration between the work of the teams can help identify problems early, when they can be fixed with minimal effort.

Give your teams a fighting chance.  Make them as cohesive as possible and reduce the need for coupling between them.