Technical debt is the future cost created when expedient technical decisions make software harder to change or maintain. A team may ship quickly, but quick fixes, incomplete implementations, or weakened architecture can later require refactoring and consume delivery capacity. section 12.2.3
Debt can arise from deadline pressure, limited resources, or inexperienced decisions. It may also be intentional: launching quickly can help validate an idea or gain market traction. The practical goal is not to eliminate every shortcut, but to acknowledge, balance, and reduce its consequences. section 12.2.3
Manage technical debt by connecting technical choices to service health and future work:
- Ask whether designs avoid duplicate code, support modularity and extensibility, receive thorough review, and include appropriate tests and documentation. section 12.2.3
- Balance technical-debt tasks with feature work instead of treating debt as an exceptional activity. section 12.2.3
- Track defects, test coverage, code readability, maintenance effort, on-call reports, service availability, downtime, and SLA performance. section 1.2.4
- Explain the cost to nontechnical partners through reliability, SLA, customer, personnel, performance, and short-term-versus-long-term cost measures. section 9.3.4
From quick fixes to rising on-call work
A team noticed that on-call workload was gradually increasing. Investigation connected the problem to quick fixes that had increased technical debt and infrastructure that lacked updates. The resulting risks included lower developer velocity, reduced morale, and burnout. The team worked with site reliability specialists and dedicated a quarter to improving service health. section 1.2.4
Making debt visible
A rapidly adopted graph database platform required two days of manual onboarding per customer because its minimum viable product had left the process inefficient. Reliability, SLA violations, customer effects, maintenance cost, and long-term cost comparisons made the debt concrete for prioritization. section 9.3.4
