George Dinwiddie's blog

There’s been a long discussion on one of the mailing lists about software development process standards. Someone quoted Robert Glass from his essay “A New Way of Looking at Software Productivity” in Software Conflict 2.0: The Art and Science of Software Engineering

Data show that good people do various software tasks 7 to 28 times better than others… Could we, for example, find out what the good people do? And once we found out, could we transfer that technology to others?

Now, I haven’t read this paper, so it’s quite possible that it’s taken out of context.  But it was introduced to me with the question

This sounds like the goal we are trying to do, to discover the most effective way to do something and then enable others to work the same way.  Does anybody disagree with this as the goal?

That sounds so logical, doesn’t it. (Continued)

At the SQE Agile Development Practices (ADP/West) Conference last week in Las Vegas, Yvette Francino interviewed me on the topic of cultural change.  Here is the video of that interview. (Continued)

Brian Marick has written a tantilizing post The Stance of Reaction. In it he says

At this point, Sr. Naveira has at least four reasonable choices. He can step forward, thereby “asking” Srta. Muzzopappa to move backwards. He can step backwards (typically reversing the sweep). He can turn toward her so that they’re facing, causing her to “collect” (bring her feet together). He can take no step at all, but turn his chest to the left, causing her to begin moving counterclockwise around him.

The important thing about Argentine tango (danced recreationally, though perhaps not in a performance like this) is that she does not know which choice he’ll make. She must be balanced in a stance—physical and mental—that allows her to react gracefully to any legitimate move.

I truly hope he’ll expand on this, and how he applies it to the business of software development. I have great admiration for Brian’s intellect and inventiveness. I suspect what he says will help me work on some half-baked ideas I have about effective TDD keeping the code in a state in which it’s prepared to go in any direction, and about Pair Programming being most effective when we work to increase the possibilities open to our partner (a la Improv acting).

So far, Brian seems to be describing the concept of Reaction by saying what it is not–that it is not a reduction to a model. His description of this dichotomy does not match my understanding of how we use models. Online conversation has not clarified my understanding of his description. I suspect that the difficulty stems from us looking at the situation using different models. The appropriate next step seems (to me) to clarify my own model of how models work and are useful to me. (Continued)

Everything should be made as simple as possible, but no simpler. — Albert Einstein

Dave Rooney recently bemoaned on Twitter about how complicated people make things, pointing in particular to a thread on the scrumdevelopment yahoogroup.  It’s a thread that started with a question about a team wanting to adjust the Sprint Backlog in-sprint when something changed about their capacity to complete the work.  From there it spawned a long discussion about various ways to estimate the work and commit to it.

To me, most of these approaches to estimation are more complicated than is necessary.  Some go into detailed calculations that are far more complicated than what most teams do.  I could tell you a really simple technique, but I suspect most teams aren’t ready for extreme simplicity, yet. (Continued)

How long does it take to take a team from where they are to becoming an Agile team?  Of course, that depends on many things, including where they are and how badly they want to succeed at Agile.  It’s reasonable to think they can make a transition in six short months.

If you’d like your team to become Agile, give me a call to find out how I can coach the team to do that for about the same cost as contracting a senior developer.  If your team has already made a transition, but you find that you’re not as effective with Agile as you’d like to be, I can coach using the same framework to help you reach that effectiveness.

On Twitter, Alfonso Guerra (@Huperniketes) asked me, “Okay, tell me how [software] quality will improve by prog[rammer]s taking more resp[onsibility] for quality?” My response is longer than 140 characters, so I’m replying here.

For background, my involvement in the conversation started when he caught my eye with

The problem with the Software Craftsmanship movement is its attempt to create a race of superprogrammers who can save [software] from bad [project management].

Well, I don’t know anyone promoting Software Craftsmanship who thinks that. (Continued)

Tonight, we attended a lecture by Rich Wilson about the 2008-2009 Vendee Globe, a race around the globe by solo sailors in 60 foot overgrown sailing dinghies.  While many sailboat racing talks get rather monotonous, this one was fascinating.  Instead of talking just about boats and gear, Rich spoke mostly of the experience and the people involved.

He offered some advice that I think fits well with software projects:

In a race of four months, going 22 knots for a day doesn’t mean much. It’s just an opportunity to break things. It’s more important to raise the average speed from 10 knots to 11 knots.

This says something about sustainable pace, but it also says something about our tendency to measure ourselves by our peak performance according to some measure.  Let’s face it–we’re only at those peaks for brief moments.

In the normal world of human endeavors, rather than artificial contests, the measure of “best” is never a measure of a single attribute. I would say that the measurement scales for our performance are so numerous and varied that we are never “best” by all of them at once. Perhaps we are not at our peak even for brief moments.

Yet we can always strive. And even when we don’t achieve that which we desire, or that which we think we’re capable of achieving, we may still be doing our “best” under the circumstances. In fact, how could we not?

When I first discovered Extreme Programming a decade ago, I was a software developer wanting to produce the best, and best fitting, software that I could. In those days, it seems that most Agile adoptions were from the bottom up.

Now I find a lot of Agile adoptions are from the top (or, at least, middle) down. Managers have heard about the improved results that companies are achieving using Agile development, and they want some of that for their organizations. That’s not surprising, and it should result in both better results for the organization and better work life for the employees.

Unfortunately, it doesn’t always work out that way. What is it that goes wrong with these top-down Agile transitions? More importantly, how can a well-meaning manager conduct a successful Agile transition? (Continued)

Documentation! It’s what we do.

People approaching Agile software development for the first time often ask about what documents are required.  When I ask developers what annoys them most about other peoples’ code, I frequently get the answer that it’s not documented well.  And I can’t tell you how many times I’ve heard people express the opinion that Agile software development is undisciplined because you “don’t do any documentation.”

Why is documentation so important to us? (Continued)

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. (Continued)