There's no comparison

XP Day 2008. XP Day isn't really about XP any more - it's about whatever the people that go every year are currently obsessed with. On this occasion, that seemed to be two topics. One was that old favourite, how shall we know good code when we see it? Not much to say about that except that I was pleased to find lots of other people in the middle of Bob Martin's "Clean Code", which is focused thereabouts.

The other obsession was lean thinking. This is one of those myriad attempts to improve software practice by copying something that worked somewhere else. In this case, Toyota came up with a bunch of practices that helped them to make cars more cheaply in the immediate post-war era. I mentioned this over the weekend to a friend whose job consists of trying to make various car factories run more efficiently. As you might expect, he knows a lot about value streams, kanbans, and the rest of this stuff, and he immediately came back with "but what has all that got to do with software?".

I was reminded of an OOPSLA in the late nineties. At that time, pattern languages were all the vogue, and Chris Alexander - the architect who invented pattern languages to capture architectural knowledge - had been invited to give the keynote. He shambled on stage, and expressed himself vaguely bemused to be there. Why would you all be interested in something designed for use with architecture? he asked us.

It seems to me that we do this a lot in software. Apart from lean thinking and architecture, other past efforts have included the SEI models (one of many other attempts to compare software with manufacturing), making movies, mountaineering, oil exploration, collaborative game playing, building buildings, and plenty more besides.

These can be sources of entertainment. I've spent some happy hours annoying movie-making friends by trying to make comparisons. But mostly, I don't think these analogies help much with the goal of getting better at writing software.

Years ago I saw Bertrand Meyer give a talk in which he said that the significance of a piece of advice was inversely linked to the plausibility of the opposite. If someone advises you to choose readable variable names, that's not advice: you were unlikely to make an effort to choose unreadable names. On the other hand, if you're advised to "choose names that express what is to be done rather than how" then you have real advice, because it's not immediately obvious that "how" is the wrong answer.

Much of the advice that comes from these analogies seems to me to fail the Meyer test. I was initially taken by someone talking at XP Day about applying the principles of lean applied to software. One outcome was the notion of not having any more than a small number of tasks on the go at once. But then I took a step back to consider the alternative. Deliberately strive to do lots of things at once? Was I about to do that? About the best you can say is that this changes the emphasis, but then you have to wonder, away from what?

Other debates about the management process had this same unsatisfactory feel. Reminders of lots of common sense stuff, but nothing that might change your practice. Breakthroughs in software development - the move from waterfall to iterative, for example - I don't think come from analogies. All the "good stuff" for me at XP Day happened where the topic under discussion was software development, in and of itself. I sat for an hour in an open space discussion about what makes software programs easy to read. I came away with some genuinely useful insights that will make me do something different in future. From here on in, I think I'm going to try and get better at software by doing and talking about software.