Technical debt is the accumulated cost of shortcuts, compromises, and deferred work in software development — first articulated by Ward Cunningham in 1992 as a financial metaphor to explain the trade-off between speed and perfect design. It exists in every codebase and isn't inherently bad; prudent, deliberate debt can accelerate time-to-market and validate ideas quickly. Deloitte's 2026 Global Technology Leadership Study estimates that technical debt accounts for 21–40% of an organization's IT spending, and IBM research shows 81% of executives say it is already constraining AI success. The critical challenge is visibility and prioritization — teams that treat technical debt as a managed backlog item rather than hidden friction consistently ship faster and maintain higher quality over time. Understanding the different types of debt (code, design, architecture, test, documentation, infrastructure, security, AI/LLM), how to measure it quantitatively, and how to prioritize remediation using frameworks like WSJF, blast radius analysis, or cost of delay modeling is what separates teams that scale from those that collapse under their own complexity.
What This Cheat Sheet Covers
This topic spans 14 focused tables and 142 indexed concepts, 125 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
Table 1: Fowler's Technical Debt Quadrant
Martin Fowler's quadrant separates debt by whether it was conscious (deliberate vs. inadvertent) and whether it was strategically sound (prudent vs. reckless). Knowing which quadrant a debt item falls into determines how urgently it must be addressed and what cultural fix is needed alongside the technical one.
| Type | Example | Description | |
|---|---|---|---|
// Ship now, refactor auth layer next sprint | • Conscious decision to take a shortcut with a clear plan to pay it back • typically driven by strategic need to ship quickly; the intent distinguishes it from reckless debt. | ||
"We don't have time for design patterns" | • Knowingly cutting corners with no remediation plan • accumulates rapidly and often leads to architectural collapse; a cultural problem as much as a technical one. | ||
"Now we know how we should have built this" | • Learning-based debt that emerges after shipping • team gains understanding of the problem domain through building; unavoidable and healthy when addressed promptly. | ||
Poorly written code by inexperienced developers | • Accidental debt from lack of skill or awareness • often invisible until it causes production issues or blocks new features; addressed through mentorship and standards. |