How much does it cost to refactor an application into production?

The right question is:

How much does it cost you NOT to refactor an application into production?

While solving some blocking bugs for one of my clients in the banking industry, I discovered code that needed refactoring.

No problem at first glance, right?

Indeed, it is not so complicated to take a complex function and break it into smaller methods.

Also, it is not very difficult to respect the DRY principle (Don’t Repeat Yourself) and turn the repetitive code into methods.

Admittedly, it is not the easiest thing to do, but it is doable for a Senior Developer.

When is it hard to do that?

If you have an application in production, refactoring code will become very challenging.

Why?

Because once the application is in production, the risk of damaging something is very high - and that can lead to serious business losses.

Why is the risk so high?

Throughout my experience as a programmer, I have noticed that a simple equal sign can affect an entire application flow.

If you want to compare two elements in Javascript, you can do it with == or ===. The difference is that === also checks if the compared elements have the same data type.

Specifically, in Javascript, "21" == 21 is true, while "21" === 21 is false because the data type is different ("21" is a string in Javascript, and 21 is a number).

The best practice in Javascript is to use ===, and this is exactly what I used, but it broke an application feature.

It is hard to intuit all these details at first glance, for example, an equal sign.

Refactoring the code and doing it well takes time, focus, and experience, of course.

Let's make a short calculation for a feature that needs refactoring and which would take about two weeks.

So:

2 weeks full-time means about 80 hours x 50-60 euros per hour for a senior freelancer to do your job well = 4000-4800 euros.

Two weeks is decent for a not very complex functionality.

What are you doing now? You have several options:

Option 1: Leave the problem unresolved and hope that everything will work properly

Of course, if that piece of code never changes, you may not have any issues.

But what if you find a bug or want to improve an existing poor code?

Simple! Things get worse.

When you develop over poor code, you only amplify the problem, risking that the initial two weeks of refactoring will cost you two and a half weeks - three in the future.

Option 2: Allocate just a week of work for this, and hope that the work will be completed as soon as possible.

There are higher success chances than in the first option, but if you do not provide enough budget for this, you risk one of two things:

1. The developer will feel forced to solve it quickly and will not be able to pay attention to all side cases that may occur and deliver a stable code.

OR

2. The developer will start working on the solution, but due to high complexity and lack of budget, they will not be able to complete the solution.

In this case, you spent a week, the problem is still there, and you lost time and money.

Option 3: Allocate the budget needed to solve the problem

If you provide the necessary budget for the refactor, you can enjoy an increasingly stable application, which will be even easier to develop.

Ok, you pay 4,000 euros now, but you will save time and money for the future. This is prevention.

Moreover, if the code is clean and easy to read, the further development of that functionality or any tangential development will be much easier.

So you invest money and time in the refactor, but you will save time and money because:

1. You will prevent new issues

2. Developing over a well-written code will be much easier

3. Maintaining code will be more straightforward

The third option may have a disadvantage.

I do not want to say everything will be perfect in the case of the third variant.

What if the freelancer discovers more problems during the refactor?

If you have the budget, I recommend that you allocate it because you only amplify the three results that I have just listed: prevention, easier development, and straightforward maintenance of the code.

And if you amplify those three, you will buy your business’ time and money.

Which option would you choose?