malvasia bianca

I finished reading The Art of Agile Development, by James Shore and Shane Warden a few weeks ago. It’s a quite good book: if you’re looking for a well-written, prescriptive guide for how to do XP, this is what I would recommend.

Though I won’t go into the book in general any more than that. But, a few thoughts that it triggered:

One thing I liked about the book’s discussion of “once and only once” (pp. 316–317) is that it spent some time on the first “once”. I’m used to thinking of the sentence in terms of eliminating duplication, which is great. But the first part of that sentence is important, too: as they say, “don’t just eliminate duplication; make sure that every important concept has an explicit representation in your design”. That way, you have a place to store behavior related to that concept: e.g. having a Dollar class may not seem like a big win over, say, just representing dollar values as integers, but it gives you a place to stash code for formatted output, or parsing, or conversions to related types.

I also really liked the discussion of levels, rhythms, and frequencies of refactoring in the “Incremental Design and Architecture” section. (pp. 321–330.) They distinguish between standard incremental improvements and “breakthrough” changes: the latter are “idea[s] for a new design approach, which will require a series of refactorings to support it. … Breakthroughs happen at all levels of the design from methods to architectures.”

After which they talk about how frequently you do various sorts of refactorings, and how to make time for them. At the method level, “Method refactorings happen every few minutes. Breakthroughs may happen several times per hour and can take 10 minutes or more to complete.” At the class level, “Class-level refactorings happen several times per day. Depending on your design, breakthroughs may happen a few times per week and can take several hours to complete.”

The latter raises the question: several hours is enough to make a noticeable blip in your team’s work for the week, so where do you find the time, if you see something that looks valuable but isn’t on the shortest path to completing a feature? Their answer: “Use your iteration slack to complete breakthrough refactorings.”

And then there are architectural breakthroughs; I’ll quote them at length on the subject (p. 325):

In my experience, breakthroughs in architecture happen every few months. (This estimate will vary widely depending on your team members and code quality.) Refactoring to support the breakthrough can take several weeks or longer because of the amount of duplication involved. Although changes to your architecture may be tedious, they usually aren’t difficult once you’ve identified the new architectural pattern. Start by trying out the new pattern in just one part of your design. Let it sit for a while—a week or two— to make sure the change works well in practice. Once you’re sure it does, bring the rest of the system into compliance with the new structure. Refactor each class you touch as you perform your everyday work, and use some of your slack in each iteration to fix other classes.

Keep delivering stories while you refactor. Although you could take a break from new development to refactor, that would disenfranchise your customers. Balance technical excellence with delivering value. Neither can take precedence over the other. This may lead to inconsistencies within the code during the changeover, but fortunately, that’s mostly an aesthetic problem—more annoying than problematic.

Definitely something to think about: over the last few years, my team has made some progress in terms of lessening the technical debt that we’re adding to the system, but we still haven’t done nearly as well on that as I’d like, and we’ve done a bad job in terms of actually eating away at the technical debt. (As you might suspect from my using the term “last few years”.) We’re just not good at maintaining a good refactoring rhythm at the various scales that are necessary; maybe the authors’ advice on the subject will help, by giving an idea of what our behavior would look like if we were successful.

Note also the importance of slack in carrying this out successfully.