Rewriting is More Expensive than You Think

There always seems to be a strong desire in software developers and managers to completely rewrite systems. People just love creating something brand new without the burden of worrying about existing code and architecture. I share this desire myself, but I find it hard to believe how often companies look at a giant system that's been developed over a decade or more, and think they can pull off throwing it out and rewriting it.

When developers and outsiders first see a system, it's easy to write it off as "crummy code" or "way too complicated". They develop a rosy picture of the way the system should work, and then come up with a rough estimate of the work involved based on that rosy picture. Based on these idealistic estimates it seems like a good idea.

The first problem is that they've completely discounted the effort that went into the existing system. The first system could have been developed over 10 years by 100 developers, but they now estimate that they can completely recreate that in 1 year with only 20 developers. Those 100 developers were actually doing something over those 10 years, and it's huge mistake to discount all that work. Upon closer examination, all of that "crummy code" usually is dealing with all the real world scenarios that don't fit into the rosy picture. The original code is probably complicated, because the problem it's trying to solve is complicated.

The second problem is that people usually grossly exagerate the benefit of the rewrite. Take Expedia's web server as an example. Development started on it in the mid nineties before most of the web server technologies people use today had even delivered their first versions. It uses a custom template language, and is backed by C++, which very few people use for the web today. The web server contains both display code, and business logic. It would be very tempting to rewrite it thinking you could make your developers much more efficient.

When you actually look at where the developers spend their time though, you find that about 50% of the time is spent on the middle tier servers, which wouldn't be affected by this; 15% of the time is spent writing HTML and JavaScript, which also wouldn't be affected; and 20% is spent on business logic, which won't get any simpler by having a new web server. Even if you assume a completely unrealistic 50% efficiency gain, your developers are only getting around an 8% improvement overall. If you assume a more realistic 10% efficiency gain, then the overall gain drops to an unimpressive 1.5%.

Imagine launching a huge multi-million dollar project that will seriously reduce your output for multiple years for a 1.5% efficiency gain. People who launch these kinds of projects typically grossly underestimate the costs, and grossly overestimate the benefits or they would never had started it in the first place. In fact, the history of software development is full of examples of leading companies that were overtaken by a competitor when they made the mistake of trying to rewrite everything.