The wrong abstraction: why software engineers should prefer duplication over a premature abstraction

Software teams everywhere are taught the slogan: "DRY — Don't Repeat Yourself." For decades it was treated as the cornerstone of code quality. In a short 2016 blog post, Sandi Metz argued that the rule has been wildly mis-applied: the wrong abstraction is far more expensive than duplication. This week the essay returned to the top of Hacker News, drawing thousands of comments.

Metz is one of the best-known names in OO design and the Ruby community; her book Practical Object-Oriented Design in Ruby is standard course material. The Wrong Abstraction is only nine paragraphs long, but its endurance is worth examining.

Metz's thesis is plain. When you see similar patterns repeating in a codebase, it is tempting to immediately extract a common abstraction — a helper function, an abstract class, a generic interface. But this premature decision is risky: you do not yet know how the patterns will diverge in future. Over the years, the abstraction bends a little for each new caller, parameters accumulate, conditional logic creeps in — and the abstraction becomes far more complex than the problem it was originally trying to solve.

Her line: "Duplication is cheap. The wrong abstraction is very expensive to reverse." Because once the team has built around the wrong abstraction, undoing it means untangling every call site, finding the genuine seam, and rebuilding the code on the other side. That is many times more work than simple copy-paste.

Metz acknowledges that duplication feels scary to engineers: "Seeing the same 20 lines in three places, the voice in your head saying 'DRY this up' is normal. Resisting that instinct goes against the reflex our engineering training has reinforced." Her recommendation is to wait until the pattern has repeated three or four times before extracting. By then you can see which parts of the code are truly shared and which are context-specific.

In the microservice and API era, this matters more, not less. Every new shared library is a coupling between teams; over time that coupling becomes a substantial component of technical debt. Wikipedia editor and former Google engineer Hyrum Wright formalised the related principle now known as Hyrum's Law: "With a sufficient number of users of an API, all observable behaviours of the system — not just the ones stated in the contract — will be depended on by somebody." That is why the real-world cost of the wrong abstraction is so high.

Metz's essay regained currency in 2025-2026 because AI-assisted coding tools — GitHub Copilot, Claude Code, Cursor — can be very aggressive about pattern detection and abstraction suggestion. A commenter on Hacker News wrote: "Copilot is constantly suggesting that I 'DRY' three functions; the three functions still serve genuinely different domains. Premature consolidation is a much more common mistake in the AI era."

Metz's counter is that abstraction is the product of understanding the differences, not of recognising similarity: "Two things looking alike does not mean they should be abstracted. First map the dimensions on which they differ; only abstract once you can say 'all those differences will remain fixed in future.'" That sentence is one of the most-quoted pieces of software-engineering writing of the last decade.

The long-run view, in practice, is that undoing the wrong abstraction is often "half of technical debt". Former Stripe principal engineer Patrick McKenzie made a similar observation in a 2024 essay: "The most expensive engineering decisions of Stripe's early years were shared abstractions taken too early. Each one took six months on average to unpick."

The lasting reason Metz's essay endures is that it is language- and stack-agnostic. C++, Java, Python, Rust or TypeScript — Ruby or Go — does not matter. The wrong abstraction is a property not of the coding language but of the engineering decision itself. That is why a 2016 essay still hits a 2026 reader as freshly useful. One important nuance: Metz does not say "DRY is always wrong" or "duplication is always right". Her claim is that the real cost of an abstraction decision is much higher than most engineers estimate.