The problem often arises when two pieces of code happen to look the same, but are conceptually doing two different things.
I have seen far too many codebases where a junior engineer took it upon himself to DRY-ify two similar looking bits of code, only to have to later go start adding knobs and if-branches to handle differing evolution between the two problem domains.
If the original piece of code had some logic bug, sure, it will likely be necessary to go fix that bug in all of the duplicated spots. But if the code evolves in one place due to the problem domain changing slightly, that rarely implies that the duplicated code needs to change.
I coined it initially for configuration management, but... "Keep accidental an intentional identity apart".
By that I try to convey that just because two things look the same doesn't mean that they are by necessity the same. So if it is a case of "happens to look the same", keep things separate, but if they're fundamentally linked, keep only one copy and reference it.
In terms of code, I think that means "repeat the codepath if the two copies just happen to look the same today, but are not necessarily going to do so in the future" and "if the code paths are always going to be identical, make a function/procedure". That can probably e extended to subclassing as well.
I have seen far too many codebases where a junior engineer took it upon himself to DRY-ify two similar looking bits of code, only to have to later go start adding knobs and if-branches to handle differing evolution between the two problem domains.
If the original piece of code had some logic bug, sure, it will likely be necessary to go fix that bug in all of the duplicated spots. But if the code evolves in one place due to the problem domain changing slightly, that rarely implies that the duplicated code needs to change.