Which Technical Debt Is Worth Fixing?

“The application has technical debt” is a starting point for discussion, not a complete investment case. The business needs to know where the constraint sits and what it prevents.

A pricing rule duplicated across several components may make a commercial change slow and error-prone. A poorly understood integration may require one developer to supervise every release. Missing tests around a critical calculation may make the team reluctant to alter it. These are specific relationships between software structure and business work.

Distinguish debt from other problems. A newly requested feature is not automatically debt. Neither is every defect, unsupported component or unfamiliar technology. Some issues overlap, but the label should not obscure the actual reason for action.

The Software Engineering Institute’s Managing Technical Debt material treats debt as something to identify and manage across delivery and sustainment. A useful business discussion therefore names a particular design or implementation constraint rather than condemning the whole codebase.

Ask the team for recent evidence. Which change required repeated work? Which incident involved the same fragile component? Which dependency makes a planned feature difficult? What extra review or testing was needed?

Also ask what happens if the business does nothing for the next relevant period. The answer may be continued inconvenience, a growing delivery constraint or an unacceptable operating risk. Those outcomes call for different priorities.

A debt item becomes actionable when someone can explain the affected capability and the consequence of leaving it in place.

A debt register should contain enough information to choose an action. A list of code-quality warnings alone may be useful to engineers but difficult to compare with commercial work.

Record the affected component and business capability, the observed consequence, the next change likely to encounter the problem and the available response. Include an owner who can explain the evidence.

The example does not imply that centralisation is always the answer. A shared component can introduce its own dependencies. The decision needs enough technical investigation to compare the options.

Keep estimates honest. An engineer may be able to demonstrate repeated effort without calculating a precise monetary debt balance. Record a range or qualitative consequence where that is the available evidence.

Avoid treating a tool-generated score as a direct forecast of delivery delay. One industrial study of debt and issue lead time reported mixed relationships between the measures it examined. That is a reason to connect automated indicators with the application’s actual change history.

The register should be maintained as work proceeds. Remove resolved items, revise assumptions and add new evidence. An untouched catalogue of every possible improvement quickly becomes another document the team does not use.

Not every debt item should be fixed immediately. The sensible response depends on the value of the affected capability, the likelihood of encountering the constraint and the risk of changing it.

Repair is attractive when a near-term business change repeatedly crosses the same difficult area. The work can improve the foundation and deliver the intended capability together, provided the scope remains clear.

Containment may be appropriate when the system cannot be replaced soon. The team might add tests around fragile behaviour, restrict changes through a stable interface or improve monitoring and documentation. These measures can make the constraint more manageable without claiming it has disappeared.

Acceptance can be reasonable when the affected area is stable, low-risk and unlikely to change before retirement. Record that decision and its review trigger. “Accepted until the old reporting service is retired” is clearer than allowing an item to remain indefinitely without discussion.

A business-driven debt-prioritisation case study connects debt decisions with valuable business assets. The practical lesson for an SME is to discuss the capability at stake, rather than rank every code issue on one undifferentiated list.

Urgent security or reliability problems need appropriate treatment even if they sit in an otherwise low-priority area. Debt prioritisation should not become a reason to defer a known serious exposure without an informed owner.

Compare the cost of the intervention with the constraint it removes. A broad rewrite can introduce migration and operational risk that exceeds the benefit of a local repair. Conversely, repeated patches may be poor value when a component clearly cannot support the required direction.

The decision should state what will improve and how the team will recognise the improvement.

Technical debt work is easier to assess when it is connected to an upcoming business change. Identify the relevant constraint during planning and include the repair or containment needed to deliver safely.

Keep that work visible. Hiding substantial restructuring inside a small feature estimate can create confusion about progress and cost. Present the relationship: this capability requires a change in this area, and this preparatory work reduces the identified risk or repeated effort.

When several planned features depend on the same improvement, make that shared investment visible. Assign an owner and decide which release will carry the work, rather than repeatedly including or excluding it in separate estimates. This also helps prevent a necessary foundation from being deferred because each individual feature appears too small to justify it alone.

Define acceptance for the technical improvement as well as the feature. Depending on the issue, evidence might include consistent behaviour across entry points, a repeatable deployment, a recoverable integration failure or tests that cover the critical rule.

Do not promise that every refactor will make all future development faster. Review the effect on the specific work the debt obstructed. Can another developer understand the component? Does the next comparable change involve fewer manual steps? Has the recurring incident stopped?

Keep the result separate from changes in team size, requirements or workload. Delivery time can improve or worsen for many reasons, so the review should use the closest relevant evidence.

Discuss debt at a cadence that fits the product. Important items belong in planning when their capability is next changed; significant risk items need an earlier decision. The backlog should show these priorities alongside features rather than place all engineering work in a distant clean-up project.

For software development and modernisation, this approach creates a practical agreement between technical and business teams. The engineers explain the constraint and options. The business helps judge consequence and timing. Together, they choose improvements that support the service’s future without pursuing a theoretically perfect codebase.

That gives technical debt a manageable place in the investment plan: a set of explicit decisions tied to work the business needs to perform.