Problem
Technical debt accumulates invisibly. Teams ship features, debt compounds. No budget, no visibility, no strategy. Eventually velocity → 0.
economics-evolutionestablished · medium operational burden
Technical Debt Management
Also known as: tech-debt, technical-debt, debt-management, refactoring, code-quality
Intent
Systematically identify, prioritize, and pay down technical debt — treating it as a portfolio with interest rates, not a dirty word.
Forces
- •Debt is inevitable: trade-offs made under pressure
- •Interest compounds: debt slows future changes, causes bugs
- •Visibility: debt must be measurable, not gut feel
- •Budget: allocate % of capacity to debt repayment
Solution
✓ When to Use
- •Any team with codebase > 6 months old
- •Velocity declining, bugs increasing
- •Onboarding new engineers takes months
✗ When Not to Use
- •Pre-product-market fit (velocity > quality)
- •Team not ready for measurement discipline
Pros
- +Sustainable velocity long-term
- +Reduces bugs, outages, security incidents
- +Improves onboarding, morale, retention
- +Enables faster feature delivery long-term
Cons
- −Short-term velocity hit (20% budget)
- −Measurement overhead (tools, process)
- −Hard to quantify ROI precisely
- −Requires cultural buy-in (not just engineering)
Cost Profile
Infrastructure
Low — tools, dashboards
Operational
Medium — measurement, budgeting, review
Cognitive
Medium — categorization, prioritization
Failure Modes
Debt theater: metrics tracked, no action
Rewrite trap: big bang rewrite instead of incremental
Perfectionism: gold-plating instead of high-interest debt
No budget: debt work only "when time permits"
Blame culture: "who wrote this?" instead of "how to fix?"
Real-World Examples
Alternatives
- ignore-debt
- rewrite-only
- perfectionism
- no-process
Related Patterns
- architecture-decision-records
- refactoring
- code-quality
- dependency-management
- architecture-review
- debt-registry
Competency Domains
economics evolutionreliability opsdeploymentdeploymentsecurity compliance