Lexicon

Technical Debt

n.—what you didn't fix, now compounding with interest.

Ward Cunningham coined the phrase as early as 1992, in an experience report presented at OOPSLA. It was an accounting metaphor, not a complaint: a shortcut in code is a loan against future time, and like any loan, it accrues interest until it's paid down. The metaphor is more precise than the way it's usually deployed—as a vague way of saying "stuff we should clean up someday"—because real debt has terms. It compounds. Some of it is worth taking on deliberately, the way a business takes on debt to grow faster than savings alone would allow.

What I find useful is pushing the metaphor past code, into how organizations actually run. Obsolete structures nobody revisits are legacy code left untouched. Friction with rules nobody questions anymore is hard-coded logic. Duplicate effort across teams that don't talk to each other is a redundant codebase. A lack of shared narrative about why things are the way they are is poor documentation. Capabilities nobody activated is a dormant API.

None of these show up on a balance sheet, which is exactly why they're dangerous in the same way technical debt is dangerous—invisible until the interest payment comes due all at once, usually at the worst possible moment, usually disguised as an unrelated crisis.

The discipline I respect most in engineering teams—and the one I think transfers most directly to how an organization should run—is not avoiding debt entirely. It's knowing which debt was taken on consciously, in service of real speed, and which one accumulated by default because nobody was tracking it.