Practical Ways to Reduce Technical Debt While Development Continues

Why Technical Debt Keeps Growing (and Why That's Normal)

Technical debt is not evidence of bad work. It happens when you build software under real conditions: tight deadlines, shifting requirements, limited budget, and teams that grow faster than the systems underneath them. Ward Cunningham, who coined the term, described it as a financial metaphor. Shipping code that has not been fully thought through is like borrowing money: you get the feature sooner, but pay interest later in slower development and more fragile systems. As Martin Fowler explains on his bliki, the extra effort needed to incorporate a feature into a system overflowing with shortcuts is exactly that interest being paid back.

This is a typical SMB story: a SaaS company starts with five developers and a working prototype. Three years later, the team has grown to twenty people and ten times the features, but the architecture remains essentially the same. Every module gets bolted onto what already exists, because stopping to redesign the foundations never feels as urgent as the next release. That is how debt accumulates: not through carelessness, but through the ordinary pressure of building a business.

The Real Cost of Ignoring Technical Debt

For anyone who does not read code, technical debt stays invisible until it starts showing up in budgets and timelines.

The first thing that you notice is slipping timelines. A change that took a week two years ago now takes a month, because every task starts with navigating layers of undocumented workarounds, and developers consistently report losing 20 to 40% of their working time to exactly that kind of friction.

Hiring gets harder too. When system knowledge lives in one person's head and that person leaves, it goes with them. New hires can spend months getting up to speed on a codebase nobody thought to document, which means the team is effectively smaller than it looks on paper.

The deeper problem is that debt makes the codebase fragile. If you touch one thing, another breaks, leading the team to work around the system rather than through it. This is where professionals usually leave because they don't want to be on projects where they aren't allowed to improve anything. Over time, heavy unaddressed debt becomes a retention problem as much as a technical one. It is also worth reading technical debt as one entry on a wider risk register — our guide to IT risk assessment for SMBs puts it in context.

The GOV.UK team documented this publicly. After a period of intense building on a single government publishing platform, they recognised that delivery would keep slowing unless they stopped and paid some of the debt back. They set aside a full month, or a "firebreak", to do exactly that, putting debt reduction ahead of new features. The team came out faster and more capable of shipping.

How to Reduce Technical Debt: 5 Practical Approaches

The right approach depends on how much debt you have, how fast it is growing, and what bandwidth you can realistically dedicate to it. These five technical debt best practices can be used in combination, and each one suits a different scale of problem.

1. The Boy Scout Rule: Leave Code Better Than You Found It

Whenever a developer touches a piece of code, they leave it slightly better than they found it. It's not a rewrite, just something small, like moving a hardcoded value into config, adding a missing test, renaming a variable that nobody understood, or removing commented-out code that has been sitting there for two years. To do this, you don't need extra budget or a dedicated sprint — just consistent discipline during code review, and a shared agreement on what "better" actually means.

The limitation is worth making clear: this will not fix structural problems. A broken authentication layer is not going to improve because nearby functions got tidied up. The Boy Scout Rule is maintenance, not repair.

2. The 20% Rule: Dedicate Time Every Sprint

Reserve a fixed share of each sprint, usually 15 to 20%, for paying down debt. Atlassian recommends treating debt work as first-class backlog items with the same acceptance criteria as any feature story. This should not be a suggestion that is revisited on a regular basis; it needs to be a standing agreement between engineering and product.

For non-technical leadership, this can be framed as a window for maintenance: machinery breaks down without scheduled servicing, and software is no different. Skipping that servicing just moves the cost to a worse moment.

A working example: a 30-person e-commerce company sets aside 20% of every sprint for its debt backlog. In just three months, deployments are more frequent and new features are shipping faster, because the codebase is finally stable enough to build on without fighting it at every step.

The honest limit: this works well for moderate, manageable debt. Ten years of accumulated shortcuts will not yield a 20% allocation. That scale requires something more deliberate.

3. The Technical Debt Backlog: Make It Visible

Since it's impossible to prioritise or finance debt that lives only in developers' minds, the minimum first step toward managing it properly is to make it visible as a tagged set of items in Jira, Linear, or even a shared spreadsheet.

GOV.UK's approach is worth copying. Anyone on the team logs a card when they find or create debt, noting the cause, the consequence, and a rough impact-versus-effort estimate. Senior technical leads review the board regularly, assign priority, and give high-priority items to a named owner.

The tools do not need to be complex. What is important is that technical debt management is no longer limited to engineering discussions but is now something that leadership and product owners can view and consider when evaluating feature work.

Three questions sort most backlogs: what is blocking new features right now, what creates a real risk of failure or a security problem, and what will cost significantly more to fix in six months than it does today. Good technical debt tools, whether Jira, Linear, or SonarQube for automated detection, make these trade-offs visible across the whole team, not just the engineers.

4. The Strangler Fig Pattern: Replace Piece by Piece

When debt is not just messy code but a structure that is genuinely outdated, replacing things incrementally is almost always safer than a full rewrite. Martin Fowler coined the Strangler Fig pattern in 2004 for exactly this situation.

The name comes from a fig tree that replaces a host tree by gradually growing around it, without the need for the host tree to be felled. In software, a new system is built incrementally around the old one. Functionality migrates piece by piece, with the old system handling whatever has not yet moved, until the legacy system can finally be switched off. Our deep dive on the strangler fig pattern walks through the mechanics, and our rewrite vs. modernise framework covers the decision itself.

Here is a practical example: a manufacturing company has a monolithic ERP nobody dares touch. Rather than rewriting it, the team extracts the billing module into a separate, well-structured service, while the rest of the ERP keeps running exactly as before. Once billing is stable, they move to inventory. The system gets replaced gradually, without a single terrifying cutover moment.

This requires more coordination than the lighter approaches above and genuine technical judgement to execute well. For genuinely legacy systems, it is often the most realistic path. For more information on how this works, explore our legacy modernisation service.

5. Planned Modernisation Sprints

When a specific component is blocking progress badly enough, incremental chipping will not do it. A planned modernisation sprint gives you two to four weeks to fix one specific problem. It should be run as a proper project with clear deliverables, not just an idea of how to make things better.

Common triggers include a third-party API being retired, an integration blocking a new customer, and a database schema that cannot support a feature already promised on the roadmap. These cannot wait for the 20% allocation to slowly accumulate. Specific legacy platforms often force the issue — replacing an Access database is a common example.

Getting approval means being direct with leadership about the trade-off: new features pause for two to four weeks, and here is exactly why that is worth it. Here is the problem, here is what it costs to leave it, and here is what gets delivered. That framing is effective, but "we need time to clean up the code" is not.

For debt that has grown beyond what any sprint can address, outside support is worth considering. Our legacy modernisation service is built for exactly that situation.

How to Prioritise Technical Debt: Effort vs. Impact

Technical debt prioritisation starts with three questions. Does this debt block work that generates revenue or affects customers, and how directly? Does it create a security gap, a compliance risk, or a single point of failure? And will it get meaningfully harder or more expensive to address in six months?

An authentication module blocking new integrations sits in the top-right quadrant. A deprecated CSS framework nobody notices goes bottom-left.

How to Manage Technical Debt in Agile

Agile's iterative structure is well-suited to debt management, but only when debt is treated as a real sprint priority rather than something squeezed in on quiet weeks. That means a debt backlog reviewed every sprint, a clear capacity agreement between engineering and product, and goals that include debt items where they matter.

Atlassian's guidance recommends tracking metrics like cycle time, defect escape rate, and change failure rate to make the cost of debt legible to non-technical stakeholders. Consistent slippage on these numbers, even as headcount stays flat, is often the clearest signal that debt has become a business problem.

A technical debt sprint, dedicated primarily to debt reduction, is a legitimate agile tool when the backlog has outpaced what incremental work can handle. It should be an occasional measure, not a quarterly ritual. If a team needs one every three months, the standing allocation is not holding.

Who Should Own Technical Debt?

Technical debt management fails when it is treated as an engineering concern only, but ownership needs to sit at several levels.

• The CTO or technical lead sets the strategy and prioritisation framework, deciding what warrants a dedicated sprint and what can be handled within the regular allocation.
• The product owner supports the balance between features and debt in sprint planning. Without someone in that role actively protecting the allocation, features will win every time.
• Developers identify and flag debt as they encounter it, estimate remediation effort, and do the work once it is prioritised.
• Business leadership approves the budget and signs off on the planned modernisation. Without executive buy-in, anything beyond incremental work will not get off the ground.

It's usually enough to have a thirty-minute review of technical debt every three months with the CTO and product owner to talk about what was added, what was fixed, and whether the current approach is keeping up.

When Managing Isn't Enough

These approaches work when debt is at a level the team can address alongside regular work. Some situations are past that point.

Signs your technical debt needs professional help:

• Debt has been building for five or more years with no structured plan to address it.
• Core systems run on end-of-life technology: Visual Basic 6, Delphi, Microsoft Access.
• The person who built the system has left, and nobody else fully understands it.
• Compliance or security requirements cannot be met on the current architecture.
• New features consistently take two to three times longer than they should.

When several of these apply, continuing to work around the problem costs more than fixing it. The most efficient starting point is not a commitment to "modernise everything" before anyone knows what that means. Instead, the first step should be a structured assessment of the architecture, the real risks, and the realistic options — our IT audit checklist is a good place to begin.

At Hollinford, we start every engagement with exactly that kind of assessment before agreeing on any project scope. If these signs apply to your system, it is worth talking before the gap widens further.

Key Takeaways

• Technical debt is normal. Every team shipping software at a pace accumulates it. The goal is not zero debt — it is debt at a level you can manage, with a plan that keeps it from compounding.
• Start with visibility. A debt backlog, however simple, is the minimum first step. You cannot manage what nobody can see.
• Match the approach to the scale. The Boy Scout Rule and 20% allocation for moderate debt. Strangler Fig and planned modernisation sprints for serious cases.
• Prioritise by business impact. Which debt is actually slowing down revenue-generating work or creating operational risk? That is the question, not which code bothers the engineers most.
• Ownership is cross-functional. CTO, product owner, business leadership — all three have a role. Technical debt is a business problem before it is a technical one.

Sources & Further Reading

• Martin Fowler — Technical Debt.
• Inside GOV.UK — GOV.UK's firebreak: why and how we spent a month working differently.
• Atlassian — Agile software development.
• Martin Fowler — Strangler Fig Application.