Refactoring Metaphor

by Jeff Langr

September 16, 2004

I’m not overly fond of metaphors. They’re never perfect and are usually abused.

One metaphor for refactoring is dirty dishes. The person who chooses not to clean his dishes as he goes finds himself with a growing, dirty pile of dishes. At some point, presumably, the developer runs out of dishes and can no longer eat.

It’s an adequate metaphor. Refactoring is something you should do constantly, a little bit each time you touch code. Do a meal, wash the dishes for the meal. Your likelihood to throw up your arms in disgust at a huge stack of dishes diminishes.

There are problems, however, with the metaphor. If you don’t refactor your code, it becomes exponentially more difficult to introduce new changes without the possibility of causing problems. Also, companies know they can get away with buying cheap dishes, perhaps even paper or plastic, instead of wasting their time cleaning them. Some companies will throw away expensive china if it’s gotten too dirty. And all companies know that there are a lot of places to leave the dirty dishes lying around.

A Jiffy Lube mechanic, on the other hand, works in a pit of fairly limited size. He changes oil frequently (let’s imagine that a car represents a task on a project). The mechanic can choose to ignore the oil oozings that drip onto the floor. Or, he can take the extra time to clean it up with each oil change.

If the mechanic chooses to ignore the dirty liquid, it begins to build up on the floor. At first, things are a little slippery and a bit of a nuisance. In a short amount of time, perhaps a day or two, the mechanic begins to fall down on the job, taking a bit longer to complete each oil change.

You know where this is going, of course. It gets exponentially worse and worse; soon the mechanic swims against the black filthy tide, and can do one oil change a day if he works hard enough. Finally, the mechanic just drowns, never to change a filter again.

XP or no XP, test-driven development or no test-driven development, programming or something else, all systems have entropy. All systems turn crufty and ultimately become useless. The promise of XP is to allow you to sustain that system for a longer period of time before the costs become too high. This is the hope for any system. Constant, hardcore refactoring at the micro level is essential for this to happen. Don’t let the code drown you!

Share your comment

Jeff Langr

About the Author

Jeff Langr has been building software for 40 years and writing about it heavily for 20. You can find out more about Jeff, learn from the many helpful articles and books he's written, or read one of his 1000+ combined blog (including Agile in a Flash) and public posts.