If there is one lesson to learn from this article it is that old code isn’t bad. Its been tested, lots of bugs have been found and fixed, and it is a lot harder to read code than it is to write it.
If you take a look at the long list of companies that have tried to rewrite their code base, almost all of them ended in failure. Going all the way back to the early 2000’s, Netscape decided to rewrite the entire 4.0 codebase for 6.0. It took them 3 years and in that time, Microsoft swooped in with Internet explorer and took away their marketshare. Netscape ended up going out of business.
Microsoft also made this mistake with Word which they planned to replace with a secret project called “Pyramid.” After years of working on a replacement, they realized it was a total failure and scrapped the project. Luckily they were still working on Word, so they just released that instead.
More recently, Macromates an indie company who had a very successful text editor called Textmate decided to rewrite the code base for Textmate 2. It took them 6 years to get a beta release out the door which is an eternity in today’s time and they lost a lot of marketshare. When they did release a beta, it was too late and 6 months later they folded the project and pushed it on to Github as an open source project..
Quick customer-driven releases are better than big upfront plans or rewrites for several reasons. First, the market changes quickly and your product needs to be able to pivot to those changes. Second, its better to string your customers along meeting their incremental needs than abandoning them for a period of time to then try to meet all of their needs at once. Lastly, big projects always take longer than expected, so you’re likely to cause disappointment and pain for your customers on the bigger projects as you delay and try to explain away why they should continue to wait.
Code rewriting is a classic example of the Second-system effectwhich is the tendency of small elegant and successful systems to be replaced by feature-laden monstrosities.
People who have designed something only once before, try to do all the things they “did not get to do last time,” loading the project up with all the things they put off while making version one, even if most of them should be put off in version two as well.
This affects not only programmers, but anyone involved in design. With all of this negativity toward rewrites, is there ever a time that it is acceptable? Author Neil Guntonconcludes that there are 3 factors that should determine whether or not you need to do a total rewrite:
- Amount of accumulated wisdom
- How incompatible the new version is with the old version
- How many people used the old version and will be affected by the changes
With these in mind, you can quickly determine the cost of doing a total rewrite and hopefully decide against it.
Look at it as a living organism that can perhaps be healed, and can evolve. You can refactor, you can rewrite portions of the internals to work better, many things can be accomplished without abandoning all the experience and error correction that went into that codebase. When you rewrite you are abandoning history and condemning yourself to relive it.
Well said Neil.