January 11, 2006

...Learn TDD with Codemanship

Climbing Mount Improbable

I've been on a bit of a Dawkins binge in the last few weeks. Having read the excellent books The Selfish Gene and The Blind Watchmaker many years ago, I dug out my old copies and re-read them - this time paying a lot more attention.

(Just as an aside, and by an extraordinary coincidence, Richard Dawkins has been presenting a documentary on Channel 4 here in the UK about why it's time we got rid of religion, and started thinking for a change!)

Credit cards are dangerous things, but amazon.co.uk's One-Click ordering feature makes them even deadlier. In just a few seconds I'd ordered the complete set of Dawkins' works and they have been dropping onto my doormat at the rate of about one every 2-3 days. This gives me just enough time to ingest one book before the next arrives.

I've just finished reading Climbing Mount Improbable and a whole bunch of missing jigsaw pieces have suddenly turned up.

High-performing software development teams are so improbable that they surely cannot have formed purely by chance. The mistake of process improvement "creationists" is to believe that the team, and the process, was designed by some unseen hand. Think about it. When we look at a clockwork watch, it's configuration and usefulness is so highly improbable that we can only conclude that it must have been created by some form of intelligence. To take a bunch of metal parts, throw them into a pot and expect a working timepiece to be the result flies in the face of reason - because there are so many billions upon billions of configurations of components that add up to a non-working watch, and just a handful that add up to a watch that tells the time.

And so it is with software development. There are so many ways of giving poor performance that we can only assume that any team that achieves high performance must have been engineered with all the skill and craftsmanship of an experienced watchmaker. These watchmakers call themselves "process consultants" or "methodologists" or "coaches" (among other things). The idea that high-performing teams can emerge spontaneously is severely counterintuitive to a lot of people who are fully indoctrinated in the ways of Linear Management.

The reality is that development teams cannot be engineered in this way. The frightening complexity (well, frightening to some) of any such endevour means that simple cause and effect no longer applies. Sensitivity to initial conditions means that any attempt to tinker with the team is likely to have unpredictable effects. Going faster in software development isn't simply a matter of putting your foot down on the gas pedal.

Complex systems, like development teams, can reach higher levels of performance (or "fitness") through a process of gradual, incremental change called evolution.

In Dawkin's metaphor, we stand at the bottom of a sheer cliff face staring up in wonder at people we can see on the peak of Mount Improbable, wondering just how the hell they got up there. What we can't see is the gentle slope on the other side of the mountain.

Evolutionary Engineering is a more organic approach to shaping the form of complex systems. It works with complexity and can achieve quite improbable results through a gradual series of perfectly probable steps towards the summit. Agile Software Process Improvement is the epitome of evolutionary engineering. How else can we hope to climb Mount Improbable but one small, measured step at a time?

Posted 1 week, 6 days ago on January 11, 2006