Managing your technical debt - Convincing your manager
Understand, manage and convince: discover strategies for managing technical debt in software development.
You offer to look at the files with him, to see if there isn't a faster way of implementing the requested functionality. As you look at the files, you notice the problem. The code is indeed hard to read and the business logic is scattered throughout the various files. We definitely need to tidy things up, but we have to deliver by Friday and it's already Wednesday. You find a way around the problems by vowing to add the technical debt to the backlog... The next step will be to convince your joint manager of the importance of prioritizing this task in the next iteration.
Here, in a nut shell, are the deleterious effects of technical debt. Indeed, this metaphor illustrates the idea that not only does "shovelling problems forward" not solve the problem, but that problems accumulate exponentially, like the interest on a debt.
Are there times when it makes sense to take out a technical loan? How to manage a known technical debt? How do you prioritize the correction of technical debt? Does it always have to be repaid? But first, let's define technical debt more clearly.
Understanding the metaphor of technical debt
The first time the concept of debt was associated with shortcuts in code was by Ward Cunningham1 in 1992. He described how, in order to quickly produce a usable iteration, producing immature code was perfectly acceptable, just like taking out a loan. It was important, however, to repay the debt in the very short term, otherwise you'd end up with a debt-ridden, unmaintainable code.
Today, the concept has evolved beyond code itself. Technical debt2can be described in terms of the design stage at which the compromise was made:
How do you take on technical debt?
Render unto Caesar the things that are Caesar's: Martin Fowler has written an excellent analysis of technical debt in his blog4. He came to the conclusion that there were 4 types of technical debt, which can be represented in the following table:
|
Deliberate |
Inadvertent |
|
|
Reckless |
E.g.: our introductory example |
Ex: a team lacking knowledge |
|
Prudent |
We take out a loan to pay it back quickly |
We mean well, but we'll find the best solution later... |
As with our finances, prudent debt can help us reach an intermediate goal more quickly. The idea is to pay it off quickly!
An involuntary debt is more difficult to conceptualize: in fact, when we borrow in everyday life, we are conscious of doing so, even if it's not always reasonable. Nevertheless, the idea is worth considering.
Sometimes the team is too junior to be aware that it is making decisions that will affect it in the short/medium term. This is where training and knowledge sharing come into their own.
On the other hand, a competent team may not know the optimal solution, even if the delivered product is functional and appreciated by the customer. Indeed, a developer, however experienced, will often look back at his old code and think he could have done better. This is normal, as almost every line of code is a learning experience. We're constantly evolving, and so is the market.
Repayment, with interest
You want to repay as quickly as possible, but it's not always easy or even desirable. In fact, there are a number of factors that may come into play.
The classic example is spaghetti code... which works well. Unless you know it completely by heart (and even then), you have to think not only about the time spent correcting it, but also about the effort involved in checking for non-regression. All this in the hope of not having broken any forgotten functionalities. After all, paying off a technical debt has its costs!
Yes, there is a an "easy" way to mitigate these risks5, but it does involve quite a few modifications. So let's not underestimate the importance of complete and rigorous documentation...
In any case, the problem remains. Is this the right time to repay our loan?
A pragmatic way of looking at things is to ask what the impact of doing nothing would be6. Sometimes, it's very low. Even if the code is objectively disgusting, if there's no longer any active development on it, there's more risk in paying the debt than in leaving it as it is. However, if the customer asks for new functionality, the technical debt will have to be factored into the project.
In an active project, however, it will be necessary to assess the relevance of each debt item in relation to bug fixes and other modifications. To do this, you need to consider that the velocity of modifications is impacted by technical debt. Beyond the cadet method*, i.e. always leave the code cleaner at the end of your work than at the beginning, is to look at how much the code will degrade if you do nothing, and how much it will harm you, always taking into account the impact of the modification on the rest of the development cycle.
These rules of thumb are very useful for known (often voluntary) technical debt. But what about unknown debt - other than ignoring it, of course? The easiest way is to go through the entire code of a project and analyze the sticking points, the over-coupled classes, the problem areas and prioritize them according to the degradation and nuisance criteria seen above. Today, there are automated methods for detecting problem areas, such as SonarQube, Coverity, Snyk Code, Cast or CodeScene7. Code reviews are also a good time to notice existing technical debt.
In conclusion
1 The WyCash portfolio management system
5 https://www.kuriosit.ca/travailler-avec-le-legacy-code/
6 A Framework for Prioritizing Tech Debt - Max Countryman
7 How to Measure Technical Debt: Step by Step Guide
*The author was in the Air Cadets, not the Boy Scouts, which is why she renames the rule Uncle Bob. It's exactly the same concept.