2 min read

How are you managing your technical debt?

Technical debt is a 23-year-old metaphor that has almost as many modern interpretations as does ‘agile development’. Common thinking suggests that technical debt is the result of a conscious decision made by software developers to implement a suboptimal solution for short-term gains, fully aware that the solution must be reimplemented, optimally, at some point in the future in order to deliver long-term value.

A majority of commercial software developers will be aware of this definition and will have experience of creating and, probably much less often, addressing technical debt, but there is far less undertstanding of the forms of technical debt and the strategies that teams are using for managing it.

A recently published study by the Software Engineering Institute, A Field Study of Technical Debt, surveyed ~2000 people working in software in order to answer these questions. It makes for great reading and offers some illuminating insights.

Our data and analysis strongly support that the leading sources of technical debt are architectural choices.

This highlights technical debt as a larger problem than just dealing with “bad code” that can be swiftly refactored. Notably, and perhaps expectedly, the tracking of technical debt is highlighted as a problem with “65% of respondents having no defined technical debt management practice” in place. That’s huge. Of those that do, the issue tracker is the most common tool with “social process” (read: ad hoc interpersonal communication) being the second most common practice. Unsurprisingly, one of the study’s conclusions is:

Tooling is a necessary component of any technical debt management strategy.

This is aligned with my own experience over the years: little focus on improving the tracking of debt in a software application (a document, a Trello board, a bug tracker project), and a lack of any focused effort to pay this debt down. Both are related. Perhaps our culture can be improved by introducing an effective tool and process, but what should they be? There is distant hope here, but the journey to get there is going to be a long one.

How are you managing your technical debt?