I get what you're saying, and sort of agree, but I think your examples show a misunderstanding of DRY.
The point is not how long it takes a dev to create a stylized button. The point is that if the button is to be used in several places, there's one official representation of it. That way, it's consistent everywhere, and if it ever needs to be changed, it can be done in one place instead of all over your application so you can miss 3 instances of it and end up with an inconsistent interface. That's a UX example, of course, but the principle is the same for non-visual applications and their underlying APIs.
I agree with you! I may not have made it super clear, but I think DRY when applied correctly isn't bad. The examples are definitely a exaggeration, but I think the exemplify the style of DRY programming that can happen when you don't agree on how to abstract or define when exactly you shouldn't repeat yourself.
I think having a rule like "Write Everything Twice" is actually the right way of achieving the same end as DRY. You get good abstractions and you don't spend a ton of time trying to generalize the components you don't need to generalize.
I would argue that it is better to have to miss a single instance and have to update it later than to have too many abstractions that have to be really general or abstract to function.
To me, the best abstractions are ones where you don't feel like you are working with an abstraction. Instead it just feels like the "right" way of accomplishing what you are trying to accomplish.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I get what you're saying, and sort of agree, but I think your examples show a misunderstanding of DRY.
The point is not how long it takes a dev to create a stylized button. The point is that if the button is to be used in several places, there's one official representation of it. That way, it's consistent everywhere, and if it ever needs to be changed, it can be done in one place instead of all over your application so you can miss 3 instances of it and end up with an inconsistent interface. That's a UX example, of course, but the principle is the same for non-visual applications and their underlying APIs.
I agree with you! I may not have made it super clear, but I think DRY when applied correctly isn't bad. The examples are definitely a exaggeration, but I think the exemplify the style of DRY programming that can happen when you don't agree on how to abstract or define when exactly you shouldn't repeat yourself.
I think having a rule like "Write Everything Twice" is actually the right way of achieving the same end as DRY. You get good abstractions and you don't spend a ton of time trying to generalize the components you don't need to generalize.
I would argue that it is better to have to miss a single instance and have to update it later than to have too many abstractions that have to be really general or abstract to function.
To me, the best abstractions are ones where you don't feel like you are working with an abstraction. Instead it just feels like the "right" way of accomplishing what you are trying to accomplish.