To refactor or not to refactor ? That is the question.

Being a developer, there’s something satisfying about creating clean, efficient code. But let’s face it, in the real world of software development, we often deal with less-than-ideal solutions. This is where refactoring comes into play – a chance for us developers to revisit and reshape the code with the wisdom gained from the initial attempt. However, bridging the gap between the satisfaction of refactoring and its perceived value from a business perspective can be challenging.

From the business side, refactoring might seem like downtime, a time when the tech team gets paid in full but seemingly produces no tangible value. Even within tech teams, opinions on the need for refactoring can differ. Some argue for the immediate benefits, while others question using resources for what may seem like a non-productive task.

How can you estimate if a refactoring is worth your while ?

Let’s start with an example.

Picture the following situation : You are working on the development of an application that handles pokemon fights. The client requires a new feature in the application, a new “statistics” page where pokemon trainers can see how many fights each of their pokemon fought, how many they won, how much damage they do on average … To plan out how you are going to compute these metrics, you start exploring the event system of the application.

It was clearly not designed with statistics in mind. The content of the event table looks like this :

With these events, simple metrics are very complex to extract. For example, computing the amount of damage Bulbasaur dealt during the fight requires you to first find out the time frame during which the fight took place, then compare the dates at which attacks happened and finally sum the damage values.

Seeing this, you quickly come to the realization that building on the existing system would be counterproductive, and you start thinking about how you could refactor the event system in order to add information to it, with the goal of making metrics computing easier.

Now comes the hard part : you estimated that the new statistics page could be developed in 2 weeks by going as fast as possible, but it would take 3 weeks to refactor the event system, plus 1 extra week to develop the feature based on the new improved event system. What should the team do ?

You need measurable facts to make the right decision.

At that point, your head is probably full of good reasons why you should refactor the event system: “the resulting code would be a real mess”, “it would be so much more practical if we take the time to refactor the event system” … However, in order to make the right decision, you have to stay factual. What would refactoring the events bring to the project ?

Most of the time, the benefits of refactoring can be nailed down to a single thing : gaining time. If you make your code cleaner, it is easier to understand, easier to maintain, easier to build upon. Therefore, refactoring saves time in the long run. The question is how much time it saves, and how long will it take to pay off the initial time investment. Lets estimate how much time our event system refactoring would save us.

The questions we have to ask ourselves are the following :

• On what occasion do we plan to save time ?
• How much time do we plan on saving ?

Refactoring will make the future addition of statistics easier. You estimate that adding a statistic with the current codebase would take a developer 3 days of work, which could be reduced to a single day of work if the event system was to be refactored. Additionally, we want to take into account that the more code we add to the existing system, the more complex it will be to continue adding code. To represent that, let’s say that each time a statistic is added to the page, it will take 0.2 days longer than the previous one.

To visualize the cost in days of work of both scenarios, we can plot them on a graph:

Here, we see that with our estimations, the refactor would pay for itself after 4 statistics added to the page. It also shows that if we plan to add more, the time difference between the two scenarios increases rapidly. In other words, the earlier we refactor, the less it costs.

This graph is a great decision tool. It shows that if the business intends to iterate on the statistics page, then a refactoring would allow the tech team to deliver features much faster.

With this graph as a tool, it will be way easier to show other team members or any stakeholder the value that you want to provide by refactoring code. The main thing to keep in mind during this exercise is that even though priorities of the tech team and the business may seem different, they are more often than not compatible.

Both the tech team and the business share a common goal : productivity

The tech team is trying to make its life as easy as possible by keeping the code consistent, limiting coupling between unrelated parts of the app, improving developer experience … On the other hand, the business tries to get as many features as possible with the resources they have invested in the tech team. In other words, the tech team wants to spend less time doing low added value tasks, and the business wants the tech team to be as productive as possible. These are both sides of the same coin !

So, for example, If the reason you want to refactor is that you do not want to have to think about edge cases when developing new features, explain that this refactor will reduce the complexity of the codebase, which both reduces the amount of bugs and improves productivity. To base this in facts, you can look for a ticket that took way longer than planned because the complexity was underestimated, or for bugs that happened because the developer that was in charge forgot an edge case.

To wrap it up

Refactoring can bring so much to your project. It can save time, it can improve your experience as a developer by making the code easier to understand, and it can even have other various benefits such as improving the performance of a particular route, or reducing the amount of bugs that the team introduces.

However, keep in mind that software development is all about compromise. Sometimes the right thing to do is to skip a corner to meet a deadline. Sometimes, considering the time it takes to improve your code against the benefits of doing so may lead you to the conclusion that the best decision is to leave it as is. Even in cases when you figured that refactoring is the best option, the choice of whether or not your team will be allocated the necessary resources will not always be yours to make. But what you can always do is bring the factual elements in order to make sure that whoever is making the decisions understands what compromises are available to them and what the real cost of each option is.