TITLE: More on Metaphors for Refactoring AUTHOR: Eugene Wallingford DATE: May 21, 2007 4:45 PM DESC: ----- BODY:

Not enough gets said about the importance of abandoning crap.

-- Ira Glass
, at Presentation Zen Keith Ray wrote a couple of entries last month on refactoring. The first used the metaphor of technical debt and bankruptcy. The second used the simile of refactoring as like steering a car. In my experience and that of others I've read, the technical debt metaphor works well with businesspeople. It fits well into their world view and uses the language that they use to understand their business situation. But as I wrote earlier, I don't find that this works all that well with students. They don't live in the same linguistic and experiential framework as businesspeople, and the way people typically perceive risk biases them against being persuaded. A few years ago Owen Astrachan, Robert Duvall, and I wrote a paper called Bringing Extreme Programming to the Classroom that originally appeared at XP Universe 2001 and was revised for inclusion in Extreme Programming Perspectives. In that paper, we described some of the micro-examples we used at that time to introduce refactoring to novice students. My experience up to then and since has been that students get the idea and love the "a-a-a-ahhh" that comes from a well-timed refactor, but that most students do not adopt the new practice as a matter of course. When they get into the heat of a large project, they either try to design everything up front (and usually guess wrong, of course) or figure they can always make do with whatever design they currently have, whether designed or accreted. Students simply don't live with most code long enough, even on a semester-long project, to come face-to-face with technical bankruptcy. When they, they declare it and make do. I think in my compilers course this fall I'm going to try to watch for the first opportunity to help one of the student groups regain control of their project through refactoring, perhaps even as a demonstration for the whole class. Maybe that will work better. That said, I think that Ray's steering wheel analogy may well work better for students than the debt metaphor. Driving is an integral part of most students' lives, and maybe we can connect to their ongoing narratives in this way. But the metaphor will still have to be backed up with a lot of concrete practice that helps them make recognizable progress. So watching for an opportunity to do some macro-level refactoring is still a good idea. Another spoke in this wheel is helping students adopt the other agile practices that integrate so nicely with refactoring. As Brian Marick said recently in pointing out values missing from the Agile Manifesto,

Maybe the key driver of discipline is the practice of creating working software -- running, tested features -- at frequent intervals. If you're doing that, you just don't have time for sloppiness. You have to execute well.
But discipline -- especially discipline that conflicts with one's natural, internal, subconscious biases -- is hard to sell. In a semester-long course, by the time students realize they really did need that discipline, time is too short to recover properly. They need time to ingrain new practice as habit. For me as instructor, the key is "small", simple practices that people can do without high discipline, perhaps with some external guidance until their new habit forms. Short iterations are something I can implement as an instructor, and with enough attention paid throughout the term and enough effort exerted at just the right moments, I think I can make some headway. Of course, as Keith reminds us and as we should always remember when trafficking in metaphor: "Like all analogies, there's a nugget of truth here, but don't take the analogy too far." -----