Why does Technical Debt matter?
Debt is a legitimate, sometimes correct tool, shipping fast with a shortcut to learn whether anyone wants the product at all is a reasonable trade when the alternative is learning nothing for months. The mistake is not taking on debt; it's taking it on silently and never repaying it, so it compounds until a team that once shipped quickly can no longer ship anything without breaking something else. The founder-level decision is not whether to have technical debt, every real product does, but whether it's being tracked, whether it's deliberate, and whether repayment is scheduled rather than perpetually deferred behind the next urgent feature.
What does Technical Debt look like in practice?
Suppose the scheduling tool's first version hardcodes business hours as 9-to-5 because every design partner happened to keep those hours. That's a reasonable shortcut to ship faster. It becomes debt the moment a sixth practice with different hours signs up and the hardcoded assumption breaks their experience, and it becomes expensive debt if, by the time that happens, three other features have been built on top of the same assumption, so fixing it now means touching all three instead of one.
What are the common mistakes with Technical Debt?
- Treating all technical debt as equally urgent, when some shortcuts never get expensive and others compound fast.
- Never allocating dedicated time to repay debt, so it competes against features every sprint and always loses.
- Taking on debt accidentally rather than deliberately, not noticing a shortcut was even made until it breaks.
- Using "technical debt" as a blanket excuse for messy code rather than tracking specific, nameable shortcuts and their cost.
Where the term comes from
Ward Cunningham coined the debt metaphor in a 1992 OOPSLA experience report on a bond-portfolio product, WyCash, so the phrase was born out of literal financial software. His framing was narrower than today's usage: "Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite." The interest, he wrote, is "every minute spent on not-quite-right code".
Ward Cunningham, OOPSLA '92 ↗Related concepts
- Feature PrioritizationThe discipline of deciding what to build next using explicit, comparable criteria, rather than by whoever asked most recently or most loudly.
- Product Roadmap vs. BacklogA roadmap communicates the sequenced themes and outcomes you intend to pursue and why; a backlog is the working inventory of every discrete piece of work that could feed into it, prioritized but not promised.
- Minimum Viable Product (MVP)The smallest thing you can build that produces a real answer to the riskiest question about your business, not the smallest version of the product you intend to build.