Dials to Eleven

Movements arise in context. For people to gather around a shared social, artistic or aesthetic ideal, they usually need some other social ‘norm’ to distinguish themselves from. Movements are as much about what they’re against as what they’re for.

Now, that context may not be responsible for the birth of the idea, but I think it is responsible for turning someone’s idea into a movement, shared by a number of people.

In the case of Extreme Programming, the process was not ‘created’ by Kent Beck as a reaction to RUP. RUP wasn’t the problem at C3. As far as process is concerned, XP primarily addressed shops with no process. But by defining XP as the anti-RUP, the community turned XP from an idea into a Movement. Giving the idea a concrete enemy, enables people to get behind it and take it to the next level.

Ruby on Rails, another example of a movement in software, was born (so the story goes) from David Hansson’s frustration with PHP. Yet again, however, it’s J2EE that defines Rails as a movement. So, in both cases, a transforming idea comes along to bring more discipline to a chaotic environment - no process, or PHP development. In each case, however, what came to define the technology was the larger, more complex (theoretically more disciplined) approaches to process and software architecture. - RUP and J2EE.

In both cases, I see a lever. RUP has it set full on ceremony and documentation. We know we need to ease back on that, but why pull the lever all the way over the way XP does ? In the case of Rails, surely we can get lighterweight than a full J2EE stack without ditching all of the configuration and flexibility ? Why do we need to go for such a constrained solution as Rails ? Why not Spring ?

What’s interesting about that lever is that it’s spring loaded. If we pull it 90 degrees, it snaps back to 45. When we try and reduce the documentation in our process, if we try and drop 10% we’ll end up with only a 1% reduction, or maybe none at all.

XP understood this and set out to pull the lever all the way over (knowing that it would slip back eventually). By saying ‘all code must be pair-programmed’, it sets an ideal that we’re pretty sure can’t be adhered to all the time, but we set the dials to 11 knowing we might hit 9.

The same hold for Rails. When we take the J2EE stack and try and slim it down, maybe using Spring or something, we still end up with thousands of lines of XML. The only way to really change things is to pull the lever all the way over, set the dials to 11, no configuration, no XML, no flexibility.

The Extreme approach can really change things in a way that the softly-softly approach never will.