Technical Debt in the Age of Cheap Code

The economics of technical debt rested on an assumption that's changing: that writing code was the expensive part. If creation gets cheap and maintenance doesn't, several standard conclusions invert.

What the old model assumed

Rewriting is expensive, so live with the imperfect version.

Duplication is bad because you maintain two copies — and writing the abstraction, though costly, pays back.

Prototypes become production because rewriting properly is unaffordable, so build it right the first time.

Debt accrues interest in the form of slower future changes.

Each of those was a reasonable inference from expensive creation.

What changes

Rewriting gets cheaper. Replacing a module rather than patching it becomes viable more often. → Which means "it's not worth rewriting" needs re-examining rather than assuming.

The prototype-to-production trap loosens. Throwing away a prototype and building the real thing is affordable, which was always the right answer and rarely the affordable one.

Duplication changes character. The cost of writing the second copy falls; the cost of maintaining divergent copies doesn't. So duplication is still bad, for the reason that always mattered rather than the one usually cited — and premature abstraction, which was already a common error, gets less justified.

⚠️ What gets worse

Volume debt. Cheap creation means more code exists. More surface, more dependencies, more configuration, more to understand — and comprehension didn't get cheaper.

Debt that's cheap to create and expensive to remove. A configuration option takes minutes to add and is supported forever. An API endpoint is easy to ship and hard to deprecate. The asymmetry between creation and removal cost widens, which is the least-discussed effect here.

Unexamined code. Debt used to be code someone wrote knowing the shortcuts. Now some of it is code nobody read carefully, where the shortcuts are unknown. That's a different and harder problem — you can't pay down debt you can't see.

Decision debt. The reasoning behind choices is less often recorded when the choice was made quickly by something that doesn't remember.

💡 The reframe

The scarce resource shifted from writing code to understanding and maintaining systems. So the debt that matters shifted with it:

Less important than it was: imperfect implementations, duplication, code that could be cleaner. These are cheaper to fix now.

More important than it was: things that expand what must be understood and supported — unnecessary services, surplus configuration, public interfaces you'll carry forever, dependencies, features nobody uses.

✅ Which means the highest-value discipline is no longer writing it well the first time. It's not creating it unless it's needed, because creation is cheap and the carrying cost is unchanged.

What to do differently

• Raise the bar on what gets built. The cost argument that used to do this work no longer does it, so the judgment has to.
• Treat every new interface, option, and endpoint as a permanent commitment, priced accordingly.
• Delete more aggressively. Removal is now relatively more valuable than it was, because volume is the debt that matters.
• Rewrite rather than patch where the module is well-bounded and testable — the arithmetic changed.
• Record decisions, since the code no longer carries the reasoning.
• Budget comprehension, not just creation. Someone reading and understanding a critical system is real work that produces no artifact and prevents real incidents.

The takeaway

Cheap creation makes implementation debt less costly and volume debt more costly, because understanding and maintaining didn't get cheaper. The asymmetry between how easy something is to create and how hard it is to remove has widened. So the discipline moves from writing it well to not writing it at all unless it's needed — and from paying down messy code to deleting surplus surface.