6.11.2017

When Code Starts to Smell Bad, Should You Improve the Existing Code or Rewrite It from Scratch?

When Code Starts to Smell Bad, Should You Improve the Existing Code or Rewrite It from Scratch?
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.


  • (Image credit: http://www.monkeyuser.com/2017/refactor-man/)

  • 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 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.

    (Image credit: https://blog.daftcode.pl/hype-driven-development-3469fc2e9b22)

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.


    (Image credit: http://www.ben-morris.com/why-refactoring-code-is-almost-always-better-than-rewriting-it/)

  • 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.5

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.



Related articles
What works well and what you should be aware of while working with TensorFlow. READ MORE
Learning methods go through tremendous changes. Right after the e-learning and video tutorials boom, another technology emerged that promises to revolutionize the way we share information. Find out why there is such hype around augmented reality and how it can transform your business in terms of training and knowledge retention. READ MORE
Retrospective meetings are a great occasion for generating insights and ideas to improve workflow efficiency. Sometimes such improvements start travelling from one project to another and become best practices eventually. We want to share our top 7 tried and tested retrospective findings - hope they come in handy for you as well. READ MORE
For tech professionals, staying up-to-date is more than a natural curiosity, it’s a must. How to be wired up without spending too much time on it, and what blogs to follow - further in the blog post. READ MORE
Smooth collaboration and effective project management are crucial for software development. No wonder there are so many approaches and tools designed especially for software project management. And whereas there is no single cure-all tool, you might find our experience in using the following tools helpful! READ MORE
Inspired with the idea to improve the reliability of computer object detection and eliminate the necessity to handle it manually, we initiated a proof-of-concept project on automating microbiological analysis with the help of deep learning for one of our clients. After few rounds of the meticulous testing, we are happy to share the outcomes. READ MORE
The role of a CTO involves constant challenges. And a product release doesn't mean a retirement for a CTO, but a new mode of working and new issues to be prepared for. Check out these top 5 challenges that every CEO of a growing company might face and our tips for handling them. READ MORE
When there are so many examples of tremendous success done by pioneers of certain technologies, the fear of missing out becomes quite reasonable. Don’t miss out two biggest trends of 2018 (from our perspective) and learn how your business can respond to them by reading this blog post. READ MORE
A university-industry partnership is a win-win deal that gives a competitive advantage for both parties. Read more about our experience of collaborating with a university and how we benefited from it - in this blog post. READ MORE
The transition to Scrum is an exciting learning experience for everyone involved. However, it might be overshadowed with human skepticism and doubts. Read more to learn what challenged to expect during the Scrum adoption and how to avoid them. READ MORE
Changing the way how people used to work might be quite a pain. And doing it by introducing Scrum is not an exception. If you’re considering to adopt Scrum or started the transition process already, this blog post is for you. READ MORE
Bringing together people to work on the same project from different locations is becoming a common practice. But distance and lack of physical connection take its toll and may bring impediments to the workflow. After 7 years of experience in setting up distributed teams using Scrum, we cut our teeth on the possible pitfalls and collected several rules to make things work... READ MORE