That's actually more or less how DRY is described in The Pragmatic Programmer (20th anniversary edition):
> Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
Further on:
> Dry is about the duplication of knowledge, of intent. It's about expressing the same thing in two different places, possibly in two totally different ways. [emphasis in original]
And the next paragraph:
> Here's the acid test: when some single facet of the code has to change, do you find yourself making that change in multiple places, and in multiple different formats? Do you have to change code and documentation, or a database schema and a structure that holds it, or...? If so, your code isn't DRY.
Early in my career, a co-worker and I developed the habit, when a bug was fixed, of asking each other "Did you fix it everywhere?"
But that's the problem right there. Why is there more than one place to fix it?
(Now, sure, if you're using a function call wrong, you need to fix it everywhere you call that function, and it's fine that there are multiple such places. That's what functions are for. But if it's something like how a value is calculated... why is there more than one place that calculates the value?)
Related tangent: "AHA" (Avoid Hasty Abstractions) is a decent counter to the over-application of DRY. IME, people reach for DRY too quickly, at the expense of other worthy but more subtle principles.
I think the old "remove duplication the third time you write it" is bad advice as well, to be honest.
First off, it excuses some really egregious behaviour like copying entire large chunks of code representing an identical concept just because "I haven't copied it twice yet". I've seen an entire controller and all related views copied wholesale because it needed to be placed in another area of the app (with identical visual and functional requirements)
Secondly, if the code is only incidentally identical, even 3 times isn't enough to say that you should apply DRY. 3 independent concepts that happen to currently share implementation still shouldn't be deduplicated. I think a great example of this is the inherited resources gem in rails that implements a "standard" interpretation of controller actions - which works well at first until your controllers need to do something other than basic CRUD. The fact that say, an update action handles parameters and saving in the same way as some other update action may currently be true, but is not at all guaranteed to be true in the future, even if you have 100 update actions in your app.
If you know what application you are writing, there is absolutely no reason to do WET. You should always know if some code repetition is real or accidental.
But we don't always know what application we are writing.
I've pointed out in the past that if the characters you're deduplicating don't actually have the same meaning, you're just compressing your code; I've been trying to popularize labelling that kind of aggressive misapplication of DRY "Huffman coding".
On the other hand, if you keep repeating the same character sequence there is probably some structure on your code that you can also abstract away. You are not restricted to factoring business concepts.
There's clearly structure you can abstract away; doing so may be convenient, and that convenience may even make it a good idea. I contend, though, that if it does not represent a "piece of knowledge" that you're factoring out then you are dealing with concerns other than "DRY".
I do agree that a piece of knowledge may not be a business concept.
> Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
Further on:
> Dry is about the duplication of knowledge, of intent. It's about expressing the same thing in two different places, possibly in two totally different ways. [emphasis in original]
And the next paragraph:
> Here's the acid test: when some single facet of the code has to change, do you find yourself making that change in multiple places, and in multiple different formats? Do you have to change code and documentation, or a database schema and a structure that holds it, or...? If so, your code isn't DRY.