"Don't make the code so DRY it chafes"

In Go, the informal rule is to duplicate the second time you need a bit of code, and factor out only on the third time.

Yes, the middle ground is to avoid duplication when code is non-trivial.

Most code is trivial.

I think there's more to it than finding the middle ground.

The question we should ask is whether or A should change whenever B changes. If the answer is yes then there should be a dependency. If the answer is no then no dependency should exist, even if some lines of code happen to be identical at a particular point in time. (That's probably what you alluded to when you said "unrelated pieces of code" and I agree with that).

The number of lines of code shouldn't be the primary concern though.

For instance, if some tax is calculated in a particular way as a matter of law, then that calculation should exist exactly once in the entire code base, even if it's just one line of code.

> The question we should ask is whether or A should change whenever B changes.

Spot on.

Avoid applying DRY principles to incidental duplication.

Exactly right.