How to get management to embrace technical debt

“The manual won’t let me refactor my legacy code!” Common situation? Terribly annoying. Most developers, sooner or later, face a manager who is not at all interested in improving what is already ready. They either need to implement something new, or urgently put out the fire, or fix some bug … In general, they will always find a reason to postpone the refactoring of the running code base.

And even when you try to explain to them the benefits of having a neat code, they either don’t understand or don’t want to understand. They only have costs and time in mind, and nobody cares about quality. And it turns out that you are absolutely powerless to do something about technical debt, which is still accumulating and accumulating. Programmers work for prod, and prod – for impatient user requests. Nobody will pay for refactoring. The situation looks hopeless.

In such a situation, many smart developers simply pack their things and leave the company. And very soon, due to the turnover in the department, the doors are no longer closed: some leave, others come …

Managers are not programmers

The solution to the problem is to communicate to managers what impact poor code quality has on the business. Ultimately, the company’s activities are aimed at making money. Arrived. Accordingly, management is looking for the best ways to cut costs and raise revenues. This means that in order to rehabilitate refactoring in their eyes, they will have to speak their language.

I happened to work as both a technical lead and a consultant, so I have a lot of experience in this business. Let’s share with you some templates.

Five arguments you can give

1) “Refactoring will help reduce the volatility of marginal costs per unit of software functionality”

This is an accurate quote from the wonderful speeches by J. B. Reinsberg at the conference “Economics in software development”. Wait, don’t go! Everything that is said here, you know perfectly well, it is simply formulated in an abstract, abstruse spirit.

Let’s go in order:

• “Refactoring will help reduce …” – so far, everything is fine
• “… volatility …” – in other words, unpredictability
• “… marginal cost …” – that is, how much resource will be required to produce another additional unit
• “… Per unit of software functionality” is a feature that has value for business. Hooray! Business value is exactly what we need.

All five arguments are based on the same general idea of ​​translation from one language to another, which we often neglect in dealing with people far from the IT sphere. Don’t use slang, lean on concepts from economics and business – that’s the whole secret ingredient. This will help you establish a connection with your management faster.

2) “Over the past month, 63% of the development resource was spent on fixing problems with product quality”

Well, substitute your numbers here. The point is to back up the message with quantitative data. Tech debt can’t help but impact your day-to-day work processes. Can you prove it? Of course!

Here are a few metrics you can look at:

• Changing the pace of work over time. How many items from the list do you manage to process in a sprint? Has this number begun to decline recently?
• The number of bug reports that the team receives in a week, as well as the number of bugs fixed during the same period. Does it turn out that bugs are piling up? Are you spending too much time on them?
• The number of emergencies that you face in a week. Will the team be able to cope with such a number on an ongoing basis? Are the cases of their occurrence increasing?

Show the management exactly what the bad code quality is for them. Better yet, find a way to convert those numbers to monetary value.

I once attended a post-mortem bug that could have been avoided if data type checking had been done. The code was written in JavaScript. At that time, there was a debate in the company about whether to switch to TypeScript.

The developers who understood what had happened were not too lazy to raise the data and were able to assess the damage that the bug caused to the business. It turned out that in the few months of its existence, the bug sucked a million Canadian dollars from the company. Million! That alone would have been enough to offset the cost of switching to TypeScript.

Based on this, it was decided that the new services will be implemented in TypeScript, and for the most important ones, data types should be checked retroactively.

3) “From a technical point of view, we worked on credit to get the product out faster. Now we need to pay off part of the debt so that the time to market does not increase. “

Again: we speak the language of the interlocutor. Metaphors can be very effective when you need to convey a message: they connect unfamiliar concepts with familiar ones for the listener and thus help to understand them. The concept of “credit” is well known to any manager. And “technical debt” itself is also a metaphor that has received wide circulation.

Or, let’s say, imagine a company as a restaurant and the codebase as its kitchen area. As dirty dishes accumulate, serving an increasing number of visitors becomes more and more difficult. Employees need to have time to wash the dishes between meals.

4) “If you invest 10% of your work time in code quality, your turnover will drop dramatically.”

So far, we’ve talked about the obvious consequences of poor code quality. But there is one insidious thing that’s easy to overlook: turnover.

Companies these days have a hard time keeping developers, especially talented ones, on them. If such a person ceases to enjoy work, it will not be difficult for him to get another offer and just go wherever they look, away from eternal chaos. Why, maybe you yourself are already looking around in search of something better …

Now let’s ask ourselves: what does it cost a company to replace a resigned developer? A new specialist needs to be found, guided through the hiring process, brought up to date. It takes investment, takes time, and slows down the entire team. Management would definitely prefer not to do such a reshuffle every year. Therefore, reducing fluidity can be a serious argument. And the very fact of having a plan to eliminate technical debt will immediately give the whole team +100 motivation.

5) “If you invest 20% of the resource in refactoring, FRT will be halved and ROI will be positive for developer productivity”

FRT is response time, an important metric for customer support. Business strives to ensure that customers are satisfied with everything.

Here we do the following:

• Choosing metrics that have a lot of weight in technical support;
• We find a couple of problems that arise regularly and require developer intervention;
• We offer a plan to reduce the number of calls to technical support by eliminating the root cause.
• If these kinds of problems are resolved, developers will be less likely to be involved in customer support tasks. That is, they will free up more time than was spent on refactoring, which means that the investment will pay off – that very positive ROI.

Ultimately, they decide

Nobody can argue with that. I have offered five arguments to convince people of the importance of eliminating technical debt, but now I think there is one more piece of advice that needs to be given before you go to work on a manager.

Refactor as you go

Refactoring should not be seen as a separate phase of work on functionality. After all, you still cannot predict in advance what features will be implemented in the future. This means that you need to adjust the code base for new realities as they become available. This is also part of the work necessary to create that very material value – any professional developer will confirm this.

The rule works even for databases with legacy code. Well, okay, you will definitely not bring her into a divine form by tomorrow. And trying to do large-scale refactoring in-between is a dead issue too. But with this approach, the situation, at least, will not worsen. And when working with lrgacy code, you have to focus not on “good”, but on “better”.

Are you fixing a bug? Spend an extra hour writing an automated test. Are you getting ready to roll out a new feature? Take an extra day to clean up the code. Try to make the change painless day after day. After a few months, you will notice that this habit has had a huge impact on your productivity. Do you know why? Because refactoring helps reduce the volatility of marginal costs per unit of software functionality.