Types of Technical Debt
debt(d7/e7/b7/t7)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints indicate automated detection is 'no' and tools like SonarQube and Jira can surface some signals, but the code_pattern note explicitly states debt accumulates when there's no explicit tracking or paydown schedule — distinguishing debt types requires human judgment in code review and retrospectives, not automated tooling.
Closest to 'cross-cutting refactor across the codebase' (e7). The quick_fix describes a triage framework, but actually remediating accumulated technical debt — especially reckless/inadvertent debt from code review gaps — touches multiple systems and work streams. Establishing debt categorisation, documentation practices, and sprint budgets is a persistent organisational and codebase-wide effort, not a localised fix.
Closest to 'strong gravitational pull' (d7). Tags include architecture and management, and applies_to covers both web and cli contexts broadly. The common_mistakes note that without a debt budget 'interest compounds and velocity degrades' signals that unmanaged debt shapes every future decision — feature velocity, refactoring decisions, and onboarding all feel the weight of this choice.
Closest to 'serious trap' (t7). The misconception field states the canonical wrong belief is that 'all technical debt is bad and must be eliminated' — which directly contradicts the quadrant model where prudent deliberate debt is a legitimate tool. This is a well-documented conceptual inversion that competent developers commonly hold, contradicting the nuanced framing this term introduces.
Also Known As
TL;DR
Explanation
Ward Cunningham's original metaphor: shipping imperfect code to meet a deadline is like taking a loan — the 'interest' is the ongoing cost of working around it. Martin Fowler's quadrant: Reckless-Deliberate ('no time for design'), Reckless-Inadvertent ('what's layering?'), Prudent-Deliberate ('ship now, fix later'), Prudent-Inadvertent ('now we know the better approach'). Reckless debt must be paid down aggressively. Deliberate-prudent debt should have a documented payback plan. Key insight: not all tech debt is bad — prudent debt accepted consciously with a plan is a legitimate business decision.
Common Misconception
Why It Matters
Common Mistakes
- Not documenting deliberate debt decisions — future developers don't know why a workaround exists or that it should be replaced.
- Accumulating inadvertent reckless debt through code review gaps — this is the most damaging type and the hardest to quantify.
- Using 'tech debt' as an excuse for poor quality — reckless inadvertent debt is not a legitimate business decision.
- No tech debt budget in sprints — without scheduled time for paydown, interest compounds and velocity degrades.
Code Examples
// Reckless deliberate debt — no plan to fix:
// TODO: this is a hack, refactor someday
function calculateDiscount($order) {
if ($order->customer_id === 42) return 0.5; // Hardcoded for VIP customer
// ... no plan to fix, no ticket created, forgotten in 3 days
}// Prudent deliberate debt — documented with a plan:
// TECH_DEBT: [JIRA-1234] Discount rules hardcoded until DiscountEngine is built (Q3 2026)
// Owner: @paul | Estimated cost: 2 days | Interest: manual work for each new VIP
function calculateDiscount(Order $order): float {
// Temporary: static rules until pricing service is live
return match($order->tier) {
'vip' => 0.2,
'premium' => 0.1,
default => 0.0,
};
}