What is Second System Syndrome?
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.
Similar Posts:
About the Author
Carlos Oliveira holds a PhD in Systems Engineering and Optimization from University of Florida. He works as a software engineer, with more than 10 years of experience in developing high performance, commercial and scientific applications in C++, Java, and Objective-C. His most Recent Book is Practical C++ Financial Programming.
“By that point, Microsoft was already the dominant browser vendor”
With a healthy dose of monopoly abuse, yes.
“and from there it was just a downward spiral for Netscape”
Not that downward since it turned into Mozilla Firefox and now has 30-35% market share. Imagine how high that would be if they weren’t up against a monopolist abusing their position to pimp their own browser?
By rjp on Jan 14, 2011
@rjp you’re right, but open source Mozilla only became a success after the Netscape company was bankrupt…
By coliveira on Jan 14, 2011
The word is spelled “losing”. Lose is the opposite of win, but loose is the opposite of tight.
By nick on Jan 14, 2011
Thanks for catching the typo.
By coliveira on Jan 14, 2011
Nice post, Carlos.
I’ve made this mistake myself a few times. Typically I get halfway done with the rewrite, which is just enough to make me appreciate the strengths of the initial implementation that I’d been taking for granted. And so I wind up with an old system that’s not good enough and a new system that’s incomplete.
Much better to just improve the existing system from the start!
By Dan on Jan 14, 2011
In other words: Blue sky rewrite or incremental rewrite.
By Geoff H on Jan 15, 2011
Refactoring old system might be equally hard, especially without proper tool support.
By Montreal Web Design on Jan 15, 2011
The “Second System” is not a syndrome, it was recommended by Fred Brooks in the “Mythical Man Month.” He has since endorsed the Agile methodology I believe.
By dan on Jan 16, 2011
On the other hand, Together has rewritten their tool three times and were very successful with it – until Borland bought them and stopped the “rewrite cycles”.
By Messi on Jan 19, 2011
Clearly there *are* cases where a company is better off rewriting software, and there are cases where they are not. The trick is distinguishing between the two, and if a rewrite seems appropriate, not justifying it by promising to immediately handle a pile of new requirements that add a lot of complexity.
You are right to be suspicious of the desire to rewrite. If a rewrite seems attractive, you might consider having a small team spend a predetermined amount of time — perhaps one or two people for a month — constructing a prototype of the core functionality. Then they can present that prototype to a larger group and make a case for continuing to work on it. The larger team should ask lots of “How would you handle this case?” questions. If the rewrite still seems to have compelling advantages over continued refactoring, then they might get the green light for another, say, 2 months.
The prototype should probably concentrate initially on providing the equivalent of existing functionality while making the code more maintainable and making it *possible* to meet key additional requirements, without actually spending a lot of time on meeting a number of new requirements. In other words, build in adaptability.
And of course it is easier to justify a rewrite if you can provide interfaces which allow legacy modules to function more or less as they used to until they can be rewritten.
I’m all for refactoring, which should be the answer most of the time, but don’t forget “Out of the Tar Pit.” If you are in a tar pit, you may need to think a little further out of the box.
By Nicholas Sterling on Sep 13, 2011
I do like this article. I have personally experienced it while I was developing a simple calculator for the second time. The calculator I was developing was so big, I never finished it. ;)
By Saeed Neamati on Jun 9, 2012