Rewriting software is not a light decision
It's not just the cost you imagine
Developers have a curse that has haunted us since time immemorial and that harasses us with its dreaded consequences. This curse haunts our code and adds changes without us noticing, turning our software into a huge ball of mud.
This ball of mud (for which we are obviously not responsible 😂) increases the complexity and coupling of our system and makes it increasingly difficult for us to make changes.
It is in this desperate moment when we have to make a decision and we are presented with two options in front of us: fix the mess or rewrite everything.
The cost of rewriting software
Making the decision to rewrite a system is complicated and something not to take lightly. There is a very interesting article that talks about the hidden cost of rewriting software and highlights that redoing a system is more expensive than one may estimate at first.
First we have the cost we estimate the rewrite will have. We control this cost and we can know more or less the result.
Then we have the cost of reaching the current development. Normally, while we rewrite the system, the development does not stop and new functionalities are added. This extra migration cost is the second one we must take into account.
And, on the other hand, we have the cost that we have overlooked. All those functionalities that we did not know were there or whose complexity we did not fully understand. This adds a cost to the rewrite that needs to be taken into account.
The problem is that we often keep the first cost and ignore the other two, which in many cases can double the necessary development time.
Things to keep in mind when rewriting software
Therefore, we must always assume that it will take longer than our worst estimates say, since we may have any unforeseen event or hidden cost that we have not analyzed well. As Hofstadter’s law (paraphrased by me) says:
Any development always takes us more time than estimated, even if we have taken this law into account to estimate it.
On the other hand, we can have the good idea that when we rewrite the code we remove everything that is no longer needed or has stopped being used. The problem is that identifying those parts that may not be necessary to migrate is a very complicated task.
Here I always resort to the Chesterton’s fence principle, which means don’t delete something until you’re sure why it’s there.
I give an example of this with a farmer who has bought some fields that come with a fence along the road. After a couple of days of working the land and not understanding very well what that fence is doing, he decides to remove it. The next day he discovers a herd of goats eating their lettuce. The fence was there to prevent the goats from feasting on the field when the shepherd passed by early in the morning.
A fence is something expensive to put up, if it was there it was for a reason. In software the same thing happens, any part of the code is there for a reason, until you understand why, don’t delete it.
When rewriting software is necessary
I have opened the article by giving as an example the decision to rewrite our project when it has become an immense ball of mud. However, there are more reasons why it is interesting to consider rewriting our project.
- Technology obsolescence: If the current tech stack is outdated and no longer supported, making maintenance and upgrades difficult or impossible, a rewrite may be necessary to adopt modern technologies and standards. To no longer implement our systems in COBOL and FORTRAN.
- Unmaintainable code: When the existing codebase has become too complex) making it difficult for developers to understand, modify, or extend it, a rewrite can improve maintainability and readability.
- Scalability issues: When the current architecture cannot handle a higher load or user demand and scaling is not viable with the existing design, a rewrite to implement a more scalable architecture may be needed. Although here I always recommend trying to implement evolutionary architectures that are capable of adapting to new contexts.
- New requirements and functionality: When business requirements have changed significantly and the current system can’t adapt to support new features or workflows efficiently, a rewrite may be the best way to meet the new needs.
- Legal or regulatory compliance: If new laws or regulations require changes to the system that are impractical to implement in the existing codebase, a rewrite may be the only viable option to ensure compliance.
In the end, we have to assess whether a rewrite is going to provide us with a differential value in relation to the cost it may have. If the new system is going to be better suited to our business and the needs of our users, rewriting our software is a good strategic decision to make.
Conclusions
In conclusion, software rewriting is a strategic decision that should not be taken lightly. While we are often tempted to start from scratch to get rid of a mud ball that has grown over time, it is crucial to consider the hidden costs and challenges inherent in the process.
However, there are times when rewriting software becomes imperative. Technological obsolescence, difficulty in maintaining existing code, scalability issues, new requirements and functionalities, and legal or regulatory compliance needs are all factors that may warrant a rewrite. In these cases, rewriting can not only solve current problems, but also better position the system for future needs and technologies.
Finally, the key is to carefully evaluate the differential value that a rewrite can bring in relation to its cost. If the new system promises to be better suited to the business and the needs of users, rewriting is not only a viable decision, but a strategic one. When making this decision, developers must maintain a clear and detailed vision, ensuring that each step is taken with a full understanding of its implications and potential benefits.
Photo by Sandie Clarke on Unsplash