How is applying DRY entering premature optimization territory (maybe relative to LOC?)? I argue it is instead: premature abstraction.
Optimization is specialization (which is the opposite of DRY): to enable DRY you likely need to generalize the problem (i.e. abstract) such that you remove duplication.
I've always seen "Premature Optimization" as an umbrella that covers a variety of cross-cutting concerns, ranging from:
- Performance
- Code structure / abstraction
- Data structure
- Team organization / org structure
I'd argue that DRY (and a focus on abstractions more generally) are optimizations of the codebase. Not all optimizations are optimizing the same thing.
Yeah, it's like reminding people that code can change, so it's ok to have known flaws day 1. Something forgotten too often.
One thing that really goes against the usual programming grain is DBMSes. We're taught to always decouple/abstract things, but I'm convinced that it's impossible to abstract away your DBMS in most applications. It's just too big of an interface, and performance considerations leak right through it. It's always one of the selling points of an ORM, "you can switch databases later," and then nobody actually switches.
Optimization is specialization (which is the opposite of DRY): to enable DRY you likely need to generalize the problem (i.e. abstract) such that you remove duplication.