Second system syndrome is term coined to characterize software development groups that enter into the dangerous sport of rewriting an existing piece of software.
It usually happens when someone, feeling that the current system is not good enough, believes that it is would be easier to abandon the current code base and give it a fresh start.
Second system syndrome has happened to a number of high profile companies, but probably the most well known case is the rewrite of the Netscape web browser. By the end of the 90s, Netscape was losing dominance of the browser business to Microsoft. The main problem Netscape faced, however, is that it was too hard for them to enhance the aging code base of Netscape navigator.
The solution Netscape found was to rewrite the whole browser from scratch, in order to create a new code base that would be easier to evolve. The result of this pursuit is that it took years before Netscape had a new browser with the expected functionality. By that point, Microsoft was already the dominant browser vendor, and from there it was just a downward spiral for Netscape.
The other thing that is inherent to second system syndrome is that we have the desire to create a new version of a system that is an order of magnitude better than the previous version. This creates expectations that are hard to match.
For a common example, Microsoft has suffered from this syndrome several times during the evolution of Windows. They frequently promised a new version of its OS that would fix all perceived flaws and introduce revolutionary technology. This usually is followed by long delays and finally to a new version that is more similar to the previous than to the promised one.
The Lessons
While rewriting may be a good thing to do on research and prototype systems, it is rarely the best right thing to do in real systems. Particularly if there is fierce competition in the area of the market you are, there may be no time to recreate a product. In the case of Netscape versus Microsoft, Netscape gave up all the development advantage they had.
Clearly there are some perceived advantages on rewriting a piece of
software:
- Do it right from the beginning: this is the main allure for software engineers (at least the good ones). We really like to do the right thing. However, starting from scratch is not the only way of improving software.
- Fix a broken architecture: Similar to the above, the problem faced may be that a completely wrong architecture is used. For example, we may be using a client-server architecture where this is not applicable.
- Addressing performance problems: This is probably the weakest reason to create a new system. Performance is usually a result of the algorithms and architecture used. It is better to deal with these issues than to start everything from scratch.
Disadvantages
- The new architecture is not a proven one: although we may know that the previous architecture is bad, there is no way to know that the new doesn’t suck until we tested it. A lot of resources may go into fixing something that isn’t broken.
- Lessons of current system may not apply: your team spent years developing a product. With a rewritten version, a lot of that experience is lost simply because the code is different. Improving a system may be easier than recreating it.
- No guarantee that the second will work: another issue is that, if your current code base is not working, the attitude towards software creation will probably be taken along to the new code base. It is possible that in a few months the new code will look very similar to the old one.
- Time to market is lost: more importantly for companies, the lead in the market place may just disappear. In a competitive market, this may be a terrible move. It is better to spend time improving what you already have than trying to create something new and unproven.
Refactoring instead of Rewriting
As a response to the problems created by second systems syndrome, the industry has moved towards the use of refactoring as a standard tool to improving systems. Refactoring is the art of changing a code base in the direction we want to improve it. For examples of what can be done, it is possible to refactor a code base to make it more object oriented, or functional oriented, if that is desired.
There are a number of good books in this area, but the best known is
Refactoring, Improving the Design of Existing Code, by Fowler, Beck, Brant, Opdyke, and Roberts;
Another remarkable book on this topic is Clean Code: A Handbook of Agile Software Craftsmanship, by Robert Martin.