The Fallacies of Premature Optimization

I think ten or more years ago there existed this fear that developers were spending an inordinate amount of time on optimization. That they were thinking about, planning for, and handling performance problems that might never come. As a result, someone came up with "avoid premature optimization" as a handy bit of advice for junior (and non-junior) developers. In my experience, this has only served as rationale for developers to simply avoid dealing with it entirely and/or to be lazy.

I've worked with countless junior, regular, and "senior" developers writing garbage code that makes spurious network calls, database queries, or is polynomial in complexity. When pointed out, their response is always "that sounds like premature optimization." That bit of advice is bandied about like an unbreakable shield guarding them against having to write good code. In every one of those instances the code was quickly described by the organization as "bad", "slow", "tech debt", and "needing to be rewritten".

• Good code generally takes into account time and space complexity
• Good code generally avoids needless network calls
• Good code generally avoids needless latency

Premature optimization is spending a week trying to shave off another 50ms on an API that is rarely called. If it were frequently called then it would be warranted optimization.

Skipping the above steps isn't premature optimization - it's bad programming.