Good technical debt is intentional, enables benefits for the organisation, and is controlled. Teams can use a disciplined approach for managing and repaying technical debt, for instance by using the wall of technical debt.
Marijn Huizendveld spoke about taming technical debt at OOP 2023 Digital.
We can partition technical debt into good versus bad, Huizendveld explained. Bad technical debt is the stuff that has been lingering around. The only attention it gets from the team is working around it, or fixing the fallout as a consequence of this bad technical debt. This type of technical debt limits the team, and as a consequence, the team members may feel hopeless, Huizendveld mentioned.
Not all technical debt has to be bad. Huizendveld shared that there’s a school of thought that identifies good technical debt. This type of debt has three characteristics:
- It is intentional; the technical debt is not just there because it happened to us, but because we made a conscious choice to take a shortcut
- It enables; the organisation benefits from taking on the debt initially because it allows us to generate more value
- It is controlled; we have tripwires that inform us when we are nearing the point where the interest we pay exceeds the value that we gained
Teams struggle to articulate the business value of repaying a particular instance of technical debt, Huizendveld mentioned. Many teams offer only a single way out of the bad situation, by suggesting a total rewrite of the system, rather than some small but meaningful first step:
If it is unclear what the value is to the organisation of addressing technical debt, and if the only presented solution is starting from scratch, then teams shouldn’t wonder that no budget is approved to address these lingering issues.
For managing technical debt, Huizendveld referred to the Wall of Technical Debt by Mathias Verraes. The elegance of this process is in its simplicity, as he explained:
Rather than doing a full account of all the debt you have, you start to collect data on what is hindering your progress. Each time you encounter a bit of technical debt that prevents you from moving faster, you capture it on a sticky note. You add a date to the note and you put a dot on it.
Every time you run into it again, you put another dot on that note. When the third time comes around, you have to act. You have proven that this has hindered progress 3 times, it will hinder you another 3 times, and then some more.
Huizendveld explained that the difficulty is in the discipline that you need to bring up, in order to act when you have encountered the same piece of technical debt for the third time. But acting consistently on each item will produce a radical change in your environment, he said. When a team commits to this process for at least three months: they realise a profound improvement in the ability to work with the software system:
I encourage people to try this approach and to exercise discipline by always acting on the third encounter. Introduce the process, and see how it improves your situation.
InfoQ interviewed Marijn Huizendveld about dealing with technical debt.
InfoQ: What keeps us from repaying technical debt?
Marijn Huizendveld: People will often say "the business", but in my experience that isn’t always an accurate representation of reality. Often the pressure that is perceived that keeps people from repaying technical debt is not real pressure. Teams will say something like: "That is not allowed here", but if you ask who would be the person that disallows paying back technical debt, then they tend to fail to point out the evil forces.
Now I’m explicitly acknowledging that there are organisations that keep their engineers from repaying technical debt, but in my experience, it is not as common as engineers lead us to believe. What I observe a lot when working with teams, is that many of these instances of technical debt have become so accepted, because of continued exposure to them, that teams simply do not register the problem anymore.
There is often this numbness to the pain, which is only recognized after the fact, once the technical debt has been removed. Only then the team realises how much attention was consumed by all these small issues. It’s like death by a thousand paper cuts; you don’t always realise it’s happening.
InfoQ: How should we act to repay technical debt?
Huizendveld: One of the ways to ensure that people act upon technical debt is by learning to come up with small improvements. A small improvement today is preferable over a better improvement next week.
The reason for that is that you get the compound interest of the improvements day by day, as well as a reduction in interaction effects between various pieces of technical debt. The positive side-effect is that teams learn to think in smaller improvements, which will help them with general feature work too.