gistfile1.txt

The Pros and Cons of Rewriting
A complete rewrite is a very tempting idea. Developers championing a rewrite feel like they will be able to
do all the right things the first time through. They will be able to write unit tests, enforce best practices,
separate concerns according to modern pattern definitions, and use the latest framework or even write their
own framework (since they know best what their own needs are). Because the existing application can serve as
a reference implementation, they feel confident that there will be little or no trial-and-error work in rewriting
the application. The needed behaviors already exist; all the developers need to do is copy them to the new
system. The behaviors that are difficult or impossible to implement in the existing system can be added on
from the start as part of the rewrite.
As tempting as a rewrite sounds, it is fraught with many dangers. Joel Spolsky had this to say regarding the
old Netscape Navigator web browser rewrite in 2000:
Netscape made the “single worst strategic mistake that any software company can make” by
deciding to rewrite their code from scratch. Lou Montulli, one of the 5 programming superstars
who did the original version of Navigator, emailed me to say, “I agree completely, it’s one of the
major reasons I resigned from Netscape.” This one decision cost Netscape 3 years. That’s three
years in which the company couldn’t add new features, couldn’t respond to the competitive
threads from Internet Explorer, and had to sit on their hands while Microsoft completely ate
their lunch.
– Joel Spolsky, Netscape Goes Bonkers²
Netscape went out of business as a result.
Josh Kerr relates a similar story regarding TextMate:
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 market share. 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.
– Josh Kerr, TextMate 2 And Why You Shouldn’t Rewrite Your Code³
Fred Brooks calls the urge to do a complete rewrite “the second-system effect.” He wrote about this in 1975:
The second is the most dangerous system a man ever designs. … The general tendency is to overdesign the second system, using all the ideas and frills that were cautiously sidetracked on the first
one. … The second-system effect has … a tendency to refine techniques whose very existence has
been made obsolete by changes in basic system assumptions. … How does the project manager
avoid the second-system effect? By insisting on a senior architect who has at least two systems
under his belt.
– Fred Brooks, The Mythical Man-Month⁴, pp. 53-58.
²http://www.joelonsoftware.com/articles/fog0000000027.html
³https://joshkerr.com/textmate-2-and-why-you-shouldnt-rewrite-your-code/
⁴http://www.amazon.com/Mythical-Man-Month-Software-Engineering-Anniversary/dp/0201835959/
Legacy Applications 5
Developers were the same forty years ago as they are today. I expect them to be the same over the next
forty years as well; human beings remain human beings. Overconfidence, insufficient pessimism, ignorance
of history, and the desire to be one’s own customer all lead developers easily into rationalizations that “this
time will be different” when they attempt a rewrite.
Why Don’t Rewrites Work?
There are lots of reasons why a rewrite rarely works, but I will concentrate on only one general reason here:
the intersection of resources, knowledge, communication, and productivity. (Be sure to read The Mythical
Man-Month⁵ (pp. 13-26) for a great description of the problems associated with thinking of resources and
scheduling as interchangeable elements.)
As with all things, we have only limited resources to bring to bear against the rewrite project. There are
only a certain number of developers in the organization. These are the developers who will have to do both
maintenance on the existing program and write the completely new version of the program. Any developers
working on the one project will not be able to work on the other.
The Context-switching Problem
One idea is to have the existing developers spend part of their time on the old application and part of their
time on the new one. However, moving a developer between the two projects will not be an even split
of productivity. Because of the cognitive load of context-switching, the developer will be less than half as
productive on each.