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!)
-----