"Single source of truth" is more meaningful than the overly simplistic "DRY".

If two things are _supposed_ to behave similarly, then not having duplicate code makes perfect sense.

If two things just _happen_ to behave similarly (at first), it may be a hasty generalisation to immediately refactor them to use the same code.

> To add on to that, I think the key behind DRY is to not repeat a concept within your codebase, and not failing into the trap of avoiding similar but slightly different code blocks that aren't exactly logically equivalent by carving up your code into nonsense.

Dry is about not repeating behavior. It's not about not repeating text.

I’ve always found DRY to only apply well to two things:

- business logic

- something that your extracting as a library

It requires subtle thinking. Instead what I see a lot of the time is the "rule" of DRY applied with religious fervor, and it produces the kind of code I enjoy working with the least.

I tend to think of it in terms of bugs or less so, feature addition. Weighted by likelihood of bug.

If there is bug, will someone have to fix it in one place. Or, remember it’s in 7 places. If later I DRY.