Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick

191.8

⇒

167.2

⇒

186.2

183.6

184.0

183.2

184.6

Wed, 09 Jun 2004

Your body is a gross kludge...

... 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.

## Posted at 21:00 in category /misc [permalink] [top]

JUnit Recipes

[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.]

I've been reading J.B. Rainsberger's forthcoming JUnit Recipes. I quite like it. It's something of a patterns book, with problems and solutions embedded in a context.

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":

Suggest providing rituals for people to break out and talk about micro-techniques. For example, a hallway conversation with Nathaniel Talbott at XP/AU shifted into seven people clustered around a table, looking at two variant ways of doing what I'm now calling "coaching tests". Can that stuff be ritualized? (I think of Open Space as a similar kind of ritualization.)

I envision a big room. One side has tables. One side has lots of open space and blank walls. At the tables, people who have micro-techniques to share are sharing them with small groups, who came together because they knew a particular micro-technique would be shown there at that time.

Over in the open space, people are demonstrating "wall as tool" micro-techniques. For example, Norm Kerth might be showing the project energy timeline he uses.

And so forth.

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.

## Posted at 12:49 in category /agile [permalink] [top]