Technical Debt Management
The problem
Every codebase accumulates shortcuts taken under time pressure, and left unmanaged, that accumulation compounds — each new feature gets slower and riskier to build on top of an increasingly tangled foundation, until the team is spending more time fighting the codebase than building on it.
Why now
Refactoring already gave the tool for fixing structural debt; technical debt management is the deliberate practice of tracking that debt and deciding when paying it down is worth prioritizing over new features, using the same coupling-and-cohesion vocabulary to judge severity instead of relying on vague unease.
Mental model
Technical debt is a real analogy: a shortcut is a loan that buys speed now at the cost of slower changes later, and like financial debt, it's sometimes a reasonable deliberate choice (ship now, pay it down soon) and sometimes an unrecognized, compounding liability. Managing it means treating it as visible and trackable, not as ambient guilt — naming specific debts, in specific places, with a specific cost to leaving them unpaid.
Requires
- RefactoringEngineering Practices
Paying down technical debt is executed through refactoring; you need the safe, test-backed restructuring technique already covered as the mechanism before debt management's prioritization question (what to refactor, and when) is actionable.
- Coupling & CohesionSoftware Architecture
Judging how severe a piece of technical debt actually is requires the same vocabulary already covered — is this tightly coupled in a way that will keep costing us, or just superficially messy but harmless — rather than a vague, unquantified sense of unease.
Used in
- Sprint planning decisions balancing new features against debt paydown
- Explaining to non-technical stakeholders why 'just add the feature' isn't always the fast option
- Tracking specific, named technical debts (not vague 'the code is messy') in a backlog
- Deciding when a deliberate shortcut is worth taking, with an explicit plan to pay it down later
Projects
- Audit a real codebase and produce a prioritized list of specific technical debts, each with a concrete cost (what does leaving this unpaid make harder) and a rough paydown estimate
- Make and document a deliberate technical debt tradeoff for a hypothetical deadline — what shortcut you'd take, and the specific follow-up plan to pay it down
Examples
- A specific, named debt ('the payment module directly queries three other services' tables — should go through their APIs instead') is actionable; 'the code needs cleanup' is not
- Deliberately hardcoding a config value to hit a launch deadline, with a tracked follow-up ticket to externalize it properly afterward, is a managed debt, not an accident
Resources
Mastery checklist
- I can identify and precisely name specific technical debts in a real codebase, not just vague dissatisfaction
- I can estimate the ongoing cost of a specific piece of technical debt
- I can make a deliberate, tracked tradeoff to take on debt under a deadline
- I can prioritize which debts are worth paying down versus which are low-cost to leave alone