Build Once Then Enhance

In his book Mythical Man-Month, Frederick Brooks says to build a system “three times” by designing, implementing, and testing software. But this approach tends to amplify our mistakes rather than allow us to learn from them. It’s based on the false assumption that we can articulate a system’s behavior in the design documents with sufficient detail so as to make implementation merely a matter of following the design.

This has long been the dream of senior management because, as in building construction, the architect is a highly skilled (and highly paid) professional but the rest of the crew merely has to follow the directions outlined in his design documents. Construction workers don’t require a lot of specialized training and therefore don’t demand high salaries.

But software development is different. Requirements and design documents are not blueprints for software construction. In software, design and construction are inextricably linked. It can’t be separated out and a great deal of design decisions have to be made in the moment.

A much better approach is for developers to start by working through concrete examples. Examples give form to abstract concepts so they’re easy to think about, discuss, and find inconsistencies in. Working through an example isn’t a commitment to a particular implementation and it can give us lots of insights on how to best approach a design.

Working through a few examples gives developers enough perspective so they can form the right generalizations. This helps them find the right level of abstraction to apply when coding. And then, rather than launching into a testing phase to assure quality, we instead focus on cleaning up the code to *build supportability into the code we write* so we can continually improve our design and end up with a much better result.