TITLE: Agile Moments: Metaphor as Practice, Metaphors for Practices AUTHOR: Eugene Wallingford DATE: August 04, 2010 2:58 PM DESC: ----- BODY: In the last few weeks, I've seen a few interesting metaphors related to agile development. Surprisingly, one of them was actually a metaphor, XP-style. The Mute Button Like many newcomers to XP, my students tend not to get the reason that "metaphor" was one of the original XP practices. I try to give examples that I've seen, but my set of examples is too small. That's one reason I was excited when some agile practitioners in industry created a new discussion list on metaphor in software. Joshua Kerievsky posted a link to a blog entry he had written about two metaphors that have helped him recently. In one case, his company has started using the idea of a playlist for the products it sells, instead a book. In the other, which is the main theme of his entry, he extrapolates from the presence of a "mute" feature in the Twitter client Twittelator to a riff on thinking about Twitter as if it were television. There are some interesting similarities, as well as interesting differences. But it's a good example of how a salient metaphor can be a source of common experience for guiding the design of a software system. Refactoring "Technical Debt" A few months back, I wrote an entry on technical debt, suggesting that some technical debt might be okay to carry, so long as we incur it for investment, not consumption. Not everyone believes this, of course. I've been heartened by Kent Beck's writing over the last couple of years about his own questioning of when we might break our own rules, at least the rules as they have been calcified over time or hardened against the challenges of skeptical audiences. Last month, Steve Freeman proposed a new picture of bad code: it isn't technical debt; it's an unhedged call option. This metaphor highlights the risk we run when we allow bad code to remain in the build. My metaphor's willingness to carry debt for investment implies a risk, too, because some investments fail deliver as hoped. Freeman's metaphor raises this risk to a more dangerous level. I like his story and think it applies quite nicely in many contexts. Still, I'm willing to accept lower quality code in trade for something of greater value now -- as long as I keep my eye on the balance sheet and remain vigilant about the debt load I carry. If the load begins to creep higher, or if I begin to spend too many resources servicing the debt, then I want to clean the code up right now. The cost of the debt has risen above the value of the investment it bought me. One of the nice things about software is that we can make changes to improve its structure, if we are willing to spend the time doing so. What is Refactoring? Finally, here is a metaphor you can use to explain refactoring to people who don't get it yet: refactoring is a time machine. I'll be smarter tomorrow, more experienced, better informed about what the system I am building today should look like. That is when I should hop in the time machine and make my code look the way it ought, given what I know then. Boy, that take's a lot of pressure off trying to fake the perfect design today, when I don't know yet what it is. (If I could travel in a blogging time machine, I might go back to last Friday, unmention the Kent Beck failing today, and find a way to use for the first time here!) -----