[jchook]

It seems, early on, software devs mis-learn the meaning of “DRY” to mean “abstract away all repetition”.

It takes experience to unlearn this bad habit and realize that “duplication is cheaper than the wrong abstraction”[1].

While this post may not provide a perfect example I think it gestures in the general direction of this very important principle.

1. https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction

[hansvm]

Part of the problem is an overemphasis on DRY as it pertains to allowing you to write less code. That's often a benefit, but it's not large and is easily dwarfed by the cost of bad abstractions.

On the other hand, DRY as a principle shines when it allows logical changes to a program to only require physical changes to the code in one place. E.g., in <horrible but self-contained algorithm> it's plausible that bugs might exist, and you'd really like bug fixes to apply to all implementations. The easiest way to manage that is to only have a single implementation. Likewise, to the extent that they're sometimes necessary your magic strings should be given a name so that your compiler can catch minor typos (supposing the edit distance between various names in your program is largeish).

[amw-zero]

DRY is absolutely essential. You can defer abstractions, sure, but ideal software is DRY.

[amw-zero]

The problem with Sandi’s catchy phrase, is that it’s a claim with absolutely no backing. What is the cost model for software? How do you measure the cost of an abstraction vs. duplication?

It’s really silly to argue about this stuff. This claim has no evidence. For example, I feel the exact opposite, that abstracting early always makes it easier to refactor, and does not prevent ending up at better abstractions later on in any way.

I _feel_ like that’s true. And you can’t prove or disprove either side without agreeing on a cost model.