All too frequently I hear how some group of people feel the only way to get their system to work properly is to start over from scratch. The most recent example of this was from the council for a large school district near where I live. While starting over from scratch may sound like a great idea, it is usually a poor choice for any system that has been operating for a period of time. I learned this first-hand early in my career while taking care of the interface and software that operated between the ground and flight equipment of an IR&D project. I shared my story in the current issue's "Tales from the Cube" article, "The smallest change necessary: Wise boss imparts important design principle," which touts the value of making only the smallest change necessary to accomplish your goal of changing your system's behavior.

The idea that doing a redesign from scratch is much better than using the existing implementation is flawed. The existing implementation has been tested under field conditions and contains fixes to real-life conditions that the system has actually had to operate in. How does starting over preserve those lessons learned?

Besides the very high chance of having to repeat hard-won lessons learned that are already captured in the existing system, the effort spent starting over from scratch is effort not being put into making the current system work better, adding new capabilities to the existing system, and keeping your product viable against your competitor's alternatives—especially if they have decided not to start over from scratch. Netscape's fall as the preeminent Web browser is partially attributable to the company's decision to rewrite the browser from scratch while its competitor, Microsoft, incrementally improved its browser.

The decision to start over from scratch is basically a decision to throw away many man-years of effort and lessons learned that the current system implementation encompasses. Aside from the different incentives between politicians and commercially competitive teams for wanting to start over from scratch, why would a design team spend more than a few moments even consider starting over?

Here's a description of what engineering is that I use: Engineering is the discipline that enables a system to behave consistently despite having to operate over a range of conditions. When we design a system from scratch, we by necessity (to contain the amount of complexity we have to consider at one time) design the system to the most likely conditions. As the system operates successfully under those conditions, we allow the user of the system to try a wider range of conditions, and this is where and why the system configuration or code gets "messy"—to accommodate those variable conditions that are not compatible with the general conditions.

Other possible incentives for this bias to want to start over from scratch may be that our culture rewards the maverick that blazes a new trail and makes new ways of doing things possible. Another reason is that the technical labs in college usually give projects to students that start from a blank slate. Are we biasing our future design engineers to develop thought patterns that propagate working from a clean slate rather than making small changes to and improving on legacy structures?