DRY is one of those principles that can be taken way too far (namely, it often leads to building towers of abstractions which only loosely fit to avoid (mostly) repeating yourself even once). A while ago, someone (I believe the following is the original, but I am not sure) advocated for WET (Write Everything Twice), less because writing a second instance gives you the opportunity to see what differences exist before refactoring out the common bits (though, to your point in the article, that may indeed be a benefit), but more because it offers an opportunity to avoid premature abstraction.
Upon reading it, I jokingly came up with MOIST (Mostly One Instance; Sometimes Two) with the idea that while there are plenty of times you probably have the same pattern which should be abstracted to a single instance as-needed, you may sometimes need multiple copies of “the same” code which will actually differ slightly due to differing requirements in the use (e.g., this might be preferable over a function taking a boolean argument). I even wrote a small shell script which very naïvely determines the moistness of your code (by checking that the total lines of code is roughly 1.3 times the size of the unique lines of code). :P
I’ve called this the ‘WET-DRY’ principle in the past, sharing many of the same concerns as OP. “WET-DRY” = “Write Everything Twice, (then) Don’t Repeat Yourself”.
It is much easier for me to extract the whole repetition if I let it replicate a few times. Much less likely I extract the wrong abstraction.
I recall the notion of writing stuff multiple times before you try to abstract it floating around for many years. Of course whether that’s a good idea depends on context, but incremental insight is our great friend while doing software development for sure.
A measure of how much “grease” there is in code sounds cool! You could then measure what is the optimal level of codebase grease, though I imagine in applications the optimal amount of grease is going to be much bigger than in libraries for instance.
DRY is one of those principles that can be taken way too far (namely, it often leads to building towers of abstractions which only loosely fit to avoid (mostly) repeating yourself even once). A while ago, someone (I believe the following is the original, but I am not sure) advocated for WET (Write Everything Twice), less because writing a second instance gives you the opportunity to see what differences exist before refactoring out the common bits (though, to your point in the article, that may indeed be a benefit), but more because it offers an opportunity to avoid premature abstraction.
Upon reading it, I jokingly came up with MOIST (Mostly One Instance; Sometimes Two) with the idea that while there are plenty of times you probably have the same pattern which should be abstracted to a single instance as-needed, you may sometimes need multiple copies of “the same” code which will actually differ slightly due to differing requirements in the use (e.g., this might be preferable over a function taking a boolean argument). I even wrote a small shell script which very naïvely determines the moistness of your code (by checking that the total lines of code is roughly 1.3 times the size of the unique lines of code). :P
All the best,
-HG
I’ve called this the ‘WET-DRY’ principle in the past, sharing many of the same concerns as OP. “WET-DRY” = “Write Everything Twice, (then) Don’t Repeat Yourself”.
It is much easier for me to extract the whole repetition if I let it replicate a few times. Much less likely I extract the wrong abstraction.
I recall the notion of writing stuff multiple times before you try to abstract it floating around for many years. Of course whether that’s a good idea depends on context, but incremental insight is our great friend while doing software development for sure.
A measure of how much “grease” there is in code sounds cool! You could then measure what is the optimal level of codebase grease, though I imagine in applications the optimal amount of grease is going to be much bigger than in libraries for instance.