I often talk about the Best Alternative To A Total Rewrite. The idea that you should know the alternatives to a rewrite before making a decision.
Even when there is no alternative to a rewrite you still need to work through the common problems that cause the project to fail.
These open ended questions are designed to guide your preparations:
How will a rewrite solve your users’ pain?
Where is the current system failing your users? How will a rewrite fix those problems? You and your fellow developers may hate the current codebase, but that isn’t a compelling argument.
Clients don’t want the Next Generation of your system.
Are there really no incremental improvements?
Now that you know what user pain you are trying to solve, is there really no way to resolve the problem in the current codebase?
If the system is slow, is there really nothing you can do to make it faster? Maybe a rewrite would make things so fast that users won’t notice any lag. But if a refactor would reduce frustrating lag by 50% in a month, you should refactor.
Once you’ve focused on your client’s problems, reducing pain today is preferable to fixing the problem 6 months from now.
Do you have to recreate the existing system before adding new features?
After bugs and latency, the number one issue with old codebases is that it’s hard to add new features. The original code was designed to expand in one way, and now it needs to expand differently. A rewrite will let you design a system to meet those new requirements.
What about a new system that is nothing but new features? Can you find a way to make a new system that is a client of the old system?
A rewrite requires you have to recreate all the features of the existing system before adding the new features that create new business value.
How will you ensure that the new system doesn’t have the same problems as the original system?
The forces that caused the original system to go off the rails are going to work against the rewrite too.
Management didn’t want to spend time on unit tests? They still won’t.
Constantly changing business requirements? Just wait until the demands aren’t constrained by the existing code.
Inadequate resources, logging, metrics and other tools? A rewrite won’t make any of that better.
After a brief honeymoon a rewrite will face more pressure than the original system. You need a plan to keep all of those external forces at bay.
What’s the release plan?
Replacement is not a release plan. How is the rewrite getting into production? Can you find a way to run the two systems in parallel? Can you replace things a piece at a time?
You will have to release the new system eventually. “When it’s done” takes forever.
Conclusion
When you propose a rewrite, you need to be able to answer these questions to your teammates and managers. Bringing the questions and answers up in your initial pitch will show that you’ve thought things through.
Don’t proceed until you can answer all five questions! You just might happen to discover an alternative to a total rewrite. Even if you don’t use it, you can move more confidently once you can speak to the alternatives.
