A View on Premature Optimization

Slow learner that I am - it took me some time to realize my own perspective on so-called "premature optimization":

Deciding against doing something because you're certain it won't help is just as premature an optimization as choosing to do something because you're certain it will help.

That came recently in the context of a discussion with colleagues around the tradeoffs in an HTTP caching design - in particular, does the latency you lose with validation-based caching responses (i.e. all the additional round trips, albeit with zero content length) rule out its use? One could speculate that yes, it does; but I would claim to not know without first measuring - and measuring within the parameters of the particular application in question.

And I guess that's my whole point. Assuming you've already optimized before testing/measuring with a well-known scalability strategy (one that balances round-trip latency cost with up-to-date staleness benefit) is a premature conclusion.

Measure first.