Dealing with Technical Debt

In the first part of this article, we outlined what technical debt is, how we can improve our understanding of it, its sources and how to catalogue it. Once we understand the nature of our debt and the forces that created it, we can then make conscious decisions about how it should be managed.  This is the purpose of this, the second part. You can read the first part here.  

Different repayment strategies reveal different approaches to managing technical debt, usually as a result of differing organisational contexts. Some organisations address technical debt only when it becomes acute, diverting effort reactively. Others allow it to accumulate until a large remediation initiative becomes unavoidable. A more sustainable approach allocates consistent capacity to technical improvement, addressing high-impact debt incrementally.  

Continuous Architecture advocates for this incremental model because it embeds a culture of continuous learning and improvement within everyday delivery rather than treating it as a periodic correction. The activities involved in this process are illustrated in the figure below: 

Raise Awareness 

The first step in the process is simply to make people aware of the technical debt in the system and the fact that it has consequences.  The software engineers probably understand this already, but perhaps don’t discuss technical debt much.  Other stakeholders probably aren’t aware of it and certainly won’t understand how it affects them.  So starting to talk about it and point out where it is having consequences is a good way to start raising awareness across the stakeholder community. 

Assess & Catalogue 

As previously mentioned, an incremental, iterative approach can be used to assess and catalogue debt on an ongoing basis, drawing on multiple data sources, including automated code analysis, manual and automated design analysis, dependency analysis and testing and operational metrics. 

We can then build a ‘candidate technical debt list’ and meaningfully detailed ‘technical debt trackers’, such as the example below, which we can regularly review and assess to create our technical debt register of the higher priority items we want to work on next.  

Assessing the Cost of Technical Debt 

There is no reliable way of assessing the cost of technical debt accurately. This is the same for most software development work. We must, therefore, use judgement and qualitative assessments. 

Each technical debt item can be assessed across two cost dimensions. The first is the size of the “interest”, the ongoing cost of leaving it unresolved. The second is the “repayment”, the effort required to address it. Considering both allows the technical debt catalogue to inform meaningful prioritisation. 

Planning a Repayment strategy 

Once debt has been assessed and prioritised, the next question is how it will be repaid. There is no single approach; organisations typically adopt one of three broad repayment strategies. Each carries its own cost in effort, timing and organisational impact. 

Just-in-Time 

A just-in-time approach means technical debt is monitored but not addressed routinely. The team keeps an eye on it and intervenes only when it begins to cause real friction, such as slowing delivery, increasing defects or creating operational risk. At that point, effort is diverted during a specific iteration to resolve the issue. The advantage is clarity: when repayment happens, the need is obvious. The downside is timing, as the work almost always arrives at the least convenient moment, and the cost is often higher than if the debt had been tackled earlier. 

Little-and-Often Repayment

This strategy sets aside a consistent proportion of delivery capacity (perhaps 10 to 20 per cent) for technical improvement. Debt is reviewed regularly, and the highest priority items are addressed incrementally. This tends to be the most efficient way to prevent debt from accumulating because issues are resolved before they become disruptive. The challenge is organisational commitment. Securing agreement to reserve capacity can be difficult, and during periods of intense delivery pressure, that allocation is often the first thing to be reduced. 

Cleanup

This involves no active management of technical debt on a routine basis, whether by choice or by neglect. Debt accumulates quietly until it becomes critical, perhaps through production incidents, repeated release failures or a dramatic fall in delivery velocity. At that point, attention shifts dramatically to remediation for a defined period. There are few real advantages to this approach, although it is common in practice. It typically requires a difficult conversation with stakeholders and a temporary pause in feature delivery. If underlying causes are not addressed, the organisation risks repeating the same cycle. 

Remediation: getting debt items prioritised 

Getting technical debt items into the backlog is often one of the hardest parts of managing them. Unlike new features, debt rarely presents itself as visible value, so there is usually a need to persuade a Product Owner or other stakeholders that it deserves attention.  

Where the debt introduces meaningful risk, those risks need to be expressed in business terms. Rather than describing a fragile module or an outdated dependency, it is more effective to outline a realistic scenario: what could fail, what that failure would mean for customers and what it might cost in time, reputation or revenue. If the team is already paying “interest” on the debt, that ongoing cost should be made explicit. Rework, repeated manual effort, longer testing cycles and avoidable defects all consume capacity that could otherwise be used to deliver value. 

It is also worth acknowledging the human impact. Persistent technical friction erodes morale and reduces pride in workmanship. Over time, that affects retention, quality and productivity. None of these consequences are immediately obvious to those outside the team, which is why they must be articulated clearly. Managing technical debt is as much about communication and shared understanding as it is about refactoring code. 

A unified backlog  

A unified backlog brings the different types of work the team needs to do together as a single set of trackers, with each one clearly assigned to a particular type of work.  A good set of classifications to start with is Features, Defects, Architecture Stories and Technical Debt Items. 

A unified backlog allows visibility of the balance and prioritisation of work and may help to show the need to change the balance of priorities that the team is working on.  

Avoiding Future Technical Debt 

Having worked hard to understand and start to remediate technical debt, it is then important to start putting measures in place to avoid more technical debt unintentionally piling up again in the future. A useful technique for this is the Technical Debt Retrospective. 

Technical Debt Retrospectives

Avoiding future technical debt requires more than periodic remediation; it requires reflection. One effective practice is to run occasional technical debt retrospectives. These sessions create space to step back from immediate delivery pressures and examine how debt is arising in the first place. Rather than focusing only on individual debt items, the discussion should look across the technical debt catalogue to identify recurring patterns and root causes. 

By grouping debt by type (requirements, architecture, testing or operations), teams can begin to see systemic drivers. Perhaps time pressure consistently leads to weakened testing. Perhaps unclear domain understanding results in repeated rework. Once the highest-impact root causes are identified, the conversation shifts from fixing symptoms to preventing recurrence. Concrete actions can then be agreed to mitigate those causes, whether through improved practices, clearer standards, earlier validation or changes in workflow. 

The difficulty, of course, is not in identifying improvements but in creating space to implement them. Without deliberate commitment, the actions from a technical debt retrospective risk being overtaken by the next delivery cycle. Sustained improvement depends on treating prevention as part of the discipline, not as an option. 

Communicating Technical Debt 

However we go about managing our technical debt, it is crucial that we are able to explain it and its implications to our stakeholders so that they understand why addressing it is important.

Communicating with stakeholders 

Communicating technical debt is often a real challenge. Senior leaders focus on strategic flexibility, cost exposure and risk. Product leaders prioritise delivery speed and quality. Operational teams care about stability and incident reduction. When technical debt is framed as a constraint on organisational capability rather than a development team concern, it becomes easier to get attention for it. 

Metrics can help to provide an objective foundation for that discussion. Time-based measures show impact on flow. If debt increases cycle time or reduces delivery velocity, the effect is tangible and commercially relevant. Risk-based measures highlight exposure, clarifying how remediation would reduce the probability or impact of failure. Cost-based perspectives make the ongoing “interest” visible, translating rework, manual effort and avoidable defects into financial terms. Trend data, such as defect rates, cycle time or release failures, reveals whether debt is stabilising or compounding over time. Together, these measures shift the conversation from anecdote to evidence. 

Understanding the Stakeholder Perspective 

Engaging senior stakeholders requires a deliberate shift in emphasis. The conversation should centre on their priorities rather than engineering frustration. Technical explanations about refactoring or design purity rarely resonate at executive level; business impact does. Framing debt in terms of market responsiveness, operational resilience or strategic options makes the issue relevant without oversimplifying it. 

It is also more effective to present options with clear trade-offs than to frame the situation as a binary choice. This encourages shared ownership rather than defensiveness. Above all, avoid surprises. If technical debt is becoming material, it should be signalled early, supported by evidence and accompanied by transparency about uncertainty. Credibility depends not on certainty, but on clarity about risks and confidence levels. 

Closing Thoughts 

Continuous Architecture does not promise the elimination of technical debt. I don't think that has ever happened to a successful system in the history of software development. Instead, it provides a framework for making trade-offs explicit, revisiting decisions regularly and ensuring that debt remains intentional rather than accidental. The presence of technical debt is not evidence of failure but the loss of visibility and control is. The real question is not whether technical debt exists, but whether its management is intentional, aligned with strategy and managed with discipline.