Creating an abstraction that makes no sense is worse than just having code being there twice (e.g. different codebases). I worked with a guy who would apply DRY to literally everything like it was a panacea. It was an awful time.
I've done a lot of legacy work, and most repetition is due to a loss of business context. Naturally support staff don't want to be hero's and make big changes.
Right now I work with a system that's been in active development for 30 years and it's a dream to work on because everyone knows it and I can just ask some of the original authors what something is, or to explain an edge case.
Most dev's aren't that lucky.
that very much depends of how the function is called. there are a lot of ways I've encountered in the wild which wouldn't be found by this.
> Creating an abstraction that makes no sense is worse than just having code being there twice
The key point being 'that makes no sense'.
If you have experience as a software engineer you understand that most 're-use' isn't completely de-duping a function, but instead you see it being abstracted out into a more generic fn that can handle two or more _slightly different_ use cases.
This typically makes the original intent of the fn difficult to understand
Some programmers do this and then pat themselves on the back, repeating the 'DRY' mantra to themselves and everyone else around them.
80% isn't completely pulled out of thin air, the vast majority of fn abstraction leads to a less understandable (therefore less maintainable) codebase.