Plan to Throw One Away
In most of the projects, the first system built is barely usable, either it is too slow, clunky and/or too bulky. Once you write a program, you often get the feeling that it can be written in a better way. When the software is reviewed after it is built, the inefficiencies become apparent, but by that time it is often too late to make any changes. The options are either throw away the first build and re-write it OR ship it and re-write it gradually.
The fact is every software, anyhow, will be thrown away, so why not be prepared for the inevitable. (Feels like talking about life)
Below are a couple of pointers to enable the preparation:
But why do we need to eventually throw the software away? For this, we need to understand how the software ages.
Phase 1: 2 Steps Forward and 1 Step Back
Whenever a defect is fixed there is a 35% chance that it will introduce a new defect. Why? First, a defect shows up as a local failure, where it gets fixed as well, it is the system-wide ramification that is usually non-obvious. Second, often the repairer is not the person who built it.
领英推荐
Phase 2: 1 Step Forward and 1 Step Back
Maintenance is an entropy increasing process. Sooner or later there comes the tipping point where each forward step is matched by a backward step. This software can be used as long as desired but this is the time one should start thinking about retiring/revamping it.?
My Thoughts
Amazing to see how this chapter, written almost half a century back is still so relevant today. The thought that the software will be thrown away is uncomfortable and yet so liberating. No designer designs the system with this eventuality in mind that the software will age and needs to be replaced. Technologies and requirements change really fast, systems and teams designed with this eventuality in mind would gracefully embrace change and continue to turn into, and rise from, the ashes.