Technical Debt Tracking

---

Origins

The technical debt metaphor was introduced by Ward Cunningham in 1992¹. Cunningham used the metaphor to explain to financial-services stakeholders why the team needed to refactor: shipping code quickly was like borrowing money, and the cost of not paying it back was paid as ongoing interest in the form of slower future development.

The metaphor has been refined, debated, and stretched since — Martin Fowler's debt quadrant (deliberate/inadvertent vs. prudent/reckless)² is now widely used — but the core insight holds. Shortcuts have an ongoing cost. Teams that don't track that cost pay it indefinitely without realizing they could choose differently.

Fowler's Debt Quadrant

Not all technical debt is the same. Fowler's quadrant distinguishes four kinds:

• Deliberate & prudent: "We know this isn't ideal, but we need to ship now and we'll fix it later." Acceptable when conscious.
• Deliberate & reckless: "We don't have time for good design." The team knows they're cutting corners and does it anyway.
• Inadvertent & prudent: "Now we know how we should have built it." The understanding came after the work; the debt is the gap between then and now.
• Inadvertent & reckless: "What's a design pattern?" The team didn't know what good looked like and produced debt by default.

The quadrant matters because the response differs. Deliberate debt should have a payback plan from the start. Inadvertent debt is a learning opportunity. Reckless debt of either kind is a process problem — the team is producing debt faster than it can absorb the cost.

What Counts as Technical Debt

The category includes more than "ugly code":

• Code-level debt: duplication, complex methods, brittle tests, outdated patterns.
• Architectural debt: services that should be split, schemas that no longer fit, integrations built for an old context.
• Dependency debt: outdated libraries, abandoned dependencies, vulnerabilities.
• Test debt: missing test coverage, flaky tests, slow test suites.
• Documentation debt: missing or outdated docs, runbooks that no longer match reality.
• Infrastructure debt: aging environments, manual deploy steps, missing observability.
• Knowledge debt: tribal knowledge in a single person's head, undocumented decisions.

Each kind accrues interest differently. Code-level debt slows the next feature in that code area. Architectural debt slows everything across the affected boundary. Knowledge debt becomes a crisis the day the holder leaves.

What Tracking Actually Means

Technical debt tracking is the discipline of making debt visible enough to manage. Several layers of practice:

Mark it

When debt is created or discovered, mark it. Code comments (TODO, FIXME, HACK) work; tickets work better. The point is that the team can find what's been deferred.

Categorize it

Use the quadrant or your own taxonomy. Different kinds of debt warrant different responses.

Estimate the interest

What's the ongoing cost of this debt? "Every feature that touches this module takes 30% longer" is a concrete interest payment. Knowing the rate informs the prioritization.

Prioritize

Not all debt is worth paying off. Some carries low interest; some is in code about to be deleted; some isn't worth fixing relative to other work. Prioritize based on interest rate, not on aesthetic offense.

Allocate capacity

If the team plans 100% feature work, debt grows. Some explicit allocation — 10-20% of capacity, dedicated days, refactoring as part of every story — lets debt actually get paid down.

Review periodically

Operations review or a dedicated debt review surfaces what's accumulating. Without the regular look, debt becomes background noise.

Common Tracking Patterns

Debt tickets in the backlog

Each debt item gets its own ticket, prioritized alongside features. Simple, visible, easy to defer indefinitely.

Refactoring tax on every story

Each story includes some related cleanup. Steady payment, but the worst debt may never be in the path of a story.

Dedicated debt sprints

Periodic focused efforts on debt. High-leverage when it happens; tends to get cancelled under pressure.

Boy Scout Rule

"Leave the code cleaner than you found it." Cultural discipline rather than explicit tracking. Works when the culture supports it; fails silently when it doesn't.

Quality gates

Automated checks that prevent new debt — complexity thresholds, coverage requirements, dependency vulnerability blocks. Effective for what they cover, blind to what they don't.

Common Pitfalls

• "We'll fix it later" without a ticket: the team commits the debt without recording it. Later doesn't come; the debt is forgotten and pays interest forever.
• Debt tickets in a separate backlog nobody opens: tracked but invisible. The same as untracked.
• Tracking aesthetic preferences as debt: "this could be cleaner" without a real interest payment. The debt backlog fills with low-value items and the real debt gets lost.
• No prioritization framework: all debt treated equally; the loudest debt gets fixed, not the most leveraged.
• Zero debt allocation: the team plans only feature work; debt grows unboundedly until a crisis forces it back into scope.
• Debt review as theater: a meeting where the team agrees there's debt and nothing changes. Make the review produce committed work, not just acknowledgment.

Coaching Tips

Make Debt Visible

If "we'll fix it later" gets said in a meeting, get the ticket created in the same meeting. Untracked debt is forgotten debt.

Estimate the Interest

"This is gross" is not a tracking entry. "Every feature in this module takes 30% longer because of this pattern" is. Make the cost concrete.

Allocate Capacity Explicitly

If debt is never planned for, it never gets paid. Some explicit percentage — even 10% — produces dramatically better outcomes than "we'll do it when we can."

Don't Conflate Aesthetics with Debt

Code that's not how you would have written it isn't always debt. Real debt has an ongoing interest payment you can name.

Review at a Cadence

Periodic debt reviews surface what's accumulating. Without the regular look, debt becomes background noise and the team stops noticing.

Prefer Prudent Debt

When debt is taken on, make it deliberate with a payback plan. The reckless quadrants are where the long-term cost compounds out of control.

Summary

Technical debt is one of the few engineering concepts that genuinely benefits from the financial metaphor. Like financial debt, technical debt has a principal and an interest rate. Like financial debt, taking it on can be wise or reckless. Like financial debt, ignoring it doesn't make it go away — it makes the interest payments invisible.

Teams that track debt well don't have less debt. They have more conscious debt — deliberate, prioritized, with payback plans. Teams that don't track debt have whatever debt they've accumulated without realizing they could choose differently. The difference shows up over years in the codebase the team can or can't change quickly.

Back to Technical Practices