Avoiding technical debt disasters

Technical debt is not just duplicated code, large methods and other "code smells" that can be found with static code analysis tools, but includes things like bad architecture, unsupported technologies, lack of automated testing, performance and scalability problems - basically anything that should be fixed now or likely has to be fixed later, often at a higher cost. The more technical debt you have in a system, the more costly it becomes to change it, but you are also more likely to have quality issues, like poor reliability, security and performance.

The debt metaphor is used to show that some technical debt can be intentional; You can take a shortcut to gain speed in the short term, but over time you will have to repay that debt or deal with the consequences. However, most technical debt, by far, is unintentional. Usually, technical debt comes from things like bad prioritization (“we don’t have time to do this properly”), bad design or implementation (“i don’t know how or can’t be bothered doing this properly”) or unrelated circumstances that can't be prevented (e.g. new business requirements or technology changes). Because of this, it is tempting to just talk about technical risk, rather than technical debt. However, the debt metaphor is useful to underline that the problem will get worse over time, if not managed properly.

So how do you avoid development grinding to a halt, or worse, actual disasters due to technical debt? (See Chernobyl and Boeing 737 Max.)

First, a development team can prevent technical debt by making good design choices in terms of technology and architecture, discussing and mitigating risks before implementation, following a common coding standard, and performing pair programming or code reviews.

For technical debt that is not prevented, the development team has to be able to identify technical debt automatically by using static code analysis tools, but also manually during pair programming or code review, and as part of other processes like retrospectives and incident reviews.

When technical debt has been identified and it’s not resolved immediately, the development team has to document that technical debt in the same backlog as everything else to ensure that it becomes part of the normal prioritization and planning process. When the technical debt is documented, it should be analysed and given a risk score. How likely is this to cause trouble, and what is the impact? (If multiple teams use the same scale, this is a good way to get a good overview of the most important technical debt across an organization.)

To avoid spiraling out of control, the development team has to monitor the amount of technical debt over time. They can do that by looking at the sum of risk scores over time (see bottom image), and by looking at metrics in static code analysis tools like SonarQube.

Significant technical debt should be made visible to stakeholders, especially if it helps ensure time or resources to repay it. The risk scores should be used to determine what should be paid down next.

The standard in our industry is to dedicate 20% of the team’s capacity to pay down technical debt, or more if needed. But in addition, development teams and their stakeholders should consider agreeing to a technical debt cap, a threshold which if crossed, means that the team will not spend time on anything other than repaying technical debt.

I hope that was useful. Leave your thoughts in the comments.