The Missing Peice of Design

We've know for years that defects are easier (and cheaper) to fix during requirements and design than during coding and test. Yet that knowledge doesn't seem to reduce the number of requirements and design defects .

What's particularly weird is that all other factors being equal most "lets do it"(1) projects that I've observed turn out to have significantly fewer requirement and design defects than projects with heavy investments in design.(2) Until now I haven't understood why. In a Eureka moment late last week I finally realized why.

The key is that design does not come from reality. Design comes from a mental model of the world. Like this:

Requirements and design problems are almost always are rooted in the disconnect between the mental model and reality. It makes logical sense. Designers are almost always smart, dedicated and detailed. Once a piece of information has become part of a designer's mental model it is unlikely that it will be forgotten or corrupted between the model and the design. The more time a careful designer spends polishing and refining the design the less time they have to develop and verify their mental model. Thus the very thing--careful preparation--that is suppose to reduce risk actually increases it!

Of course modern software developers don't (I hope) follow the simplified model above. Instead we follow an iterative model. Here is the classic Boehm model from 1988.

The problem with this model is it doesn't reflect the disconnect between reality and design. Instead I propose the following:

If the mental model is close to reality projects will slide cleanly into stage 4. If not, there is a jarring bump as the design crashes into reality. If your design crashes, watch out. It will be tempting to slap a patch in place and move into the next iteration. Don't. Stop and re-calibrate. Scrap the entire previous iteration if you must. In the end it will be a lot cheaper than working around a flawed design for the life of the software.

----------------------------------

1) By "Let's Do It" I don't mean unplanned, I just mean less formal.

2) This may sound suspiciously like a argument for the Agile development process and perhaps it is. I've never worked in an Agile environment so I can't say.