Commentary: How to do a full rewrite
How about never, is that good for you?
How to do a full rewrite covers a scenario in which a programmer works on a new system that predates them, and they are tempted to start over in the face of how hard the system is to change incrementally.
The canonical write-up of why you should be wary of full rewrites is by Joel Spolsky and is called Things You Should Never Do, Part I. If you have never heard of Joel, go ahead and block out the next few hours to browse his archive or buy compilations of his writing. Joel is Stack Overflow's co-inventor; if you haven’t heard of that, ask ChatGPT what it is.
In another post, Joel lays out why rewriting is so hard other than just effort:
The sheer volume of bugs, it seems, proves that rewriting code from scratch does not make for a better code base, it makes it worse. Old code doesn’t rust, it gets better, as bugs are fixed. Lou Montulli again: “I laughed heartily as I got questions from one of my former employees about FTP code the he was rewriting. It had taken 3 years of tuning to get code that could read the 60 different types of FTP servers, those 5000 lines of code may have looked ugly, but at least they worked.”
Software loses context as it ages - not all the information is contained in the source code, and a rewrite is an attempt to rebuild it because the context has changed. But it is very tricky to figure out which context matters. The situation becomes more complex the more interactions there are with outside systems. In many cases, rebuilding software as a new product makes more sense than rewriting.
Another issue that I point to is that rewrites are sometimes borne out of a combination of arrogance and frustration at how hard it is to work on a system, combined with the inherent stability of the system. The longer a system has existed, the harder it is to change, which is a double-edged sword. If you are a programmer working on a 40-year-old system, it is likely stable as hell. And you were likely hired to change it, which is hard as hell. Living in this world is very emotionally exhausting, and a rewrite is a fantasy you create in order to survive. Rewrites also fall into another trap, which is the belief that technical excellence trumps everything else:
We assume the sun, moon, stars, and the board of directors will all magically reconfigure themselves around the right technical answer simply because it’s the right technical answer. We are horrified to discover that most people do not actually care how healthy a piece of technology is as long as it performs the function they need it to with a reasonable degree of accuracy in a timeframe that doesn’t exhaust their patience. In technology, “good enough” reigns supreme.
This quote is from the best book I’ve read on how to professionally handle an old system that has outlived its initial context: Kill it With Fire (Manage Aging Computer Systems (And Future Proof Modern Ones)). The first chapter starts out strong by explaining in clear terms how it is that we created really large machines with dumb clients, then created smaller smart clients, and then moved to large machines with dumb clients.
The Anti-Pattern Recipe
These are the conditions in which the idea of a perilous full ground-up rewrite thrive:
A system is very hard to change
It feels like it takes more effort to figure out the system than to change it
There is a bit of hubris, a dash of we-could-rebuild-this-in-a-weekend attitude
It feels possible to stop changes
It feels like rewriting it is the only way to understand it
The system is so bad it feels like a YOLO rewrite isn’t that crazy
Healthy Anti-Pattern Recipe
There are times when a rewrite is a good idea, they normally have these conditions:
The rewrite is driven not based on purely technical merit only, but larger scale business efforts. If the development group wants to do a rewrite - red flag. They are like the military, and inherently are always read to go war and willing to suggest it; developers want to develop. If product or upper management are driving a rewrite, it has a much higher chance of success.
“Full system rewrite” makes more sense when the system is smaller, greatly reducing the hubris factor and unknowns.
There are times when the business can make the investment to build a new ground-up version while slowing down new features in the existing system; this can happen on very profitable projects that are nearing a technical cliff but still highly profitable
Caveats and It-Depends and Common Objections
There are some common objections to saying rewrites are a bad idea, because isn’t most technical work of any real size a “rewrite”? Isn’t conquering technical debt a goal?
One person’s rewrite is another person’s regular migration work
Rewriting software is the only way to improve it, so the definition of a rewrite gets fuzzy
Full rewrites have to occur sometimes, like how new warehouses have to be built instead of just adding on the existing ones.
Doing a “mock rewrite” is a useful exercise in the same build one to throw away is - it gets you quickly familiar with the domain.
Be on the lookout for this anti-pattern, and resist the temptation that starting over is less work than understanding and incrementing. If you seek to understand first, you can make a more informed decision later and go into a partial or full rewrite with your eyes open.