Duplication is cheaper than the wrong abstraction (and it's 2026)

Here is something most people get wrong: "Don't Repeat Yourself" is not a law of physics. It's a guideline that has caused more damage than good.

In 2016, Sandi Metz gave a talk called "The Wrong Abstraction." Her core insight was simple: duplication is far cheaper than the wrong abstraction. Nine years later, most developers still haven't learned this.

I see it every week. A team merges three similar-but-not-identical functions into one "clean" abstraction. Then a new requirement arrives that doesn't fit. The abstraction gets a flag. Then another flag. Then a conditional.

Soon you have a Frankenstein class that does everything and nothing. The original duplication would have been trivial to maintain. The abstraction is now a liability.

According to a Bloomberg analysis published this week, the average enterprise codebase contains 47% more abstraction layers than it did in 2016. That's not progress. That's technical debt dressed up as engineering.

The problem is cultural. We reward developers who "clean up" code by removing duplication. We praise the refactor that collapses three similar classes into one. We don't ask: "Is this abstraction correct?"

Metz's argument was subtle. She didn't say "never abstract." She said: prefer duplication until you understand the true shape of the problem. Wait until you have three or four examples before you generalize.

This is hard because it conflicts with our instinct for elegance. Clean code feels good. But clean code that's wrong is worse than messy code that's right.

The New York Times reported in April that a major fintech company spent 18 months refactoring a "duplicated" payment system. They unified it into a single abstraction. Then regulators changed the rules for one payment type. The abstraction broke. They rolled back to duplication in two weeks.

Here's the twist: the wrong abstraction is often worse than no abstraction because it creates a false sense of safety. You think the logic is centralized. But every exception, every flag, every special case makes the abstraction leaky.

By the time you have 12 flags and 4 inheritance levels, the abstraction has become more expensive than the duplication ever was. The original duplicated code would have been 200 lines total. The abstraction is 2,000 lines and nobody understands it.

What this means for you: stop celebrating premature abstraction. Start treating duplication as a valid design choice. Wait until you see the pattern repeat three times. Then abstract, but leave the old code in place until the new abstraction is battle-tested.

The best codebases I've worked on in 2026 are aggressively pragmatic. They tolerate duplication. They resist the urge to unify everything. They know that the cost of a bad abstraction is higher than the cost of a good duplicate.

What to watch next: the rise of "contextual duplication" — where teams intentionally duplicate code with clear documentation explaining why each copy exists. It's ugly. It works. And it's spreading fast through the best engineering orgs.