Software should be improved and refactored constantly. This habit helps keep code fresh, flexible for any changes, and up-to-date. If you wait until one small modification causes plenty of bugs in the whole system, or until nobody can explain what parts do what – it is already too late to get off easy. And sadly, this is often the case.
At this stage, development becomes painful and time-consuming, and the debate over “what to do now?” starts. Fueled by developers’ claims “the code is a mess”, “we can’t work with the legacy code”, “let’s rewrite it” from one side, and the business trying to solve the issue less dramatically – from the other, the debate seems to be never-ending.
And here is the bad news – there is indeed no definite answer to it. Every situation merits thoughtful consideration in order to find the best-balanced solution.
In this blog post we will guide you through potential pitfalls while deciding whether to improve the existing code (by refactoring, running unit tests etc.) or rewrite it from scratch.
Time and cost assessment
Obviously, you need to choose what’s more financially wise for the business. Estimate and compare the following scenarios:
- Time and costs of improving the existing code.
- Time and costs of rewriting the code from scratch.
* If the existing software has been released, think of its users. To keep them loyal and satisfied you will need to maintain and develop the existing system while rewriting it at the same time. Working on two versions of code will require huge resources. Remember to add them to this estimation. - Time and costs of adding new features to the existing system vs. to the rewritten version of it.
However, the story doesn’t end there. Every path has specific factors to consider that might eventually alter the initial money-based decision.
Improving the existing code
The rule of thumb is that improving the existing code should be preferred over rewriting it in a majority of cases. And there are solid arguments for that:
- The code can be improved on the fly while the whole system stays functional – so there is no risk of losing the market, the product stays always market-ready.
- While improving the code you don’t lose all the knowledge accumulated in the past. You see, no matter how messy the software might seem, if it works, it means that all this mess is actually a result of numerous bugs fixing. And all these bugs were identified by real users within the long period of time. Write it from scratch and you will need to deal with the new bugs all over again.
However, while considering to improve the existing code, keep in mind the following:
- Reading old/somebody’s else code isn’t that fun as creating the new/your own one. So be prepared for resistance from the developers’ side. If the project is long and painful, it can demotivate developers or even become the reason for them to quit. Not cool when good developers are so hard to find and recruit. Be careful not to end up with the bunch of bad developers and constantly fluctuating juniors.
- If the software needs a tech upgrade (to stay compatible with related platforms, hardware etc.), it might be difficult or even impossible to do without rewriting the code from scratch. Especially if the system is complex and monolithic. In this case choosing to improve the existing code means you will be stuck with the obsolete technology.
* This risk doesn’t apply to microservices or systems that function through separate modules, that can be changed, updated, rewritten independently from other parts. However, it doesn’t mean that avoiding monolithic architecture is a cure-all also. You need really great architectural skills to design and operate such kind of system. Besides, for some applications, it’s better to be monolithic.
Rewriting code from scratch
Joel Spolsky provided brilliant arguments that should make you think twice before choosing to rewrite the product from scratch. Indeed:
- Don’t rewrite just because it’s difficult to understand the code.
It’s natural that developers prefer to rewrite rather than to try to understand and fix the existing code. But it’s not a sufficient reason to go for a rewrite. - Don’t rewrite because of the hype about the new technologies.
Developers have a craving for new technologies (read more about it here). Often being blinded with Hype Driven Development syndrome they opt for rewriting just to try the trendy tech stack, tools.
Nevertheless, there are situations when rewriting is indeed a better choice. For example, when the software comprises a monolithic system built upon the obsolete tech stack, that cannot be migrated, while management of the product foresees a relatively long life for the product. Or when the software was developed through a long time with no refactoring done and architecture was not prepared to cope with the complexity of the system, no or poor documentation available and nobody able to explain it. Or any other cases when improving the existing code costs more than rewriting it.
While considering to rewrite the system from scratch take the following factors into consideration:
- Be aware of developers’ biases.
When deciding to rewrite the code using the new tech stack, make sure it will really benefit a product in a long term, not just satisfy the Hype Driven Development cravings of your team, as we pointed out above. At the same time, remember about “childhood diseases” of new technology and its learning curve. If you expect predictable results in a short period of time, it might be better to stick to the proven tech stack.
So, try to keep the balance between making developers happy and choosing what’s best for your business needs. When in doubts – get an external opinion on the tech stack suggestion. - There should be a reason to believe that you are going to do a better job than you did the first time and the new system will offer new value to users.
- If the existing software is in use, think how to keep the market position while rewriting the whole system. As we mentioned, to do that the old code will still need to be maintained and developed together with the new system being written from scratch.
- Be ready to new bugs appearing in the rewritten software and customers complaining: “Hey, you had fixed that before and now it’s broken again”.
- When possible – make changes incrementally. There is a big temptation to make wide steps once it’s decided to create a system from scratch. But rewriting a big project is riskier. Check if changes can be introduced incrementally, with no harm to the overall architecture of the new system, to mitigate the risks. If in doubts – better seek professional unbiased advice on the best suitable path of rewriting.
As you see it’s pretty complex topic with so many factors and details to consider. In the end, it’s always a compromise between various stakeholder interests.
We hope this blog post will help to shape your mind. In case of any questions – feel free to contact us via m.kasprzak@neurosys.pl.
