Recently, I had to work on an old C++ builder 4 (1998) application. The IDE couldn’t be installed anymore on Windows 7, there were global variables and singletons everywhere, client-based compilation directives, no separation between UI, business logic and data layer, no class isolation, memory leaks all over the place, compiler failure as soon as the source code got too big, dependencies on obsolete COM objects, etc. A nightmare. It looked like the perfect example of an application that should be rewritten from scratch, and it made me wonder when is it a good time to completely rewrite a product ?
Short answer : Never.
That’s an overly simplistic answer, yet it’s a good rule of thumb : never consider rewriting an application from scratch, unless you don’t care about money and your goal is just to improve your coding skills.
As a developer, I do know that this sounds innacceptable, that some applications are so poorly coded that they beg for a rewrite. But most of the reasons used to justify a full rewrite are not valid from a business point of view. For example :
- “Code is a mess !” : So, it’s supposed to take less time to rewrite everything rather than just refactor the concerned messy part ?
- “Adding new features would be way cheaper with a new architecture.” : what are the chances rewriting the whole application costs less than adding the features to the code as-is ?
- “Technology is totally outdated !” : The new tech better have great benefits to compensate the cost of the rewrite !
Those justifications for a rewrite are valid concerns, developers just tend to underestimate how risky a product rewrite is for a company : you know when it starts, never when it ends. Meanwhile, no value is added to the product, and competitors can use the time spent on rewriting the same features to take the lead.
A full rewrite is usually considered when a company is in a bad situation : it can’t keep pace with its competitors or customers requests, and the development team keeps repeating the reason is the technical debt (the legacy of the previous generations of developers, of their skills and technical choices). Rewriting from scratch would allow them to restart from a solid base, hence enabling them to deliver features faster. Seems logical, no ? Not so much indeed :
- Halting all developments to rewrite the product will most likely worsen the situation.
- Devs are comparing apples and oranges. They are justifying the rewrite cost by comparing the time required to add a feature to a well known messy code, to the time it would take to add it to an hypothetical great, easy to maintain code. See the glitch ? And that’s not even including the cost of rewriting the whole app before adding any valuable feature.
- Devs are overly optimistic about the cost of the rewrite. They assume they have a better understanding of the technology/domain/requirements now than when the code was written, or that they are more skilled than the previous teams. That’s usually wrong. They will eventually realize it, once the first deadline is missed… That’s human nature : when judging a work, we tend to simplify the problem and to forget the constraints at the time it was done. It’s easy to assume one had done better with an inifinite amount of time : a chimpanzee would eventually do better with no time/cost constraint.
Moreover, what kind of feedback will you get from your customers when presented with the new app ? They won’t appreciate the (eventually not so) shiny new code, they won’t notice the features that used to work and are still working despite having been totally rewritten, they will only notice the new bugs, or the missing features they were the only one to use but that they loved. Prepare for a crisis, and for the maintenance of two applications instead of one. Not such a great way to reduce development cost…
When rewriting from scractch, you will lose all these field-detected-bug fixes, all these small features which look like nothing in the big picture, but which together reflect the complexity of your application as much as its value to your customers. Your brand new design will focus on simplicity, and will get rid of good and bad stuff together.
That doesn’t mean you should never rewrite code, you just almost never rewrite all of it at once.
Keep in mind the Pareto principle : 20% of the features are used 80% of the time. Do you really want to rewrite these 80% which are barely used but which still give value to your application ? Better to focus on the 20% which are probably responsible for the largest part of your maintenance cost.
I said that you almost never have to rewrite an app from scratch. What are the cases in which a full rewrite should be considered ?
The main reason is probably the human factor :
- Your current developers are running away from this code, and new ones resign after a few months… It is such a mess that developers feel that whatever they do, things break. Each refactoring attempt causes a collapse of the whole application, and keeping the code as-is just seems insane.
- The technology is so outdated developers feel trapped in a dead-end, wondering where their career will go after a couple of years spent on a technology no one has been using anymore for the last 15 years… What is hot today will be common tomorrow, and obsolete the day after. Devs know that, and the same way a manager would be reluctant to hire a dev whose experience is based on 20 years old tools, devs are reluctant to work with tools that don’t increase their market value.
The Human factor may be really frustrating because the requirement for change is not coming from customers, but from within your company. But managers should keep in mind that a product is dead if there’s no one to work on it, or if the ones working on it are developers who couldn’t find any other job or are just waiting for a new opportunity to leave the company.
Other reasons, more technical, that could justify the rewrite :
- Current technology doesn’t allow you to implement a feature that is or will become indispensable to your customers. Ex : customers need your Window MFC application to run on their iOS/android tablets, or they don’t want anymore to manage a heavy client application.
- The product is victim of its success. It wasn’t designed for its current load/user base. Google rule of thumb (can’t find the reference) : rewrite the application when its load/user base is 10 times the one it was designed for.
So let’s say you go forward with the rewrite, what conditions must you satisfy to avoid a failure ?
- You must have full support from your hierarchy. If your team tries to do it as a side project, during its spare time, you’ll never achieve it. If there’s no clear comprehension of the risks and the required work/resources, the projet will fail.
- Go incremental. That will be more expensive, but you will have more control over your planning, more flexibility to deal with unexpected issues when they arise. But then, it’s even more important to have full support from your hierarchy. Because it’s easier for the uper layers to lose focus, deprioritize the refactoring effort, so that you end up with something half baked. If it takes too long, technology also has time to change, team may change and reject the work of the previous one.
- Estimate the work to rewrite the software. Then evaluate the numbre of man/year invested in the existing software. You’ll often find a ratio of at least 1 to 10 : your devs estimate it will cost 10 times less to rewrite the app than it originally did. That’s quite unlikely.
Eventually, it boils down to money. Developers tend to see the technical side only. But if rewriting an application doesn’t give your company any competitive advantage, and that no ROI should be expected before years, there’s little reason to do a rewrite.
Want to read more about this ? Here are some great answers from people who know more than I do :
- An old blog post from Joël Spolsky, but which is still a reference
- A great answer on SO