Every company has at least one program as old as the company. The program may be a small utility, or it may be the flagship product. It may be essential to the smooth operation of the company, or provide the lion's share of the profits. Yet it may be time to throw that program away and start over.
Rarely will one person write a program once and have it meet the company's needs for all time without error. Features are added, bugs are found, and reports are modified. Usually a program will be too large for one person to complete in a reasonable amount of time, so multiple programmers will work on it. One or more authors might move on to another project (or another company), and new programmers will join the project.
Adding features and fixing bugs should be good for the code, right? Well, maybe not. Sprinkled throughout the code are hidden assumptions about the environment in which it works - limits on parameters, the state of the data structures, responsibilities of modules, and so on. No matter how thoroughly the code is commented or documented, these assumptions cannot all be described in writing. Worse yet, the assumptions that are described might no longer be true, leading developers astray.
As the institutional knowledge of the original code fades, it becomes harder and harder for developers to make the enhancements and code fixes necessary to keep the program running. At some point, the day-to-day or strategic cost of maintaining an old program exceeds its value and it is time to start over from scratch.
So how does a developer or manager determine when to throw away a program? Here are some warning signs:
- no one understands all of the code, even at a high level
- code styles vary from module to module or within a module
- bug fixes require changes to multiple subsystems
- comments or external documentation do not match the code
- new enhancements have been added on top of older enhancements
- new enhancements or features require significant changes to core data structures or algorithms
- new competitors can match your capabilities
The last sign is hard for a company to accept, especially for a flagship program that "keeps the lights on," i.e. is a profitable core product. Managers will quite naturally say "if it isn't broken, don't fix it." This is dangerous complacency. If your competitors can match your work with a newer (and likely smaller) program, they will be ahead of you very soon.
Finally, there is one problem that forces you into an immediate rewrite: fixing one bug prevents fixing another. At this point you have no choice but to throw everything you've got into writing a new version of the code. Until you finish the new version, the old code won't work. This can cripple or kill a company; don't let it happen to you.