Technical Debt
Deliberate, tracked and repaid — as distinct from mess.
5 to work through
-
intermediate
A team's backlog contains fifty technical debt items. How should they be triaged, and which category is most often mis-sorted?
2 min answer -
intermediate
A team's technical debt backlog contains hundreds of items and never shrinks. How should debt be managed?
2 min answer -
intermediate
Engineering says the codebase is full of technical debt. The business hears "we want to stop delivering and tidy up". How do you reframe it?
1 min answer -
advanced
To hit a launch date, a 60-engineer marketplace organisation of eBay's shape stops all technical debt work for two quarters. Nothing is deleted, no dependency is upgraded, no flake is fixed. Assume the launch succeeds. What degrades, in what order, and what becomes genuinely irreversible?
2 min answer -
advanced
You need budget for a year of technical debt work. Leadership has repeatedly declined. How do you make the case?
2 min answer
4 terms in this topic
Debt Interest Rate
How much a piece of technical debt costs per unit time in slowed delivery, incidents and effort - which, paired with the cost to fix, is what separat…
practiceDebt Register
A maintained record of known technical compromises with their cost, impact and repayment trigger, making debt manageable rather than merely felt.
case-studyLinkedIn Project Inversion: Stopping to Fix the Road
LinkedIn halted feature development for roughly two months to rebuild its deployment and development infrastructure, because the tooling had become t…
conceptTechnical Debt Quadrants
Distinguishing debt by whether it was taken deliberately or inadvertently, and prudently or recklessly, since the four kinds need different responses.
Neighbouring topics
Software Architecture
General material on the engineering underneath an architecture.
SOLID
Five design principles, two of which scale beyond the class.
Domain-Driven Design
Ubiquitous language, bounded contexts and context mapping.
Bounded Contexts
Where one model ends and another begins, and why forcing one fails.
Clean Architecture
Concentric layers with dependencies pointing only inwards.
Hexagonal Architecture
Ports defined by the domain, adapters supplied by infrastructure.
Microservices
Independent deployability, and the distributed problems it buys.
Modular Monolith
Enforced internal boundaries without a network between them.
Service Boundaries
Drawing lines along change patterns rather than technical layers.
Design Patterns
Reusable solutions at code level, and when they become ceremony.
Refactoring
Changing structure without changing behaviour, in verified steps.
Testing Strategies
The pyramid, and the contract tests distributed systems add to it.
Contract Tests
Capturing what consumers actually use, not what the API documents.
CI/CD
Continuous integration and delivery, and the architecture that caps them.
Release Strategies
Blue-green, canary, shadow and progressive delivery.
Feature Flags
Decoupling deploy from release, with an expiry date.
Trunk-Based Development
Short-lived branches, and unmerged work as inventory.
Code Review
Where architectural rules are enforced by people rather than by tools.
DORA Metrics
Throughput and stability moving together rather than trading off.