Stephan Schmidt
How To Succeed With A Rewrite
Why rewrites fail and what to do about it
You’re going to do a rewrite. Don’t. Yes, I know, but don’t. I have been involved in rewrites, relaunches and redesigns as a developer and CTO. Most don’t work out. Even those that finish seldom deliver on technology promises or business value. And all risk your company, incapacitated for months, your competition gets ahead, or key customers drop because you don’t deliver features.
As Joel Spolsky wrote about Netscape: “Well, yes. They did. They did it by making the single worst strategic mistake that any software company can make: they decided to rewrite the code from scratch.”
With one of the key results of rewrites “then they made it again in rewriting Quattro Pro from scratch and astonishing people with how few features it had”
Or as Swizec Teller writes: “1. Stop the world and rewrite 2. Build a new system next to the old - These sound clean and tidy. The old and the new system stay neatly separated while you work. But that almost never works.”
Still you want to rewrite your companies’ system? You really need to or the business stops? Then I’ll help you succeed. But it’s a difficult task that needs all your attention. First, let’s find out why rewrites are so difficult to pull of.
Reasons:
The destination of your rewrite is a moving target. Ever walked 50 meters behind someone, but faster ready to overtake that person? It takes surprisingly long and your estimate how long it would take is remarkably off - because the person moves, and we’re not good at estimating the distance to a target moving away from us. In a rewrite while you write the new version, new features are added to the old code. And more features are added. All of them are assumed to be added to the rewrite. It’s like in Achilles paradox. From Britannica “The paradox concerns a race between the fleet-footed Achilles and a slow-moving tortoise. The two start moving at the same moment, but if the tortoise is initially given a head start and continues to move ahead, Achilles can run at any speed and will never catch up with it. Zeno’s argument rests on the presumption that Achilles must first reach the point where the tortoise started, by which time the tortoise will have moved ahead, even if but a small distance, to another point; by the time Achilles traverses the distance to this latter point, the tortoise will have moved ahead to another, and so on.”
You have no business requirements. Software systems are like icebergs. There is a small UI, that you can see but a huge portion of the iceberg - and your system - is underwater. In the case of an iceberg, only 1/10th can be seen. Product mangers often assume only the parts they see need to be rewritten and plan accordingly.
The code went through years of bug fixing. You plan to deliver that level of quality without that period of bug fixing. Years of edge cases that no one thought of have been fixed with bug fixes. The Probability is high that edge cases no one thought of before would be the same no one thinks of now.
Developers often change technologies for a rewrite. They change frontend frameworks, backend frameworks and add message queues or databases. They don’t have experience or deep knowledge on these technologies—they are beginners who want to pull of a masterpiece on their first try. Often these technologies are bleeding edge - and they are not called bleeding because your competition will bleed.
So what to do:
Don’t change technologies if you don’t have to. If the reason for the rewrite is to replace some commercial product you no longer can afford, replace the technology first, then rewrite the rest. If you use React, use React in the rewrite (Or was the rewrite just a scam to play with some new toys? Shame on you).
Have enough people on the rewrite. If you split the development team 50:50 you’ll fail. If you split it 90:10 with 90% working on the rewrite, you might succeed. Somewhere in between is the tipping point. Play it safe, best to have one or two developers work on the old code and fix bugs and implement new legal requirements, everyone else work on the rewrite.
Look into the code, get a thorough understanding if the code, write down all requirements. Requirements first, then start coding. Don’t make the mistake of tabula rasa, don’t make the mistake of “We start from new, the old code is bad, I don’t want to see it.” Often looking through bug tickets of the last five years is helpful to understand edge cases.
Have a thorough estimation on how long it will take based on the requirements, then double the estimation.
But …
That said, there is one situation when I would do a rewrite: The company is in deep tech trouble and hires me as CTO for exactly that reason. In the beginning, the company listens to you, and it got you in to solve that problem. Stop the world. Six month rewrite. Happy future. In all other cases, refactor each module and after some years your code will be fine.
