Continuous Management of Technical Debt

Preventing technical debt from overwhelming you

Ward Cunningham’s 1992 debt metaphor helped explain that the issue with technical debt was never about its existence but the consequences of allowing it to accumulate unchecked.

We know that ‘borrowing’ can accelerate progress and writing code quickly, even imperfectly, can enable learning and delivery. The danger lies in the ‘interest’ that accumulates when a shortcut is not revisited. Over time, change becomes slower, testing becomes harder, releases become riskier and the system’s adaptability diminishes.

Technical debt remains one of the most debated concepts in software engineering. It’s often the primary ‘friction point’ between engineering teams (who want to fix it) and product owners (who want to ship new features). While almost every developer and manager acknowledges that technical debt exists, the difficulty lies in how it’s defined, measured, and managed, and in the fact that its existence forces uncomfortable conversations about trade-offs.

Continuous decision-making

In order to avoid it overwhelming us, technical debt needs to be managed, and some of the principles of Continuous Architecture (CA) can help with this stewardship. CA recognises that decisions are made continuously, not just at the start of a programme, and these decisions shape the system’s qualities. When we think through the trade-offs we are making and ensure they support the quality attributes we need to achieve, this can help us make our debt intentional and manageable. When decisions are implicit, rushed or disconnected from strategic priorities, debt invisibly accumulates.

The aim of this article, and the next, is to provide some practical techniques for understanding and managing the technical debt we will inevitably incur on our projects. Continuous Architecture gives us some tools to help do that, by making trade-offs explicit, revisiting decisions regularly and preventing debt from quietly constraining future options.

Is it debt or is it just the simplest thing that would work?

Philippe Kruchten , Rod Nord and Ipek Ozkaya, in their 2019 book ‘Managing Technical Debt’ made it clear that context matters with technical debt. It is quite nebulous and context specific; sometimes one person’s ‘debt’ is another person’s ‘simplest thing possible.’

Our technical debt matters when it stops us from doing something. Because of debt, it may become too expensive to make a change, or it might make us too slow to react to a need. The team may become too inefficient to be valuable, or it might just become too risky to update our technology.

On the other hand, if we’re not paying interest because technical debt isn’t slowing us down, causing unreliability, or increasing risk, does it matter? Well, it’s okay now, but that, of course, could change. The rate of change, available investment, business priorities, and perceived risk all affect the impact of potential technical debt.

A close-to-end-of-life product with a slow rate of change is probably not the right place to spend our limited technical improvement budget. However, it is hard to be sure. The ‘often-ill-defined’ effects of technical debt mean that the team needs to remain vigilant and be on the lookout for changing situations to predict and avoid it.

Understanding our technical debt

As types of debt typically have similar causes, levels of impact and remediation approaches, one very practical way to understand and therefore manage your debt is to classify it.

Sources of Technical Debt

As part of this activity, it is useful to think about how we ended up with the debt. Did we mean to do it, and is it under control? Or did we mean to do it, and it’s not under control? Or didn’t we mean to do it at all? Asking these types of questions helps us to improve technical debt practices going forward.

As far back as 2009, Martin Fowler came up with a useful, and now famous, quadrant to help clarify this distinction.

The quadrant is useful because it shifts the conversation away from blame. Not all technical debt is the result of negligence; it may be strategic, and some of it may just be the result of learning and evolving systems. In a Continuous Architecture context, the quadrant reinforces an important point: the goal isn’t to eliminate debt but to make trade-offs explicit. This improves learning and reduces accumulation.

‘Managing Technical Debt’ identified four sources of technical debt, which are helpful to reflect upon and, again, help us improve our management and practices to control it.

Cataloguing Our Technical Debt

An incremental, iterative approach can be used to assess and catalogue debt on an ongoing basis. This typically draws on multiple data sources, including automated code analysis, manual and automated design analysis, dependency analysis and testing and operational metrics.

From these data sources, we can build a ‘candidate technical debt list’ and associated ‘technical debt trackers’, which we can manually review and assess to build a ‘refined technical debt register’.

These debt trackers should name the debt meaningfully, describe the problem clearly, classify the type of debt, identify where it is located and explain its consequences. A simple table to capture this information is shown below:

Closing Thoughts

Technical debt will always be part of software development, and Continuous Architecture doesn’t change that reality. However, a key practice is to actively manage technical debt to prevent it overwhelming our projects.

In this article, we’re reminded of the inevitability and context-specific nature of technical debt and some practical ideas on how we can go about analysing, understanding and cataloguing it. This is the first step in managing it.

In the second part of this article, we’ll explore what to do to keep it under control.