3 ms·

> don't try DRY until you've seen at least three repetitions A significant number of bugs I've had to fix over the years were the result of just two repetition

by samspot 14y ago

> don't try DRY until you've seen at least three repetitions A significant number of bugs I've had to fix over the years were the result of just two repetitions. Invariably someone updates one of them and not the other one. Or copies the first one, then updates, then forgets. This happens over and over and over and over. I'm so sick of it that I want to punch my coworkers (I don't usually get angry quickly but this has been wearing on me for a few years now). So I will continue to refactor at the second copy.

oinksoft 14y ago
As Djikstra said, "two or more, use a for."
- stcredzero 14y ago
  That's not entirely relevant in this context. We're talking about two similar bits of code in entirely different parts of the codebase.
dasil003 14y ago
The number of repetitions is a red herring. It's more a question of which business flows the code adheres to, and what's the likelihood that a change in one should also affect a change in the others. Often this is a gray distinction and it amounts to a judgement call about what type of changes and what mindset will the maintainer come in with in the future. I'd like to think that with experience I've gotten much better at this, but it's exceedingly hard to get anything besides infrequent anecdotal evidence. Working on the same code base for 5 years, every once in a while I get the joy that comes with discovering that I made a good decision years ago, beating the YAGNI odds or leaving a particularly relevant comment that saved me significant re-investigation of a difficult issue. But how could studies on this type of long-term maintainability draw meaningful conclusions? It just seems incredibly intractable from a scientific perspective—a result of experience and thoughtful consideration outweighing formal, documented and trainable techniques.

3 ms·

> don't try DRY until you've seen at least three repetitions A significant number of bugs I've had to fix over the years were the result of just two repetition

by samspot 14y ago

oinksoft 14y ago
As Djikstra said, "two or more, use a for."
- stcredzero 14y ago
  That's not entirely relevant in this context. We're talking about two similar bits of code in entirely different parts of the codebase.
dasil003 14y ago
The number of repetitions is a red herring. It's more a question of which business flows the code adheres to, and what's the likelihood that a change in one should also affect a change in the others. Often this is a gray distinction and it amounts to a judgement call about what type of changes and what mindset will the maintainer come in with in the future. I'd like to think that with experience I've gotten much better at this, but it's exceedingly hard to get anything besides infrequent anecdotal evidence. Working on the same code base for 5 years, every once in a while I get the joy that comes with discovering that I made a good decision years ago, beating the YAGNI odds or leaving a particularly relevant comment that saved me significant re-investigation of a difficult issue. But how could studies on this type of long-term maintainability draw meaningful conclusions? It just seems incredibly intractable from a scientific perspective—a result of experience and thoughtful consideration outweighing formal, documented and trainable techniques.