June 21, 2026
Copy, paste, and cause a scene
Code duplication is far cheaper than the wrong abstraction
Why copying your work might be smarter than forcing one messy fix to do everything
TLDR: The big idea is that forcing one “clever” shared fix onto different problems often creates a bigger mess than simply duplicating some work. Commenters turned it into a showdown over bloated tools, personal coding tastes, and whether modern software loves bad shortcuts a little too much.
A long-running programming debate just got dragged back into the spotlight, and the crowd is very ready for a fight. The core claim from developer Sandi Metz is delightfully provocative: sometimes it’s cheaper to copy code than to keep stuffing every new problem into one “smart” shared solution. In plain English, she’s warning that a neat-looking shortcut can slowly mutate into a monster full of special cases, weird switches, and heartbreak. Her advice? If the shared fix becomes a mess, rewind, split it back up, and start fresh.
The comment section, naturally, turned this into a mini reality show. One camp was yelling “yes, finally!” at the idea that over-engineered systems are the real villain. The biggest eye-roll came from people burned by modern web stacks, with one commenter practically screaming that the Node.js world is “full of wrong abstractions” after wrestling with a towering pile of tools just to do something simple. Another commenter dropped the driest joke in the thread — “You can do both with microservices!” — which lands like a roast of the industry’s favorite habit: taking one mess and distributing it across twelve servers.
But not everyone was ready to crown duplication king. Some pushed back that the real issue is taste: everyone disagrees on what a “good” shared solution even is, and consistency can matter more than purity. Others offered a meme-worthy rule of thumb — “Twice a coincidence, thrice a pattern” — basically arguing: don’t merge things too early. The vibe? Equal parts therapy session, war story swap, and group confession from people haunted by “clever” code that aged like milk.
Key Points
- •The article republishes and lightly edits an essay that originated in the Chainline Newsletter and was prompted by discussion of a RailsConf 2014 talk.
- •It presents a common development pattern in which duplicated code is extracted into an abstraction that later accumulates parameters and conditional logic as requirements change.
- •The article argues that these changes can turn a once-shared abstraction into code that is hard to understand and easy to break.
- •It says developers often preserve such abstractions because existing code exerts pressure to retain prior work, which the article links to the sunk cost fallacy.
- •The recommended remedy is to inline the abstraction back into callers, remove unused branches, and then create new abstractions only after the real similarities are clear.