My takeaway from it is that we need to distinguish what you might call essential from incidental duplication. Essential duplication is when two bits of code are the same because they fundamentally have to be, and always will be, whereas incidental duplication is when they happen to be the same at the moment, but there's no reason for them to stay that way.
For example, calculating the total price for a shopping basket has to be the same whether it's done on the cart page or the order confirmation page [1], so don't duplicate that logic. Whereas applying a sales tax and applying a discount might work the same way now, but won't once you start selling zero-rated items, offering bulk discounts to which a coupon discount don't apply etc.
[1] Although i once built a system where this was not the case! In theory, the difference would always be that some additional discounts might be applied on the confirmation page. In theory ...
I don’t understand why people interpret that article as recommending you avoid prematurely removing duplication and comparing it to the rule of 3. The point of her essay is that you should resist the sunk cost fallacy and refactor your duplication-removing abstractions when requirements (or your understanding of them) change.
The problem isn't DRY. The problem is most programmers' inability to tear down abstractions that aren't correct for your new requirements when they evolve.
Yeah that sucks. Especially when you're designing service endpoints and your colleague insists upon reusing an existing endpoint instead of opening up a new one, because the two use cases looked the same when he squinted hard enough.
Now instead of /credit-card and /debit-card, which are independently testable, debuggable and changeable, you just have /card. Can't change the debit logic in /card because it will break credit. Can't change the credit logic in /card because it will break debit.
Well... early in my career, a colleague and I developed a bit of a mantra: "Did you fix it everywhere?" Later in my career, I learned the value of there only being one place to have to fix.
At the same time, too much DRY can over-complicate (and even obfuscate) your code. That's not the answer either.
Taste. Taste, experience, and wisdom. But I don't know how to give them to someone who doesn't have them. Maybe by pointing out the problems of specific things they're trying to do, in a way that they (hopefully) can understand and see why it's going to be a problem. Maybe...
by everything you mean outside of programming also? Or just in programming? I guess I find DRY pretty important for me, as a tool to force me to abstract and to help me understand the system I'm working on.
