Making the impact of technical debt visible

Technical debt is expensive: according to the Forbes article, developers waste 23–42% of their time due to technical debt. Yet, organizations keep producing it.

The business impact of technical debt is hard to measure, hence there is not so much incentive from the management to pay attention to it and actively try to reduce it. Technical debt keeps growing like a snowball:

• often, there is a lack of time/budget to do a project properly, so new projects create technical debt
• paying down existing technical debt is seldom part of business priorities -> developers are forced to produce more technical debt in existing projects due to inter-project dependencies

This paper on technical debt conducted a survey, 96% of participants indicated that business decisions lead to the creation of technical debt, of which 74% to a great or a very great extent.

The business/IT gap is an important cause of technical debt. Due to that gap, technical teams often face tight deadlines:

• deadlines get negotiated without the involvement of technical teams
• business underestimates technical effort & technical leadership agrees with unrealistic schedule

Business tends to prioritize feature over quality due to:

• lack of systems thinking
• lack of alignment between business and technical teams.

To make a change, the problem of technical debt needs to be visible throughout the whole organization, which includes higher management, not just developers and solution architects. Visibility starts with measuring things.

Measuring the impact of technical debt

A paper by Google on Defining, Measuring, and Managing Technical Debt described a way to make technical debt impact visible by conducting a quarterly interview and asking engineers about which categories of technical debt have hindered their productivity in the previous quarter. The paper defined 10 categories of technical debt, collectively exhaustive and mutually exclusive.

Next to the questions regarding the types of technical debt, the questionnaire includes questions on the ways teams handle technical debt:

- To what extent has your team deliberately incurred technical debt in the past three months?

- How often do you feel that incurring technical debt was the right decision?

- How much did your team invest in reducing existing technical debt and maintaining your code?

- How well does your team’s process for managing technical debt work?

Going through different engineering teams, conducting the interview, and communicating the results to the business would be a great start to reducing the business/it gap and making the problem of technical debt visible.

In a way, it is similar to the MLOps maturity assessment which is the first and crucial step needed for MLOps transformation. It was needed to get buy-in from the business to do the necessary changes to the way of working.

Reducing technical debt

Technical debt reduction requires a structural approach and substantial effort from both the business and engineering teams. According to Google, the structural approach should include:

• Creating a technical debt management framework that defines roles and responsibilities across different teams
• Tooling that supports the identification of technical debt. For example, having some checks in place at the pull request for test coverage, deprecated dependencies, and bad coding practices.
• Organizing courses for business/ engineering teams that demonstrate best practices for technical debt management.
• Periodical technical debt maturity assessment that identifies categories of technical debt that have the largest impact on the teams and technical debt management maturity level across the teams (Google suggests 4 levels: teams with reactive, proactive, strategic, and structural approaches).

I believe, most organizations have a long way to go when it comes to the management of technical debt. The least everyone can do is start measuring it and communicating it, this will lead to a willigness to change things. Only then it is worth to start thinking about the structural approach.