The engineers want to rewrite it. The business wants another feature. Both sides have prepared a convincing explanation of why the other side does not understand reality.
Technical debt becomes easier to discuss when someone brings evidence instead of a preferred architecture.
The short answer: prioritise technical debt by the harm it causes or risks creating, the work it blocks, and the cost of reducing it. Distinguish urgent exposure from ordinary improvement. The age of the code is not the business case for replacing it.
Describe the consequence
A useful debt record names the affected component and the observable problem: releases require manual intervention, an unsupported dependency blocks updates, or a shared module makes changes slow and risky.
“Bad code” is not enough. Record incidents, repeated rework, delivery delays, support effort or a concrete vulnerability. If the concern is a future risk, state the scenario and uncertainty rather than presenting it as an observed loss.
Some debt was a reasonable trade-off at the time. The question is whether the original conditions still hold and whether the cost of carrying it has changed.
Use three decision lanes
| Lane | Typical trigger | Decision |
|---|---|---|
| Act now | Material security exposure or serious continuity risk | Contain, remediate and verify |
| Schedule with delivery | Debt repeatedly obstructs a funded priority | Include a bounded fix in the plan |
| Monitor or defer | Low current impact and uncertain benefit | Record a review trigger |
The lanes support judgement. They do not replace the authority of security, service or business owners to determine what is tolerable.
Compare three illustrative items
A legacy library may be untidy but stable and isolated. A deployment script may fail regularly and require the same senior engineer to repair it. An unsupported authentication component may expose a serious risk.
The authentication issue may require immediate action. The deployment work may be next because it affects every release and consumes scarce capacity. The untidy library may remain deferred until work in that area creates a sensible opportunity.
That order is not a universal rule. It is an example of using consequence and evidence rather than aesthetic dislike. Record the assumptions so the decision can change when the facts change.
Estimate the cost of carrying and fixing
Use a practical range for effort and identify uncertainty. Include testing, migration, documentation and operational transition. A rewrite estimate that counts only coding is not an estimate of completion.
For carrying cost, record the recurring work or risk you can substantiate. Do not multiply every complaint into a dramatic annual savings figure. If a slow process occurs twice a year, its frequency matters.
DORA’s research offers background on software delivery capability. Use evidence from your own system to decide which improvement is worth doing next.
Prefer bounded changes where they work
Options may include replacing one dependency, adding a test boundary, automating a repeated deployment step or isolating an unstable module. A full rewrite is one option, not the default definition of progress.
For each option, state the acceptance test. “Modernise the platform” is vague. “A second engineer can deploy and restore the service using the runbook” is inspectable.
Include a rollback or migration plan where the change affects data or live operation. Reducing long-term debt should not casually create a short-term outage.
Give debt a place in planning
Review the register alongside the technology roadmap. Reserve capacity based on the actual burden and risk rather than adopting an arbitrary universal percentage.
Close items when the acceptance evidence exists, not when a refactoring branch is merged. Reassess deferred items when their component changes, a dependency loses support or the business begins relying on them more heavily.
Good debt management protects the ability to deliver. It should make the next change safer or cheaper, not merely give the codebase a more fashionable vocabulary.
Sources and scope
Reviewed 1 November 2026. The examples and worksheets are my suggested working methods, not measured client results or official standards.
