Sandi Metz’s post says the expensive mistake is not duplication by itself but collapsing superficially similar code into one abstraction before you know whether the cases really belong together. Her warning is aimed at the familiar failure mode where a shared helper starts simple, then accretes booleans, enums, and branching to satisfy callers that only looked alike for a moment in time. The practical advice people kept returning to was that code should be shared when it changes for the same reasons, not when it merely looks similar today. That produced a rough consensus around a narrower heuristic than the headline suggests: small, local duplication is often fine, especially early, but large-scale repeated logic with real shared meaning should still be consolidated.
The strongest additions were about locality and semantics. Several commenters said the main cost of a bad abstraction is that it destroys local reasoning. A small change in one feature suddenly requires understanding unrelated callers and preserving a broad
API surface. Others sharpened the distinction between "
single source of truth" and copy-paste avoidance. If divergence would be a bug, refactor. If two pieces of code are semantically different and are likely to evolve differently, keeping them separate is not a
DRY violation at all. That is why the common smell mentioned over and over was the reusable function that grows feature flags and mutually exclusive parameters.
Where people pushed back, they usually did so on scale and org reality. In messy production systems, duplication rarely stays at two copies. It becomes dozens of drifted variants that no one can reliably find, test, or update together. Some argued that even an imperfect abstraction at least gives you a named entry point to grep for, while duplicated logic disappears into the codebase and compounds under deadline pressure. That led to a more grounded middle position than the slogan implies: use duplication as a discovery tool, then abstract once the common shape is empirically clear. Several people explicitly cited a rule of three, or said they leave comments and revisit later rather than forcing reuse on the second sighting.
LLMs came up as a new variable, but not a settled one. Some think they lower the cost of duplication because they can find repeated patterns and apply parallel edits. Others said the opposite is already happening in large codebases, with agents spraying near-duplicate code and then missing one variant when asked to update it. The more durable point was that AI does not rescue a bad abstraction and may amplify whichever maintenance habit a team already has. The thread landed on an old lesson that still holds: prefer abstractions that are obvious from the domain and easy to explain without reference to quirky callers. If you cannot justify the shared code on its own terms, the reuse is probably premature.