I was talking with Charlie Poole (of NUnit fame) at a recent workshop. I had just presented my Reflective Design ideas to a small group and we were talking about it. As we talked, I sketched out a design map and said, "for example, this is the XP approach to design."

Charlie stopped, looked at it, and said, "That's not what I do at all."

I was surprised. Charlie and I both have an XP background and (of course) heavy emphasis on test-driven development. That's when I realized how interesting it would be to conduct a survey of design approaches.

When do you design? I'd like to see your design map. I'll collect them all and post them here in a week or so. Send emails to jshore@jamesshore.com. If you can include the type of process you use, that would helpful.

How to Draw a Design Map

A design map is a simple table that shows how and when you perform design activities. Start by creating a 4x3 grid, like this:

	Up-Front	Intermittent	Continuous
Product	___	___	___
Package	___	___	___
Class	___	___	___
Method	___	___	___

The rows represent what you're designing:

Product	How the namespaces, packages, and other major components fit together to form the entire product.
Package	How classes fit together to form a namespace or package.
Class	How methods fit together to form a class.
Method	How lines of code fit together to form a method.

The columns represent when you're designing:

Up-Front	Before coding begins.
Intermittent	At regular intervals during coding.
Continuous	Every day.

The cells indicate how you design. In each cell, place a "P" for "predictive" or an "R" for reflective:

"P" (Predictive)	Creating design elements to guide future coding.
"R" (Reflective)	Reviewing design elements formed from existing code to find ways to improve design.

Use an upper-case letter to indicate a lot of design and a lower-case letter to indicate a little design. Use a dash ("-") to indicate that you don't do any design at that point. If you do both predictive and reflective design in a particular cell, put both letters.

It's easiest to do this on a piece of scratch paper or a whiteboard before putting it in electronic form.

The question of predictive vs. reflective design is a little tricky. In both cases, the design work can be done entirely "in your head"--that is, mentally--or it can involve whiteboard discussions or even formal printed documents.

For predictive design, the key feature is whether or not the code closely mirrors the design. Thinking about design precedes--and predicts--code. If you think of future design scenarios but don't end up coding any of them, it's not predictive design.

For reflective design, the key feature is whether or not the design effort is based on existing code. Thinking about design follows--and reflects upon--code. If you review a design document that hasn't been coded, it's not reflective design.

My Design Map

As an example, this design map describes my approach to design:

	Up-Front	Intermittent	Continuous
Product	-	R	r
Package	-	R	r
Class	-	r	R
Method	p	-	R

You can see from this design map that I'm heavily biased towards a reflective approach to design. Except for individual methods, I don't do any up-front design work. For "big-picture" design, I do most of my design at regular intervals; for detailed design, I do most of my design continuously.

Design maps don't tell us everything about somebody's design approach. This design map doesn't tell you that I've been heavily influenced by XP's approach to design or that I use test-driven development exclusively. It doesn't tell you that I'm continuously mulling over the "big-picture" design and using that thought process to guide the intermittent, more intensive reflective design sessions.

Instead, design maps are a great framework for discussion. Use them to share ideas and start conversations, as I'm doing here. Which reminds me: I'm collecting design maps. Send me yours!

Update, 6 Feb 2006: I've posted your responses.