Part of the problem is an overemphasis on DRY as it pertains to allowing you to write less code. That's often a benefit, but it's not large and is easily dwarfe

Part of the problem is an overemphasis on DRY as it pertains to allowing you to write less code. That's often a benefit, but it's not large and is easily dwarfed by the cost of bad abstractions. On the other hand, DRY as a principle shines when it allows logical changes to a program to only require physical changes to the code in one place. E.g., in <horrible but self-contained algorithm> it's plausible that bugs might exist, and you'd really like bug fixes to apply to all implementations. The easiest way to manage that is to only have a single implementation. Likewise, to the extent that they're sometimes necessary your magic strings should be given a name so that your compiler can catch minor typos (supposing the edit distance between various names in your program is largeish).