Technical Debt
The future cost of a present shortcut, metaphorically accruing interest.
Technical debt is Ward Cunningham's metaphor for the cost incurred by choosing an expedient implementation over a better one: you ship sooner, and you pay interest on the difference in every subsequent change.
The metaphor is often flattened into "bad code", which loses what made it useful. Cunningham's point was that deliberately taking a shortcut can be correct, provided the debt is known and repaid. Debt taken knowingly, recorded, and scheduled is a financing decision. Debt taken unknowingly is just a defect with a nicer name.
Some recognizable forms: a workaround kept after its cause was fixed upstream; a duplicated implementation nobody consolidated; a guard suppressed rather than resolved; a deprecated dependency held back; a coverage shortfall inherited from a branch whose gate never ran. Each is cheap once and expensive per subsequent touch.
Two practices keep it visible. Record why a shortcut was taken and what would let it be removed, so a later reader is not stuck at Chesterton's Fence. And prefer paying an adjacent debt inside the change that exposes it over filing a follow-up item — a follow-up moves the work to a backlog that may never be read, while the person with the context is right there.
See also5
Deprecation
Marking something as superseded and scheduled for removal, without removing it yet.
Method15 connections
Documentation Rot
Documentation that has drifted from the system it describes, and is now worse than none.
Method27 connections
Code Review
A second person reading a change before it lands, and the practices that make it worth the time.
Version Control & Delivery25 connections
Root Cause Analysis
Escalating past the visible symptom until you find the layer that actually produced it.
Method49 connections
Feature Flag
A runtime switch that decouples shipping code from enabling behavior.
Data & Content12 connections
Related4
Nearby in the graph rather than deliberately chosen. Looser, sometimes surprising.
Linked from21
- Brooks's LawMethod
Adding people to a late software project makes it later, because onboarding and coordination costs outpace the new capacity.
- Chesterton's FenceMethod
Do not remove something whose purpose you cannot explain.
- Code CommentMethod
Prose inside source code, useful only when it records a constraint the code cannot state.
- DeprecationMethod
Marking something as superseded and scheduled for removal, without removing it yet.
- Documentation RotMethod
Documentation that has drifted from the system it describes, and is now worse than none.
- Factory GamePlay & Games
A genre whose core verb is building the machine that plays the game, turning the player into a systems engineer.
- Feature CreepMethod
A product accumulates features one reasonable addition at a time until the sum is bloated, slow, and hard to use.
- Feature FlagData & Content
A runtime switch that decouples shipping code from enabling behavior.
- FlanderizationMeaning & Society
A recurring character reduced, across a long run, to a single exaggerated trait.
- Gall's LawMethod
A complex system that works evolved from a simple system that worked; a complex system built from scratch never does.
- Live Service GamePlay & Games
A game operated as a running service rather than shipped as a finished artifact, with the consequences that shift implies.
- Not Invented HereMethod
The bias against adopting an outside solution simply because it wasn't built by your own team.
- Path DependenceMethod
Outcomes shaped by the sequence of past choices rather than by present merit.
- Premature OptimizationMethod
Spending effort making code fast before you know where it's actually slow trades clarity for speed you may not need.
- ProvenanceMethod
The recorded origin of a change or a claim — who made it, when, and on what evidence.
- Root Cause AnalysisMethod
Escalating past the visible symptom until you find the layer that actually produced it.
- Schema DriftData & Content
Divergence between a schema and the code, types, or documentation that describe it.
- Second-System EffectMethod
The tendency for a system's successor, freed of its predecessor's constraints, to become dangerously over-engineered.
- Sunk Cost FallacyMethod
Continuing an effort because of what has already been spent on it, rather than what remains to be gained.
- Worse Is BetterMethod
A simpler, less correct design that ships and spreads beats a more correct one that doesn't, because adoption compounds.
- Yak ShavingMethod
A chain of prerequisite tasks that stands between you and the task you meant to do.