Twitter’s move away from Rails monolith: Twitter’s original Rails codebase accumulated debt under load — the shared-nothing model that worked at thousands of users failed at millions. The repayment was multi-year: extract services, replace Ruby with Scala for performance-critical paths, redesign the data model. The interest was real: multiple public outages (“fail whale”) during the repayment period while the system was being restructured under load.
Stripe’s API backward compatibility: Stripe treats breaking API changes as debt of the highest order. Their API versioning strategy — each request carries a version date, old versions are maintained indefinitely — is the result of learning that API breaking changes incur enormous customer cost. The decision to never break an API version is a deliberate debt prevention policy.
AWS SDK breaking changes: In contrast, early AWS SDKs accumulated API debt and paid it through breaking changes. Each major version (boto2 to boto3 in Python) required significant customer migration work. The interest was paid not by Amazon’s engineering team but by the customers. This is debt where the interest is externalised — the original team does not pay.
Apple’s Swift transition: Apple’s transition from Objective-C to Swift is a deliberate/prudent debt repayment at language level. Objective-C was appropriate for decades; Swift provides safety and performance properties Objective-C could not. The migration spanned years, with both languages supported simultaneously during the transition window.
Concept: Technical Debt as Architecture Thread: T12 (Tradeoffs) ← Book 4, Ch 1 (Architectural decisions) → Ch 16 (Refactoring Techniques) Core Idea: Technical debt is a structural tradeoff — simplicity now, flexibility later — that must be tracked explicitly with a trigger for repayment; the quadrant (deliberate/inadvertent × reckless/prudent) determines what action is appropriate; untracked debt compounds into architectural rigidity. Tradeoff: AT3 — Simplicity/Flexibility: debt is choosing simplicity now at the cost of flexibility later; the cost of repayment grows with the number of systems that depend on the simplified structure. Failure Mode: FM8 — Schema/Contract Violation: implicit contracts (shared schemas, undocumented APIs) are the highest-cost form of debt because repayment requires coordinating every consumer simultaneously. Signal: When adding a new feature requires modifying an unexpectedly large number of files, or when a specific area of the codebase causes a disproportionate number of incidents, untracked technical debt is the cause. Maps to: Reference Book, Framework 8 (Patterns)