6 ms·

Whenever I see things like this "law," or the ridiculous "DRY" principle, I'm glad I don't program deep in the OO paradigm. There have been so many code sins co

Whenever I see things like this "law," or the ridiculous "DRY" principle, I'm glad I don't program deep in the OO paradigm. There have been so many code sins committed in the name of DRY that I think it is a good interview question to ask why it is useful to not follow some of these guidelines.

twh270 7y ago
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.
- jrochkind1 7y ago
  Basically, over-engineering. 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-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.
  - hn23 7y ago
    I think that a good abstraction is not always obvious. For example, in our old code base from 2008, which is still in production and extended, the main idea was inheritance can solve DRY. Many developers still stick to abstract class just to save a few lines where they could go with a strategy or just split up. I wouldn't call this over engineering. I call it laziness to learn and refactor.
    - jrochkind1 7y ago
      I agree that a good abstraction is not always obvious, which is why we should try to avoid unneccesary abstractions (we probably won't get them right, at first, and they can be expensive to fix when we don't), which is why sometimes DRY can lead you wrong. Exactly my point. :)
  - BeetleB 7y ago
    >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. 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.
    - jrochkind1 7y ago
      Sure, and everyone complaining about OO isn't doing OO right, and everyone complaining about scrum or agile hasn't actually experienced scrum and agile correctly. "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.
  - vegannet 7y ago
    I hate very little in life but I can confidently say I hate “DRYing out code” because it’s _always_ used by developers who believe the repetitiveness of code dictate its quality. I have never seen a good commit for “DRYing out code” — in fact, that concept is usually a big red flag. 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.

twh270 7y ago

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.

jrochkind1 7y ago
Basically, over-engineering. 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-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.
- hn23 7y ago
  I think that a good abstraction is not always obvious. For example, in our old code base from 2008, which is still in production and extended, the main idea was inheritance can solve DRY. Many developers still stick to abstract class just to save a few lines where they could go with a strategy or just split up. I wouldn't call this over engineering. I call it laziness to learn and refactor.
  - jrochkind1 7y ago
    I agree that a good abstraction is not always obvious, which is why we should try to avoid unneccesary abstractions (we probably won't get them right, at first, and they can be expensive to fix when we don't), which is why sometimes DRY can lead you wrong. Exactly my point. :)
- BeetleB 7y ago
  >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. 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.
  - jrochkind1 7y ago
    Sure, and everyone complaining about OO isn't doing OO right, and everyone complaining about scrum or agile hasn't actually experienced scrum and agile correctly. "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.
- vegannet 7y ago
  I hate very little in life but I can confidently say I hate “DRYing out code” because it’s _always_ used by developers who believe the repetitiveness of code dictate its quality. I have never seen a good commit for “DRYing out code” — in fact, that concept is usually a big red flag. 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.