XP Designs All the Time

In a recent email conversation, a colleague restated a point of view that I've heard many times before:

Some time ago I had an Email discussion with Kent Beck about "design" being on the bottom of the list of activities in XP and that as a last resort you may do some design, but that you have to run to your code once you know enough of how to do things. I suggested that generating more than one design option and choosing which design is better could lead to better results and less rework. His reply was "Of course we also do design". My conclusion of this was that of course he does design, because he is a seasoned programmer and project manager. But the way he minimizes the role of design in his first book, teaches many less well seasoned developers to neglect design in favor of "code and see."

This is a common misperception of XP. XP doesn't do "less design" or "no design." XP does design all the time. It's not implied, either: it's a core part of the methodology. Test-driven development is a design technique. Refactoring is a design technique. XP catch-phrases like "do the simplest thing that could possibly work," "you aren't going to need it," and "once and only once" are design guidance.

XP does relatively little predictive design (maybe 10-30 minutes per pair per day) and lots and lots of reflective design. In every pair, one person is the driver, focused on implementation, and the other is the navigator, focused on design. Every few minutes, each pair is expected to review their recent changes (5-10 lines of code) and refactor to improve its micro-design. Meanwhile, the navigator is thinking about macro design: "Is this the best class for this feature to go in?" "Are the responsibilities of this class still cohesive?" "Does our new code have commonalities with existing code that we can factor out?"

To someone used to predictive design, reflective design doesn't look like design at all. The team rarely sits down together at a table or around a whiteboard (maybe once or twice a week for 10-30 minutes). There's no long-lasting design documentation--just some sketched out diagrams on a notecard or a whiteboard.

Instead, every pair is talking about design all the time. Listen in some time. "What should we name this method?" "I don't like that... it's ugly." "I think we're running into Primitive Obsession here." "If we factor this code out of the UI, it will be easier to test."

I talk further about the differences between predictive design and reflective design in my "Design Mindsets" blog entry.

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.