Wed, 09 Jun 2004
... so how come it works so much better than your software?
It's a commonplace of software that code should do one thing and do it well. Having heard from my wife (a professor of veterinary medicine) numerous stories of the complexity and interconnectedness of bodily systems, I once asked her if there was any organ that did one thing. She hesitated for a bit, said that the heart is mostly a pump, but then she described some completely unrelated thing the heart participates in.
Fact is, the body is a gross kludge. You'd fire anyone who designed software that way.
My favorite story along those lines is about the kidney. The kidney is a processing pipeline. One stage in the pipeline extracts too much water from the urine. A later stage puts it back in. An obvious question from the do-one-thing-and-do-it-well crowd is "Why not extract the right amount in the first place?" Well, it's probably happenstance. Think about a fish. Getting water isn't a problem. So you can afford to waste it. Then you crawl onto land. All of a sudden, water is a problem. So why not kludge on a stage that puts back the water you formerly wasted? And we all live with the legacy of that addition.
I once wanted to do a keynote-style speech on this topic. It would begin with me ambling up to the stage, facing a few hundred people, smiling genially, and saying "Let's talk about urine." Admit it: it'd catch your attention.
The problem is that I didn't really have anywhere to go after that. The obvious retort is, "Sure, if you can spend millions of years watching failure after failure die, you can make any kind of kludge work, but we have to deliver something next quarter." Which I can't really argue with. But I wish I could. I persist in thinking that maybe there's something interesting about the fact that these fantastically successful systems - bodies - so good at absorbing abuse and coping with change, are not the kind of systems that appeal to us computer people.
[Sorry about the repeat post. My ISP does not seem to have been as good about backups as I might have hoped, so I'm restoring some bits piecemeal.]
One of the things I like about it is the emphasis on micro-techniques. At XP/Agile Universe 2002, Alistair Cockburn gave a keynote in which he said that a lot of the difference between an expert and a mediocrity is that the expert knows a whole host of micro-techniques, little tricks of the trade that add up. It's hard to acquire enough micro-techniques. You can find that mythical perfect project, stuffed full of programmers from a diversity of other projects. Drop yourself into that project, and you'll pick up different micro-techniques from each of them. Or you could bounce from project to project, learning new things in each. (This is the roving consultant's approach. Requires Travel. Lots and Lots of Travel.) Less good - but workable - is to wade through mailing lists, blogs, and wikis, carefully separating the wheat from the chaff. J.B.'s done some - maybe all - of those things and boiled the techniques down nicely into a browseable form.
The other thing I like is the conversational tone. I'm only a half-good programmer, but I do spend time with good programmers. There exists a programmer's community of practice, a community that builds identity and examplars of good behavior through conversation about work - conversations usually held in break rooms, lunch rooms, blogs, and the like. A lot of programmers are not part of that conversation, and it shows. J.B.'s book, I think, does a nice job of introducing such programmers to "the community givens" without making a lecture of it. They'll learn a lot of design and Agile lore if they study the book. Will they? Dunno. Hope so - hope they're seduced into it by the problem-focused recipe format.
P.S. For the first Agile Development Conference, I proposed a "Micro-Techniques Faire":
Nothing came of that, and I rather suspect I'll be too busy at both Agile conferences this summer to organize any such thing under the auspices of Open Space. So anyone intrigued by the idea should take it and run with it, this year or next.