I’ve got an oddly satisfying feeling when I think of rewriting code from scratch. It’s time to make things right. I can finally fix all those problems with the architecture all at once. I will no longer suffer from previous mistakes. It feels so good!
All engineers must have done that at least once in their career. In many cases, it is inefficient if you think about the time you spent rewriting the code and the number of new bugs you created and old bugs reintroduced. Let’s first understand why the decision to rewrite the code feels so right at the moment.
- Writing code is easier than reading it.
- Existing bugs seem more important than fixed bugs.
- It seems impossible to change the architecture in-place.
Writing code is easier than reading it
I’ll try to represent it visually.
Understanding the existing code requires effort (surprise). Especially if it’s not yours. And if the person who wrote it saved time on typing proper variable names.
In the codebase of my previous company, the button on the website was named “ThisFuckingButton.” The reason is that it did not work as expected, but the bug was not customer critical, so an angry developer wanted to warn future developers by giving it this name.
But even if the existing code has a good quality, it’s still hard to understand. You need to absorb the whole system by analyzing many separate pieces of code. When you write the code, you first model the system in your head and then add pieces of code that build on top of each other. That’s way easier.
Existing bugs seem more important than fixed bugs
Usually, the reason to rewrite the software is that it’s too full of bugs. It’s hard to fix them one by one, so it may seem like a good idea to write the new code, so it does not contain bugs… Wait a second, code without bugs?
Every code has bugs. When you rewrite the code, it’s no exception. While you may focus on fixing all existing bugs, please consider that existing software was also tested and debugged at once. There are a ton of things that the previous developers thought about that you are not taking into account.
That line in the old code that uses the method of a slightly outdated library may not be a mistake. Maybe it is essential so the program can run on some version of Windows. But you’re going to find out about it later.
It seems impossible to change the architecture in-place
When it’s hard to add the next feature to the software product – the code calls for refactoring. Sometimes it’s just a matter of rearranging functions in the module. Other times there is a more fundamental issue in the architecture – that’s when it’s tempting to start the rewrite.
Architecture mistakes are very real. It’s impossible to predict everything that is going to happen with your software in the future. So we start simple and then make it more and more complicated. But incremental changes will always add to the initial design. They can’t replace it.
Rewriting code is rarely a good idea
It seems like we like to start things from scratch because of our cognitive biases. If you really think hard about the implications of rewriting the software, there are of downsides:
- You’re throwing out prior knowledge. This is especially critical for large scale commercial applications where people spent years creating it. You’re going to reintroduce a bunch of bugs that were fixed before. Also, you probably don’t all the people on the team that wrote the initial codebase, and there is reason to think the new group is better at writing this application.
- It’s more time-consuming than you think. Refactoring the large codebase is a daunting task. While comparing it with the potential time needed to rewrite everything, it seems like the rewrite is faster. That is because we don’t think about bugs we will reintroduce and do not include that time into the estimate.
The decision about rewriting code is yours
Sometimes to rewrite is the right decision. If the software has been written pretty recently and there is a significant change in the architecture that you need to make – go for it. That happens a lot with MVPs in startups. Engineers create the first version, so it “just works.” If it proves to be somewhat successful – then it’s time to design something more complicated for the long term.
However, be aware of cognitive biases. Don’t throw out code that other people worked hard on previously without thinking.
If you enjoyed this article, we have more. I’m the co-founder of https://www.seamlesscloud.io/, and our team of 3 engineers writes from time to time on different topics related to software engineering. You can read more of our blog here.