[horsawlarway]

Bad abstractions tie together components that shouldn't have been tied together.

Too many bad abstractions are how you quickly end up with that "Bad code base" that you believe is difficult to change - Things are wrong because they're tied together in ways that don't actually make sense, and changing code to support refactoring one use-case creates a wave of cascading changes to other places those abstractions are touched/consumed. If you miss one, or forget an edge case, or have a skimpy test suite - suddenly that refactoring you're so keen on is what's introducing new things that are "wrong" - because they shouldn't have been tied together but were, and you don't understand or remember all of the edge cases.

Basically - My rebuttal is this: It's very easy to refactor a codebase with duplication and introduce an abstraction for the current behavior. It's very HARD to refactor a codebase riddled with abstractions that shouldn't be there.

This means that by default - abstractions should only be introduced very carefully. Refactoring is fine, but you're paying more to refactor a bad abstraction than to refactor duplication. Good programmers understand that most of their value isn't in what their code looks like - it's in what it does for the users. Duplication can feel dirty, and it tends to trigger a "puzzle game" mentality in a lot of programmers, who want to fit the pieces together to make it pretty. AVOID THIS INSTINCT.

[cogman10]

Agree completely.

I've dealt with too many code bases that didn't follow this advice. It's extremely expensive to cut down capabilities from code because they are overly coupled.

DRY tends to create things like utility classes and deep dependency trees. For example, I saw a non-ui code base that pulled in JavaFX to use their pair class.