The Big Bad Rewrite Isn't Always a Bad Idea

The other day I wrote about how a lot of value in legacy systems could be liberated by more freethinking and vigorous modification and refactoring -- not the defaults of "replacement" or "incremental maintenance."

Now I'm going to look at the other end of things -- when it makes sense for to replace even "young" systems with a full-on rewrite.

Joel Spolsky has written one of the more famous essays on the big rewrite as anti-pattern. And he's right in that essay. Don't rewrite because you have grand dreams of tearing down the house to build a beautiful code palace, or because code is easier to write than to read, or because you don't like the platform the other guys used, or because your team ends every status meeting with "we need to throw the codebase out and start over," like Cato the Elder ending every speech Carthago delenda est.

A rewrite makes a lot of sense, though, in situations where the original implementation was pushing the bounds of the platform, resulting in some hairy, troublesome, and expensive-to-maintain code ... and meanwhile the industry has caught up and moved past you to the point that the hard areas are now trivial.

In the late 90s, you might have spent a bunch of time on a very complex desktop reporting app with Java 2D graphics. Your engineers hacked to the limits of what Java could do ... and maybe even tore out into the world of JNI/OpenGL or COM/DirectX to push the bounds. You used CORBA or wrote your own communication protocol, worked around firewall issues, etc. Suppose that today, the code still causes trouble, is difficult to maintain -- and could be replaced with a few hundred lines Adobe AIR/ActionScript code and web service calls. The smart thing to do is rewrite.

Look at the apps your company may have built 5-10 years ago, especially anywhere you were pushing the bleeding edge not as value-add but just as support. Do you have a roll-your-own communication protocol that made sense at the time, but could now be replaced with 10-lines of script, or a point-and-click binding in your IDE of choice? Did you write a persistence layer (or work the source code of an open-source one) when databases were more expensive and each server could house much less data than today?

Here are some common factors indicating it may be time to do a rewrite:

1. Volumes of code can be replaced with much less code (leveraging newer open source and/or vendor-supported libraries).
2. The existing code is creating real, measurable, avoidable expense at a large ratio (like 2:1, not 1.15:1)
3. Your goal is to leverage other smart people's work, not prove that you're smarter than the guy who wrote your old system.
4. At the business level, you need to gain leverage by getting back up on top of a technology stack and out of the middle where you're toiling away creating no externally measurable value.