Every piece of knowledge must have a single, unambiguous, authoritative representation within a system
This is not really about duplicated strings of characters.
DRY is about duplicated concepts
"P.J. Plauger says his major concern is "the principle One Right Place - there should be One Right Place to look for any nontrivial keys of code, and One Right Place to make a likely maintenance change" (Plauger 1993) (#)
The fewer places you have to look for something, the easier and safer it will be to change.
In blog-post-emails-are-views DHH talks about incidental-duplication
DRYing out 'concepts' exposes sameness and enables reuse; DRYing incidental-duplication lies about sameness and impedes change. (#)
if things will change for different reasons you probably don't need to dry it up (#)
In tests, when faced with duplication vs. readability, I tend to favor readability in my tests a little bit more than I do in my production code. (#)
My first step when fixing something that's out-of-control is to 'duplicate all the code'. (#)
Even when there is sameness, I think there's "must-DRY" (e.g. calculations around money) and "nice-to-DRY" (e.g. styling). (#)
"Duplication Is Better Than The Wrong Abstraction
The next thing we were told to do goes against all intuition.
Write shameless code, full of duplication just to make the tests green."
To write code that's easy to delete: repeat yourself to avoid creating dependencies, but don't repeat yourself to manage them. (#)
By default, good code tends to be modular and easy to replace, while bad code is excessively coupled and hard to get rid of. So bad code has a disproportionate impact on long-lived codebases. I wonder if one way around this is to force modularity, even when it's unnatural. Functional programming seems to be one way of doing this, microservices are another. A related principle would be not to take DRY too seriously, favoring decoupling over deduplication. (#)