4 ms·

My favorite counter-acronym to DRY is WET: write everything twice (or thrice!). Doing and then redoing it once you understand it better is the best way to learn

by dahart 3y ago

My favorite counter-acronym to DRY is WET: write everything twice (or thrice!). Doing and then redoing it once you understand it better is the best way to learn how to apply DRY correctly. > Non-DRY code is by definition complex: You now have more interconnected parts than you need. So really, if you make your code more DRY, you _simplify_ it. It really depends, I think there are some assumptions here that could use clarification. The whole point of choosing duplication is to disconnect parts that shouldn’t be connected, so I don’t understand what you mean about non-DRY code being more interconnected than duplicated code. Conscious duplication (often called “forking”) allows people who depend on a piece of code to change it without breaking anyone else. When you merge two pieces of similar code, they already had two or more separate uses, and you’re adding a new connection, tying together the fates of two or more different users. From now on, if they don’t have exactly the same agenda, there will be tension and/or bugs. If deduplication requires adding an abstraction layer, then that absolutely is adding complexity, and it happens because the code being de-duplicated was not exactly the same. Code that’s truly duplicated doesn’t need to change in order to de-duplicate. So you can delete a copy in that case and centralize the dependencies onto the remaining copy. That eliminates code but doesn’t really simplify; it has the potential to simplify future development, but it doesn’t simplify the code at the moment of deletion. With modern build systems and project structures, however, it might take a lot of work and it might add complexity to get the DRY code into the right spot where it’s visible to everyone who needs it. Another reason for duplication is to avoid having to do backflips to get the code into the right file or scope.

hinkley 3y ago
For testing I prefer DAMP. Descriptive And Meaningful Prose/Phrases. I’ve watched otherwise smart people wrestle with testing boilerplate when requirements change and I’ve had my fill for this lifetime. Each test is a separate story. At most tests in a suite should share setup code. Anything more than that is coupling of tests, which is a no-no. The distinction between mocks and fakes are the most common place I see this blow up in our faces. Fakes result in coupling of tests. They were difficult to write so they get amortized across ten tests, making new requirements difficult to impossible to add without accidentally removing coverage of other requirements.
dgb23 3y ago
> Conscious duplication (often called “forking”) allows people who depend on a piece of code to change it without breaking anyone else. Then that code is DRY by definition and simpler. It can’t be Non-DRY because that would imply you’d need to change things in multiple places at once in order to avoid breakage. If you have two separate parts that can evolve independently, without coordination then those parts don’t represent the same piece of knowledge.
- dahart 3y ago
  Well all repeated code can evolve independently too, so by that definition, how can non-DRY code exist? This discussion is a bit too abstract and losing meaning as a result. I think you’re glossing over the very real scenarios of code (“knowledge”) that’s similar but not the exactly the same; of copies of code that are similar being merged; of code that’s exactly the same being intentionally forked and “repeated” and placed nearby; and others. Repeated code definitely can be the same piece of “knowledge” and exist in multiple places without coordination. After that the copies might drift in different directions, and the DRY dogma says this is bad. This is what people mean when they talk about DRY principles, the general idea to look for and merge similar code, and to prevent multiple pieces of similar code from being able to evolve independently. DRY in fact doesn’t really come up if two pieces of code are exactly the same; then it’s pretty obvious and easy to factor it. It’s a non-issue. The reason this is a concept we talk about is because bits of code are similar but not the same, or they’re they same but people need them to be modifiable without risk. I don’t know about using the word “knowledge” to represent processes with dependencies that change over time, it doesn’t seem like the best terminology for this discussion. Specifically, the word “knowledge” tends to imply a timeless static quality to the code. In reality all the of issues worth discussing here, all of the problems with DRY, and all of the benefits of DRY, relate to how code changes over time. Your point about similar but not the same code being different knowledge actually kind-of illustrates exactly why merging similar bits of code is dangerous, precisely why you shouldn’t just apply DRY principles blindly, and why sometimes rejecting the idea of DRY is appropriate in a given situation.
  - dgb23 3y ago
tcfhgj 3y ago
> My favorite counter-acronym to DRY is WET: write everything twice (or thrice!). Doing and then redoing it once you understand it better is the best way to learn how to apply DRY correctly. I don't like it. It's so much worse than DRY. Imagine you have something that is duplicated. Instead of deduplicating it, you leave it. Later at one location you make modifications, like rename a variable, introduce an optimization, whatever. Now, if you don't explicitly remember, that duplication is hidden. Months later you need to change or use the functionality somewhere else. How likely is it you'll edit it just in one place or introduce another duplication? Now let that run for a few years and you'll have this all over the code base. Sounds nice
- dahart 3y ago
  Sounds bad, the only problem is it’s a straw man imaginary scenario. Write everything twice isn’t a call to leave repeated code around at all, it’s a call to learn by doing rather than believe that dogmatic principles like DRY can get you there the first time. The idea behind WET is to use the right tool for the job, and acknowledging that you probably won’t know what the right tool is until after you’ve tried doing the job. DRY is the right tool for some jobs, but not all jobs. There are downsides to duplicating code, and there are downsides to merging code. I’ve seen examples of such downsides in both directions in practice. The main downside of DRY I was trying to point out in other comments is that multiple dependencies on code adds additional complexity and risk regardless of the quality of the abstraction. A lot of people here are arguing the quality of the abstraction is what matters, but that’s only sometimes true. And in the cases where eschewing DRY is called for, it often has nothing to do with the quality of the abstraction.
  - tcfhgj 3y ago
    Your interpretation of wet has nothing to do with wet.

by dahart 3y ago

hinkley 3y ago

For testing I prefer DAMP. Descriptive And Meaningful Prose/Phrases. I’ve watched otherwise smart people wrestle with testing boilerplate when requirements change and I’ve had my fill for this lifetime. Each test is a separate story. At most tests in a suite should share setup code. Anything more than that is coupling of tests, which is a no-no. The distinction between mocks and fakes are the most common place I see this blow up in our faces. Fakes result in coupling of tests. They were difficult to write so they get amortized across ten tests, making new requirements difficult to impossible to add without accidentally removing coverage of other requirements.

dgb23 3y ago

> Conscious duplication (often called “forking”) allows people who depend on a piece of code to change it without breaking anyone else. Then that code is DRY by definition and simpler. It can’t be Non-DRY because that would imply you’d need to change things in multiple places at once in order to avoid breakage. If you have two separate parts that can evolve independently, without coordination then those parts don’t represent the same piece of knowledge.

dahart 3y ago
Well all repeated code can evolve independently too, so by that definition, how can non-DRY code exist? This discussion is a bit too abstract and losing meaning as a result. I think you’re glossing over the very real scenarios of code (“knowledge”) that’s similar but not the exactly the same; of copies of code that are similar being merged; of code that’s exactly the same being intentionally forked and “repeated” and placed nearby; and others. Repeated code definitely can be the same piece of “knowledge” and exist in multiple places without coordination. After that the copies might drift in different directions, and the DRY dogma says this is bad. This is what people mean when they talk about DRY principles, the general idea to look for and merge similar code, and to prevent multiple pieces of similar code from being able to evolve independently. DRY in fact doesn’t really come up if two pieces of code are exactly the same; then it’s pretty obvious and easy to factor it. It’s a non-issue. The reason this is a concept we talk about is because bits of code are similar but not the same, or they’re they same but people need them to be modifiable without risk. I don’t know about using the word “knowledge” to represent processes with dependencies that change over time, it doesn’t seem like the best terminology for this discussion. Specifically, the word “knowledge” tends to imply a timeless static quality to the code. In reality all the of issues worth discussing here, all of the problems with DRY, and all of the benefits of DRY, relate to how code changes over time. Your point about similar but not the same code being different knowledge actually kind-of illustrates exactly why merging similar bits of code is dangerous, precisely why you shouldn’t just apply DRY principles blindly, and why sometimes rejecting the idea of DRY is appropriate in a given situation.
- dgb23 3y ago

tcfhgj 3y ago

> My favorite counter-acronym to DRY is WET: write everything twice (or thrice!). Doing and then redoing it once you understand it better is the best way to learn how to apply DRY correctly. I don't like it. It's so much worse than DRY. Imagine you have something that is duplicated. Instead of deduplicating it, you leave it. Later at one location you make modifications, like rename a variable, introduce an optimization, whatever. Now, if you don't explicitly remember, that duplication is hidden. Months later you need to change or use the functionality somewhere else. How likely is it you'll edit it just in one place or introduce another duplication? Now let that run for a few years and you'll have this all over the code base. Sounds nice

dahart 3y ago
Sounds bad, the only problem is it’s a straw man imaginary scenario. Write everything twice isn’t a call to leave repeated code around at all, it’s a call to learn by doing rather than believe that dogmatic principles like DRY can get you there the first time. The idea behind WET is to use the right tool for the job, and acknowledging that you probably won’t know what the right tool is until after you’ve tried doing the job. DRY is the right tool for some jobs, but not all jobs. There are downsides to duplicating code, and there are downsides to merging code. I’ve seen examples of such downsides in both directions in practice. The main downside of DRY I was trying to point out in other comments is that multiple dependencies on code adds additional complexity and risk regardless of the quality of the abstraction. A lot of people here are arguing the quality of the abstraction is what matters, but that’s only sometimes true. And in the cases where eschewing DRY is called for, it often has nothing to do with the quality of the abstraction.
- tcfhgj 3y ago
  Your interpretation of wet has nothing to do with wet.