James Shore

I've been trying to describe this design thing we do in XP for a while now. I'd like to expose it as a mainstream practice that can be done outside of the XP context. Lately, I've been calling it "reflective design."

My best description of reflective design, so far, is Design Mindsets. I called it "continuous design" there, but now I think "reflective design" is a better term. Either way, here's a nutshell description:

• Predictive design: Designing for code that is yet to be written. What people usually think of as "design."
• Reflective design: Designing based on code that has already been written.

Reflective design, for me, works like this:

1. I have some code that I've been working with for a while.


2. In the course of adding a new feature or making some other change, I become aware of a design flaw.


• In poorly-designed code, the design flaws are obvious: a procedural rather than OO style; Primitive Obsession; Long Method; Pattern Obsession, etc.


• In well-designed code, the design flaws are more subtle. Things don't fit together as well as I would like, or I have a hard time understanding how things fit together. It may take me a while--weeks or months--to put my finger on the problem. I don't spend those weeks or months thinking about it; instead, the design flaw is sort of churning around in the back of my mind, triggered every time I run into it.


3. I draw a picture that shows the design and what's wrong with it. I gather the team together and say, "Hey, look at this!" And I point out the code smell.


4. By this point, I usually have an idea for a better design. I draw another picture and say, "I think this would be better." And we talk about it. Other alternatives are presented, etc.


5. Then we fix the design using refactoring. If a big change is required, we'll fix it incrementally, sometimes over the course of a couple of months.