This article's conclusion and headline is shallow. The example is a good one about where (depending on context), adding abstraction to reduce repetition might a

This article's conclusion and headline is shallow. The example is a good one about where (depending on context), adding abstraction to reduce repetition might add complexity. Great point! Repetition is fine in reasons like that. It does not invalidate DRY concerns in general! For example, an important reason to avoid repetition is that it adds maintenance inertia. Where a setup that a single-location change is easy to experiment with and improve, one that's repeated several places becomes tougher to change. Ie, friction. I would argue this is also adding complexity - what the author seeks to avoid. You could imagine contexts for the pizza example where the repetition doesn't make sense, and a refactor could make things easier. You can't tell alone from the snippet. From the headline and concluding paragraph, it feels like a straw-man. eg overrated, and: > "Well, obviously I'm not saying we should throw DRY completely out the window. I'm not sure it would actually be possible to write code that "never doesn't repeat itself". But I do think we should tone down knee jerk reactions to PRs that contain several repetitions of a block of code. There are at least a few cases where that might be the exact right thing to do."