Legacy Application – Technical debt and ROI of a refactoring

Application Legacy - Techncal Debt et le ROI d'un RefactoringWhen it comes to calculating a ROI, I keep it simple: I assume that we will reduce maintenance costs in an amount equal to the reduction of the technical debt.

It is a hypothesis that can be found simplistic and therefore debatable, but our ambition is not in numbers of an absolute and exact precision – it would be pretentious and unrealistic – but to provide to the management the elements that will facilitate its decision.
And I think that managers prefer a simple and clear hypothesis, even if not completely accurate, rather than a complex formula that is not necessarily more realistic.

I have done this exercise of calculating and presenting a ROI in my former life in software vendors (code analysis and application quality), so I will tell you a secret:

The result of a ROI is directly proportional to the complexity of the formula:
the more complex the ROI calculation, the higher the Return On Investment.

The ROI of software editors

In fact, a software vendor will try to avoid this calculation if he can, but it varies depending on the country. It is almost inevitable in the US, where the CIO or any other decision-maker can be fired overnight, so it is essential to be able to justify any software purchase in order to avoid any cause for dismissal. In our latin countries (I mean in France, Spain, Italy, …), the financial aspect is not as important when purchasing a software, and the decision process will be overally easier. The CIO will check that:

  • The value and the expected benefits justify a price that is considered reasonable and not exorbitant.
  • The cost of implementation and operation will be acceptable.
  • There is a budget for this investment.

But in the event that the CIO requires an estimation of a ROI to a software editor, you can be sure that the formula will be complex. Why?
Because the software (of source code analysis or application quality) that he is trying to sell you will also have a complex formula to calculate the technical debt, with the objective of raising it so as to scare the CIO or any other decision maker.

Obviously, the higher is the technical debt, the higher will be the return on investment.
This leads also to an interesting question, and to my knowledge never addressed: the technical debt due to software vendors.

How much time do you lose in managing bugs encountered in these softwares and causing project delays? How much do you spend on mandatory upgrades? If you install each new version and each patch, this is a regular upgrade cost. But if you try to escape it by forgetting from time to time a new version, you can be sure that the next upgrade will be more complicated, sometimes even requiring to go through one or more intermediate versions, which will be even more expensive.

How much do you spend to upgrade your environment (hardware, OS, version of database, etc.) or because the new version of the software is no longer compatible with a particular version of Unix, Windows, JDK, etc. What is the cost to you if the software vendor decides to stop maintaining it, forcing you to search for another one, potentially more expensive ?

Not only the applications that you manage come with technical debt, but also the software in which you invest. Do software vendors incorporate this technical debt into their ROI formula?

The ROI of our refactoring

But back to our formula. I want it to be simple and, in case that I encounter objections, then I will decide to add some elements that I will leave to the appreciation of the decision-makers. I prefer to do so rather than to incorporate these elements in a complex formula, which will not necessarily be more accurate because any deviation in the estimation of each of these elements will result in a larger deviation in the estimate of the ROI.

Our total technical debt is 1 283 days. An effort of 291 days to bring back this technical debt to a SQALE rating of ‘A’ level, will indeed reduce it to 992 days, a decrease of the technical debt of 22.7%.

With a rate of 18.5 days per month or 225 days per person per year, and a team of 5 people, the total annual cost for this team is 225 days x 5 people = 1 125 man / days.

A refactoring effort of 291 days in a year will represent a cost of 291 days / 1 125 total man/days or 25.9% of the cost of this team over 12 months, and therefore the annual costs of application maintenance, slightly more than our gain in maintainability equal to 22.7%.

We can say that, globally, the return on our refactoring investment occurs after a little more than 1 year, based on our assumption of a reduction of maintenance costs in an amount equivalent to the reduction of the technical debt.

Obviously, this assumption is relative: if I divide by two the technical debt or even reduce it to nothing, I will not halve the maintenance budget or reduce it to zero. But it remains credible for the proportions (less than 25%) that we have calculated.
And even if this calculation is not necessarily very accurate, what needs a CIO is an order of magnitude (6 months, 10 months, 1 year, 18 months, etc.). If the number exceeds reasonable limits, the project will not be discussed further. If it is acceptable, you can sell him the benefits he can get.

Sell the ROI

When I talk with developers on concepts such as the technical debt and how to use it to convince the management that a refactoring is needed, most of them show an extreme demotivation.

« My boss is not interested when I talk to him about correcting existing defects, the impact on the morale of the team is terrible. »

« The managers only reason at short term. If it takes an hour to implement a new feature, it’s an immediate benefit. If I say that it will take a day because I want to take this opportunity to improve this code, they start looking at me suspiciously. As if I am a prima donna who wants to have fun programming more than what is needed. »

Technicians and developers generally have trouble finding a justification that allows them to sell the idea of a one-time or in real-time refactoring, because software quality is not a goal in itself for managers.

Imagine that you are restoring an old car for someone who hopes to sell it a good price, once your have repaired it. If you offer him to buy new and more expensive rims and new, wider tires, of course he will think that you want to have fun customizing his vehicle. Unless you show him that he can make a profit.

The main objective of the management: the business value of an investment. How can you sell him the ROI of a refactoring? Answer: with a correct assessment of the impacts on the business.

Our plan: eliminate Critical defects (and Blockers) in order to bring back the technical debt to an acceptable level and ensure that it does not increase later.

This action plan focuses almost exclusively on reducing defects that affect first Reliability, so the robustness of the application, for a better user satisfaction, and not reducing defects in Maintainability which could lead to a reduction of maintenance costs. However, less risk of bugs means less cost of bug fixes, and an even greater gain in maintenance. We also know that the later a defect is found during the development lifecycle (in the production environment, for example), the more expensive it will be to correct it.

If it cost you just two hours to correct a violation to a programming best practice, and that means saving 2 or 3 days of detection and correction of a bug later, not only your ROI becomes much more interesting from a financial point of view, but from a qualitative point of view, you greatly improve the user satisfaction and the image of your department. And that is priceless.

Other points of interest, but that we will not necessarily estimate in order to avoid a complex formula:

  • QA efficiency: whenever a bug is found in QA, the code returns to the developer who must correct it and send it again to QA for further testing. The less defects you have, the less of these exchanges you have over the testing phase. Therefore: lower costs, compliance to budgets and schedules. And a respected deadline means a happy user!
  • Business value: a bug in production may result in lower performance or even in a interruption of the system, so to longer operations and greater workload for users, and users – or even customers – upset. All this can impact sales, and of course the effectiveness of marketing departments, commercial, logistics, etc.
  • Business value: the less you spend on maintenance, the more you can invest in new applications that support new business and growth of your company on new markets.
  • Improved developer productivity: some violations to good programming practices impact the development time. For example, a duplicate code means less reusability, so more time spent developing code … that already exists. And more time updating its multiple occurences in case of a change. And more risk to forget updating one of these copy-pasted lines of code, and to have a bug.
  • Better control of outsourcers: if you do an audit every 6 months, your outsourcer will not mind the quality of your applications and the drift of the technical debt, or only once every 6 months. When it is too late. If you use a tool like SonarQube with the SQALE plugin, you can automatically perform these checks every week. This is called the ‘radar effect’: if your outsourcer knows he can be ‘flashed’ at any moment, he will become much more careful.

These points are intuitively understandable by managers, for the value it represents for any company, the business and the IT department. Then, if they really want a more specific ROI that takes into account these benefits, I will have either to make assumptions (number of bugs found in production, in QA, cost of a developper, etc.), or use figures provided by research institutes (SEI, etc.). The result will not necessarily be more accurate than our simple estimate based on the reduction of technical debt.

We’ll probably have the opportunity to talk about ROI while considering our last scenario: the re-engineering of our Legacy application. See you soon.

This post is also available in Leer este articulo en castellano and Lire cet article en français.

Leave a Reply

Your email address will not be published. Required fields are marked *