Technical Debt — Taxonomy and Communication

Ward Cunningham coined the technical debt metaphor: 'shipping first and refactoring later is like going into debt. A little debt speeds delivery so long as it is paid back promptly with a refactor.' The danger is letting debt accumulate — the interest (slowdown) eventually exceeds the original time saved.

Deliberate debt: 'We know this is a shortcut — we'll clean it up in Q3.' It is a conscious trade-off. Inadvertent debt: the team didn't know better at the time (e.g., learned a better pattern later). Deliberate debt is manageable when tracked; inadvertent debt is more dangerous because it is unrecognized.

Debt interest is the productivity tax of existing technical debt. Every feature added to a poorly structured module costs more than it should. As debt grows, interest payments grow — eventually the team spends more time fighting the codebase than building features. This is the 'cruft' that slows development velocity.

A debt registry (debt backlog) makes technical debt explicit and managed: each item has a title, description of the problem, estimated cost to fix, business impact if not fixed, and an owner. This transforms 'vague technical debt' into managed work that can be prioritized like product features.

Paying down debt means investing time now to improve code quality, reducing future interest payments. Common approaches: allocate a fixed percentage of each sprint to debt paydown (20% rule), schedule dedicated refactoring sprints, or use opportunistic refactoring to improve code while doing feature work.