Finding a metaphor in Extreme Programming

It was quite a while since I read the Extreme Programming (XP) mailing list, so perhaps there has been more talk about the concept of the system metaphor in the XP community – but my feeling has been, ever since I began reading about XP and trying to adopt its ideas, that the system metaphor needs to be better understood. Several times I have sensed the opinion that it’s great if you can come up with a good metaphor, but if you can’t, that’s not a disaster.

True, it might not be a disaster: If you ignore the metaphor, something will take its place – namely, the vocabulary the team uses in discussions about the system. Usually (I hope) it is reflected in the code, but it might not be too uncommon for it to be only indirectly reflected in the code, so that you’ll have to translate it from design documents and diagrams. But something will take its place, and it might be good, or it might be bad.

I’m positive, however, that a good metaphor will be of great benefit to the project. I also think that an unconventional (but powerful) metaphor can make work more fun and hence the team more productive (see my post Metaphorical abstraction). The question is, though, how do you come up with a good metaphor?

Readers of XP books, and articles, all know of the “assembly line metaphor” of the primordial XP project. I can’t recall, however, having read about how the team found this metaphor (please tell me if you know) – but I’d guess that what happened was that the team members were discussing the system, and that this image came to someone in a flash. This would explain why nobody has written about how metaphors are found. However, reading Michael Michalko’s Cracking Creativity: The Secrets of Creative Genius, I’ve found a technique that I think has a chance of being very fruitful.

Currently, I’m entertaining myself in spare moments by thinking about what a really great RSS reader would be like. One of the techniques in Cracking Creativity suggests that you pick subjects at random, and try to form connections between them and your problem (or, in this case, the system to be built). The principle is that the mind can’t resist finding commonalities, however unrelated the things seem to be. I have tried juxtaposing several subjects with the problem domain for an RSS reader, and my brain has handed me associations for them all (some more relevant than others): fishing boats, baby gruel, scaffolding, museums.

I found the most interesting of these potential metaphors to be fishing boats. I saw fishing boats going out to sea to catch fish (representing the news items, and the fishing grounds being the different RSS feeds). I don’t want a reader that brings in every unread item of every feed I have subscribed to – I want mouthfuls each time I poll. Also, I want only the choicest fish, so the fishing boats would only bring back as much fish as the fishing quota allows. Not good enough fish would be thrown back into the sea, and the fishermen would continue fishing until the quota is met.

I found this to be a very powerful metaphor. The features I have thought about can be translated into this vocabulary, and it has already suggested new ideas that I hadn’t thought about. Also, I think it would be quite fun to talk about fishing when discussing the evolution of the software.

I think that if I was about to start a new project with a team, I would suggest to my fellow team members to try to find commonalities in things they pass by in the street, see on TV, read about, dream about, etc. Then we would meet and list them on the whiteboard, after which we spend some time with each item to see what ideas we would get. We might not find our metaphor the first try, but if everybody on the team used this technique I think it won’t take too long. I also think this is a suitable exercise at the beginning of a project, as a way to start building the team culture.