TL;DR
Measure technical debt through the cost and risk it adds to real changes. Track extra lead time, repeated defects, fragile test areas, ownership gaps and work that repeatedly expands because of the same constraint. Keep a debt register tied to affected outcomes, evidence and a next decision. Avoid one universal debt score: it hides different causes and invites false precision. Prioritise an item when it blocks the roadmap, raises operational risk or makes common changes materially harder.
In this article
6 min read
Technical debt is real, but it is not one substance that can be weighed. A missing test suite, tightly coupled module, obsolete dependency and undocumented business rule create different costs. Adding them into one percentage may look precise while concealing the decision the team needs to make.
The practical question is how do you measure technical debt without pretending it is exact? Observe how specific constraints change delivery and risk. Record the affected work, compare repeated costs over time and decide whether paying down that debt is more valuable than the alternatives.
Begin with a blocked or expensive change
Do not start by scanning the repository and counting every possible smell. Start with work the team needs to deliver. Ask what makes that work slower, riskier or harder to verify than it should be.
A useful debt statement has four parts:
- Constraint: the concrete code, dependency, test or knowledge problem.
- Affected outcome: the roadmap item, service level or maintenance task it harms.
- Evidence: observed delay, rework, incident, manual step or missing proof.
- Decision point: the next moment when the team should repair, accept or revisit it.
“Legacy module is bad” is not measurable. “Every pricing change requires edits in four services and a two-day manual reconciliation because rules are duplicated” gives the team something it can investigate and compare.
Measure the interest, not an imaginary principal
The original effort saved by taking a shortcut is often unknown. The cost to fully remove it is also uncertain until the team explores the work. Measuring those numbers as if they were financial debt creates false accuracy.
The observable “interest” is more useful: extra time, failure risk and cognitive effort paid whenever the affected area changes. Track signals around a stable unit, such as one service or change type.
Comparison
| Signal | What it may reveal | Limitation |
|---|---|---|
| Lead time for similar changes | Friction in understanding, testing or integration | Priority and team availability also affect time |
| Rework after review or release | Weak boundaries, unclear requirements or poor verification | Rework is not always technical debt |
| Change failure and recovery | Fragile delivery or unsafe coupling | Needs enough changes for a useful pattern |
| Repeated manual checks | Missing automation or trusted evidence | A manual check may be the right control |
| Ownership escalations | Knowledge concentration and unclear boundaries | Organisational design may be the main cause |
DORA’s software-delivery research uses measures such as change lead time, deployment frequency, failed deployment recovery time, change failure rate and rework. These are system performance signals, not a technical-debt score. Use them to locate recurring friction, then investigate the actual cause.
Keep different debt types separate
A single backlog label encourages teams to compare unlike problems. Separate items by the decision they require.
Structural debt makes common changes spread across many modules. Verification debt means the team cannot prove behaviour efficiently. Dependency debt creates security, compatibility or support pressure. Knowledge debt leaves critical behaviour without a reliable owner or explanation. Operational debt makes release and recovery depend on fragile manual work.
The categories are a navigation aid, not a scoring formula. An item may cross several. The useful question remains: what outcome is affected and what evidence shows the effect?
Use ranges and confidence for repair estimates
A precise estimate is misleading when the system is poorly understood. Estimate a range, state the assumptions and fund a small investigation when uncertainty itself blocks the decision.
For example, a team may believe separating a module will take two to six weeks, assuming its database tables are not written by another service. A short trace can test that assumption. Afterward, the range may narrow or the proposed repair may change entirely.
Record three options where possible:
Decision guide
- Contain: add a boundary, test or documentation that reduces future interest without removing the debt.
- Repair incrementally: change the design in slices alongside needed product work.
- Replace: rebuild a bounded capability when repair cannot meet the required outcome.
Containment is often undervalued. A characterization test, interface wrapper or named owner can reduce risk while the team waits for the right roadmap moment.
Prioritise debt with the roadmap, not beside it
A separate technical-debt percentage creates a negotiation between “features” and “engineering.” Instead, show how the debt changes the cost, risk or feasibility of an outcome the organisation already values.
Prioritise when the same constraint repeatedly delays important work, creates credible operational or security risk, prevents necessary change or concentrates knowledge in a way the team cannot sustain. Defer when the affected area is stable, isolated and unlikely to change, provided the risk is understood.
The major-refactor decision is different from debt measurement. Measurement identifies the recurring cost. A refactor is one possible treatment, which must still be scoped and verified.
Review the register for learning, not theatre
A debt register should contain a small number of current, evidence-backed items. Review it when roadmap work enters an affected area, after an incident exposes a constraint or when the evidence changes. Close items that no longer matter.
For each repair, compare the expected effect with what happened. Did similar changes become easier? Did the manual step disappear? Did verification improve? One result does not establish universal causality, but the comparison improves future decisions and exposes repairs that merely moved complexity elsewhere.
Avoid using code-quality tool scores as the sole measure. Static analysis can find valuable issues and trends, but it cannot know whether a flagged structure blocks the roadmap or whether an unflagged business rule has no owner.
A good technical-debt measurement system supports a choice. It makes uncertainty visible, connects engineering conditions to outcomes and prevents loud but unactionable cleanup proposals from outranking evidence.
If technical constraints are making delivery hard to predict or verify, Build with us. Eliyce agrees scope and evidence in writing and delivers reviewable software; the page explains the working model without promising a fixed outcome.
Use a baseline before a substantial repair. Capture the current sequence for a representative change: handoffs, elapsed time, manual checks, failures and the people required. After the repair, run a comparable change and note what moved. The comparison will never isolate every variable, but it is stronger than declaring success because the new structure looks cleaner.
Also watch for transferred debt. A new abstraction may simplify one module while making debugging or deployment harder elsewhere. Review the full path of the affected work and ask operators and reviewers, not only the developers who designed the repair. A useful measure follows the outcome across team boundaries.
Frequently Asked Questions
How do you measure technical debt without pretending it is exact?
Measure the extra cost and risk around real changes: delay, rework, failure, manual verification and ownership gaps. Connect each observation to a concrete constraint and outcome. Use ranges and confidence instead of compressing everything into one score.
Can technical debt be measured as a percentage?
A percentage can describe a specific tool’s model, such as estimated remediation effort relative to development effort. It does not represent all technical debt. State the calculation and use it alongside delivery, operational and knowledge evidence.
What belongs in a technical debt register?
Record the constraint, affected outcome, evidence, owner, uncertainty, options and next decision point. Exclude vague cleanup wishes that cannot explain who is affected or what future cost they are expected to reduce.
How do you decide which technical debt to fix first?
Prioritise debt that repeatedly blocks important roadmap work, raises credible operational or security risk, or makes frequent changes difficult to verify. Compare repair with containment and with the cost of leaving it in place.
Are bugs the same as technical debt?
No. A bug is observed incorrect behaviour. Technical debt is a condition that increases future cost or risk. A bug may expose debt, and repeated bugs from the same constraint can be evidence for a debt item.
How do you know whether paying down debt worked?
Define the expected change before repair, then compare similar work or risk signals afterward. Look for reduced repeated effort, fewer manual steps, clearer ownership or stronger verification. Record limits when other changes make comparison uncertain.
