Article originally posted on InfoQ. Visit InfoQ

According to Marijn Huizenveld, discipline is key to preventing accumulating technical debt. In order to be disciplined you should make it difficult to ignore the debt. Heuristics like fixing small issues immediately, agreeing on a timebox for improvement, and making messy things look messy, can help tame technical debt.

Marijn Huizendveld spoke about taming technical debt at OOP 2023 Digital.

To prevent the accumulation of technical debt and foster discipline, Huizendveld suggested using a highly visible area to show the debt inventory:

In the past, I’ve made enemies in the short term, both within and outside of the engineering community of organisations, by featuring the technical debt board prominently in the hallway. It was positioned in such a way that you could not get around it, literally. That is confrontational, because it shows where the organisation is failing, but all you do is make a problem apparent that is already there.

It takes some time to adjust for various roles that feel a responsibility towards the underlying causes, Huizendveld said. In the long term, high visibility results in frequent conversations about the tech debt inventory and what you are doing about it as a software organisation, he added.

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, Huizendveld said.

Not having any technical debt means liquidity, and liquidity means optionality, Huizendveld mentioned. People have a bias towards preventing losses, called loss aversion in bias literature. You can leverage this bias to provoke change.

Huizendveld provided some heuristics that have helped him tame technical debt:

• If you can fix it within five minutes, then you should.
• Try to address technical debt by improving your domain model. If that is too involved, you could resort to a technical hack. In the event that that is too involved, try to at least automate the solution. But sometimes even that is too difficult; in this case, make a checklist for the next time.
• Agree on a timebox for the improvement that you introduce with the team. How much time are you willing to invest in a small improvement? That defines your timebox. Now it is up to you and the team to honour that timebox, and if you exceed it, make a checklist and move on.
• Don’t fix it yourself, if it can be fixed by machines.
• If it is messy because you have a lot of debt, then make it look messy. Please don’t make a tidy list of your technical debt. The visual should inspire change.
• Only people with skin in the game are allowed to pay off debt, in order to prevent solutions that don’t work in practice.

Huizendveld suggested leaving alone areas that are stable. You don’t need to improve something that does not get changed, he argued.

InfoQ interviewed Marijn Huizendveld about dealing with technical debt.

InfoQ: How much technical debt do we typically see in software development?

Marijn Huizendveld: There was research done by Stripe Inc. in September 2018, described in the research paper The Developer Coefficient, which stated that “given an average workweek of 41,1 hours, developers spend circa 13,5 on technical debt, and including bad code it’s 17,3 hours.”

If you consider that the remaining time of 23,8 hours has to cover all the meetings and ceremonies that relate to planning work to be done, then you could infer that there is really not a lot of time left for actual work. Even if the numbers reported by developers on the impact of technical debt are exaggerated by 50%, it’s still a sizable amount.

InfoQ: How can we measure success in dealing with technical debt?

Huizendveld: There are a bunch of indicators:

• Team happiness should improve: track how people feel with a simple smiley rating, and use the answers to figure out if you’re on the right track. If people are frustrated because of the toil due to technical debt, then you know what to do. If people are happy because of the reduction of this toil, then you know doing more of it will bring even greater happiness.
• Unplanned work should go down: there is a reason why a shortcut is called a shortcut: it is not a thorough solution. In some cases, unplanned work is the consequence of shortcuts having a meeting with reality. This hinders the throughput of the team, because planned work has to be halted, to deal with the issues that are occurring in the production reality.
• Mean time to bug resolution should drop: there is a large category of technical debt that could be classified as technical debt in work processes. It’s the debt that hinders making changes to the system in the quickest way possible. For example, manual, error-prone steps to get the software into the hands of the users. When this category of technical debt is reduced, fixes are in production orders of magnitude quicker. On top of that, there is the fact that a lack of technical debt in the business logic makes it easier to address bugs, because the system behaves more predictably.
• And finally, your time to market should shorten: In the end, it is the cumulative effect of all of these small improvements that make the big improvement reality. Faster time to market is the compound effect of happy teams that can focus on the planned work without distractions, in a system that works for them, not against them.