I'm curious, what code sins do you see committed in the name of DRY? I ask because in my org there's rarely even an attempt made to DRY anything, so I'm not really aware of how people screw it up.
One example, sometimes DRY'ing up things that just happen to use the same logic now, but don't existentially/necessarily use the same logic. When they stop using the same logic, you add extra 'magic flags', or you've got to undo the architecture.
Sandi Metz says "prefer duplication over the wrong abstraction ". https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstracti... She also writes about how devs are reluctant to change existing abstractions (for both rational and irrational reasons), making the wrong abstraction even more expensive.
Which isn't to say that lots of duplication all over the place is a good sign either, obviously not.
I wouldn't call this over engineering. I call it laziness to learn and refactor.
Exactly my point. :)
The DRY principle was created by the authors of The Pragmatic Programmer, and as they formulated it, your example is not DRY.
DRY is about requirements, not code or logic. The specification of a requirement should exist in only one place in the code. It aims to reduce instances of "The requirement changed, and I thought I fixed all the places in the code, but I forgot one and it became a bug." If two pieces of code have very similar logic/code structure, but are tied to different features, then the DRY principle absolutely does not suggest you should refactor to make that logic appear in only one place.
Pretty much every time I've seen people complaining about DRY, they're complaining about something unrelated to the original DRY principle.
"No true scotsman" is a very popular way to argue about programming on the internet.
But the original question was "what code sins do you see committed in the name of DRY?", right?
I think in practice it can be hard for many people to tell the difference between "the specification of the requirement being in more than one place" and other kinds of apparent code duplication. Because it's not always entirely obvious what "the specification of the requirement" is, or what it looks like implemented in code.
Because it's so easy to do DRY "wrong", or to think you know what it means but be incorrect (in general or a specific situation), is exactly why one should be careful about it, and just because something appears to you (or a colleague) to be about "DRYing up the code" doesn't necessarily mean it's a good idea.
It doesn't mean there's nothing of value in the principle, just that one should be careful with it.
There are few principles of software engineering that don't have some truth, and also few that aren't misused or abused.
Certainly that particular example of "things that just happen to use the same logic now, but don't existentially/necessarily use the same logic" is exactly a description of when not to de-duplicate code, that's why I mentioned it! It is a "sin committed in the name of DRY", one reason to identify it is to hopefully help others avoid it. The point is not that people doing that are getting DRY right, it's exactly that they're getting it wrong, but in the actual world of actual code, it is gotten wrong with some frequency.
If you aren't sure whether two passages of code that seem similar are really sharing a "specification of a requirement in code" or not, those of us who have experienced (and written!) lots of code that errs in acting as if they were, might urge to prefer risking error on the side of acting as if they were not. Or, again, as Sandi Metz says, duplication can be better than the wrong abstraction.
There's a huge difference between OO/scrum/agile and the DRY principle. OO does not have a well defined origin and definition. Agile does, and is intentionally not well defined. Scrum does have an origin, but I bet if you read the original author's description of it, you'll find it also is not well specified. Pick any "No True Scotsman" argument and the root cause of all of them is the lack of a clear definition. That's simply not the case with DRY.
Furthermore, all these three are a lot more complicated than the DRY principle.
The DRY principle has an origin, and a well established meaning. If you go to its Wiki page, it's nice, concise, and precise. There's no real dispute about it. Generally, those accused of misusing it have never even read the definition, and are taking a concept they heard from an Nth degree source and are interpreting it by its name.
There are likely more people in the world who misuse the principles of quantum physics than those who use it and understand it properly. We don't criticize quantum physics for it. It is precise, and is not the cause of all its misuses.
The other problem I have about people criticizing the "overuse" of DRY: Had the DRY principle never been formulated, you would see no less of it. Coupling different requirements via a common code merely because the logic is identical is probably as old as programming itself. I myself was guilty of this (and bitten by it) long before I had heard of the DRY principle. Someone formulating the DRY principle did not exacerbate the problem. People creating these problems are mislabeling them because they've heard of the principle's name. My challenge to you: Whenever someone couples code in the name of DRY, ask them where they learned that they should do this. I doubt any of them will list any reputable book, for example.
Which again contrasts this with OO/scrum/agile, of which there are several books with quite different interpretations, and where one of the key annoyances is that everyone can back their stance using well known books.
Getting DRY right can be quite challenging in some projects - I'm not trying to claim otherwise. In fact, I believe the original authors were not speaking only of code, but also of documentation, databases, etc. One representation that will cover all of the above. It is clearly challenging to take it to that level. I'm all for criticizing it on those grounds. My complaint is that every criticism I've seen of it wasn't about how difficult it is to follow correctly, but about someone coupling two clearly different requirements with common code.
I’m quite attracted to writing “good” code — in that I think about theory and principles a lot — and “DRY” is not part of my vocabulary. I very much agree with your point that over-engineering is a problem but DRY is not related to that.