Prefer duplication over the wrong abstraction (2016)
“Prefer duplication over the wrong abstraction” revisits the trade-off between repeating code and creating shared abstractions, arguing that premature or ill-fitting abstractions often introduce more complexity and coupling than they remove. Commenters explore heuristics like the “rule of three,” the importance of distinguishing coincidental similarity from true shared behavior, and the long-term pain of both over-engineered frameworks and sprawling copy‑paste. Several note that modern tooling and LLMs change the cost profile of duplication and refactoring, but that the core challenge remains an art: finding stable, domain-appropriate abstractions without forcing them too early.
Scope of the Debate: Duplication vs. Abstraction
- Many agree with the core idea: premature or “wrong” abstractions can be more damaging than small, local duplication.
- Others push back that large-scale duplication can become catastrophic, especially in long‑lived, multi‑customer or multi‑team systems.
- Several argue the slogan is often misread; it’s about avoiding premature or coincidental abstractions, not a license to copy‑paste forever.
When Duplication Is Useful
- Repeated implementations can be a tool to discover the right abstraction: “write it twice or thrice, then refactor” (rule of three / WET).
- Duplication is seen as cheaper and safer early, especially when business requirements and domain boundaries are still unclear.
- Some prefer isolated, slightly duplicated flows over a brittle “god abstraction” with many flags and conditionals.
When Abstractions Go Wrong
- Examples: over‑generic frameworks, forced polymorphism, microservice “distributed monoliths,” Redux-heavy frontends, and DRY taken to extremes.
- Wrong abstractions tend to:
- Encode accidental similarities rather than true shared concepts.
- Spread hidden coupling, making every change risky and global.
- Accumulate boolean/config parameters and complex call chains.
- Some contend that any maintainable abstraction is better than widespread duplication past a “de minimis” scale; others strongly disagree.
Heuristics and Rules of Thumb
- Common heuristics:
- Don’t abstract after one occurrence; consider it after two; act after three, if they truly represent the same concept and change for the same reasons.
- Prefer abstractions that are obvious and self‑justifying from their own interface, not only from knowledge of callers.
- Favor loose coupling and simple support libraries over deep, centralized “clever” frameworks.
- Abstract for ease of future replacement, not speculative reuse.
LLMs and the Cost Curve
- Some note LLMs make duplication cheaper to create and refactor, potentially shifting the tradeoff toward simpler, more duplicated code.
- Others report LLMs introduce more duplication and can miss all instances when refactoring, so abstractions still matter.
- General view: AI changes the economics but doesn’t remove the need to reason about abstraction vs. duplication.