At a recent roundtable, one of our topics was continuous design. That session got me thinking about continuous design and how it's different from traditional design.

Ultimately, traditional design is not all that different from continuous design. People who excel at traditional design can also excel at continuous design. What's different is the mindset. Let me see if I can describe it...

Design Approaches Contrasted

In traditional design, you design your code before you write it. Let's call this predictive design. I'm not talking about that famous straw-man, "Big Design Up Front"--I'm talking about normal, sensible, planning of a design in advance. This can be done iteratively and incrementally. The design session might only be a few hours, or it might be a week . The main point is that it involves imagining the best possible design in advance.

In continuous design, you design your code after you write it. This is the big mindset difference that people have trouble with. A new feature is implemented in lots of teeny-tiny steps. After each step (which lasts anywhere from 30 seconds to five minutes), the programmer-designer re-evaluates the design of the code that he or she just added. Every hour or so, the programmer-designer will review the big-picture design and improve it. The main point is reviewing existing design and improving it.

The continuous designer (who is also the programmer) uses the same design techniques as the predictive designer. UML, CRC cards, heated conversations around a whiteboard--they're all there. The only difference is when they happen. And, because continuous design involves a lot of frequent, ad-hoc discussions, continuous designers tend not to use CASE tools, which are poorly suited to the task.

People criticize continuous design as "hacking," so let me contrast the two. When hacking, you design your code as you write it. That is, the programmer bangs out some code, tries to make it as clean as possible, but neither plans the design in advance nor changes it significantly after it's done. Even in the best case, hacking lacks the all-important big-picture design reviews and improvements of continuous design. This works fine in trivially-small projects and inevitably leads to a big ball of mud in larger projects.

Skillsets Needed

A good predictive designer will focus on coming up with designs that are "malleable"--that is, that accomodate new features without requiring design change. New features often involve "plugging in" new classes at predetermined extensibility points. There's a lot of emphasis on patterns. Experience is also super-important, because the designer has to predict what kinds of new features will crop up and avoid potential problems.

A good continuous designer, on the other hand, will focus on coming up with designs that are "simple"--that is, that accomodate new features through small, focused refactorings. New features often involve a few refactorings and new code, but not necessarily new classes. The main emphasis here is on recognizing a bad design (through "code smells") and figuring out the refactoring steps needed to turn it into a good design.

In either case, the designer has to know what a good design looks like. The main difference is that a traditional designer invents a good design and a continuous designer reviews an existing design and comes up with ways to make it better.

The Efficiency Question

Stated like this, continuous design sounds really inefficient. "Look at all that rework!" people say. "Why not just design it right the first time?" Well, I'm not sure that continuous design is actually slower. The really good continuous designers I know produce amazing code very quickly, partly because their design is so clean.

But even if continuous design is slower than perfect up-front design, the basic assumption is flawed. "Why not design it right the first time?" Because we're human and make mistakes. There's no such thing as a perfect up-front design. There's too many unknowns for that to be possible, and no amount of time spent imagining the future will change that fact.

A really experienced predictive designer might not make any mistakes--in a domain that he or she is experienced in. This requires a great amount of experience, not only with software design, but with specific types of software. If I had the opportunity to work with someone of this caliber, I'd take it in a heartbeat. But they're hard to find.

The Experience Question

This leads us to the other main concern I hear about continuous design. "Doesn't continuous design require senior developers?" Yes and no. Continuous design absolutely requires continuous review and refactoring of big-picture design. Without this essential factor, it turns into hacking. My experience in coaching a lot of teams is that the "big-picture design" part tends to be forgotten by less-experienced team members.

On the other hand, the whole team doesn't need to be that experienced. I'd recommend one senior designer-programmer per six programmers, and you could probably stretch this to one per ten if you needed to.

What if you don't have any senior designers? In that case, hire me. I have convenient retainer options to keep your team from going too far into the weeds. ;-)

Seriously, any team without senior designers is going to run into trouble, whether they use predictive or continuous design. I would guess that a team trained in continuous design would do better than one trained in predictive design, just because predictive design relies so much on experience to get good designs. It's easier to teach people how to review designs and make refactorings.

Conclusion

The bottom line is that predictive design and continuous design both require a great design sense. The mindset is different, though. Predictive designers have a "predict the future" mindset and continuous designers have an "analyze the past and improve it" mindset. You can switch from one to the other if you try.