Sandi Metz: When an Abstraction Goes Wrong, the Fastest Way Forward Is Back

Sandi Metz argues that a bad abstraction costs more than the duplication it was meant to eliminate. The failure mode is predictable: a developer spots repeated code, extracts it into a shared method or class, and moves on. Later, a new requirement almost fits the abstraction, so the next developer adds a parameter and a conditional rather than touching the shared code. Repeat that across several requirements and the once-clean abstraction degrades into a tangle of branching logic that is hard to read and easy to break.

The trap, she says, is the sunk cost fallacy. The more convoluted the shared code becomes, the more effort it appears to represent, and the more pressure developers feel to preserve it instead of replacing it. Her prescription is to reverse course: inline the abstracted code back into every caller, strip each copy down to only the path that caller actually uses, and delete the rest. Teams often discover that callers nominally sharing an abstraction were really running quite different logic. With the bad abstraction gone, the correct structure tends to reveal itself and new features get easier to add.

The takeaway for engineers is that an abstraction proven wrong should be abandoned early rather than propped up with more conditionals. Re-introducing duplication is not a retreat but a way to relearn what the right boundaries are. The piece, drawn from Metz’s 2014 RailsConf talk, remains a touchstone in discussions of maintainable object-oriented design, themes she expands in the second edition of ‘99 Bottles of OOP.’