Technical Debt

Technical debt, coined by Ward Cunningham in 1992, is the implied cost of future rework caused by choosing a quick solution now instead of a better long-term approach. Martin Fowler's Technical Debt Quadrant classifies debt across two axes: deliberate vs. reckless, and prudent vs. inadvertent. Not all debt is bad — deliberate, prudent debt (shipping MVP to validate market) can be a rational tradeoff. The danger is reckless, inadvertent debt that accumulates invisibly until it causes outages or makes feature development economically impossible.

Key Points

• Debt Quadrant: Prudent+Deliberate ("ship now, refactor later"), Prudent+Inadvertent ("now we know better"), Reckless+Deliberate ("no time for tests"), Reckless+Inadvertent (poor practices).
• Boy Scout Rule: always leave the code cleaner than you found it — incremental improvement prevents accumulation of reckless debt.
• Refactoring safely: use Michael Feathers' "working with legacy code" techniques — add tests first (characterization tests), then refactor under test coverage.
• Architecture Decision Records (ADRs): document architectural decisions with context, decision, and consequences — creates an audit trail for future engineers.
• Debt inventory: regularly catalog high-impact debt items in a shared backlog, score by business impact and remediation cost, prioritize accordingly.
• Strangler Fig pattern: incrementally replace legacy systems by routing new functionality through new services, shrinking the legacy surface over time.
• Code complexity metrics: Cyclomatic Complexity, Cognitive Complexity (SonarQube) — flag functions above threshold for mandatory refactoring.
• Technical debt velocity: measure how much time per sprint is spent on debt remediation — if >30%, the codebase is in crisis and needs a dedicated paydown sprint.