I've personally, in my 25 years of professional programming, heard it many times to mean "I don't want to consider performance at this stage of development, I want to move ALL optimization to when the code is done."

Typically after I've made comments on their design very early in the development process about the code being doomed to be very slow, in a manner that cannot be solved by optimizing small parts of the code later (so will require a rewrite).

And I'm not talking about the small wins, that make things 10-50% faster. I'm talking about design mistakes that slow down the code by several orders of magnitude. (Big-O stuff), and that is represented at a point in the design that is so fundamental it's hard to fix without scrapping everything.

An example might be images used as thumbnails in the UI. If they are fetched over the network, you might as well plan to have a local image cache. No need to wait on that one - and I would not call that premature optimization. Perhaps others would though (ha ha, and perhaps they’re right if there is already a cache in some other hidden part of the pipeline - yes, I am undercutting my own argument).

> if there is already a cache in some other hidden part of the pipeline

Still counts as a win, you can IME take out a cache mechanism easily. If somebody wants to ding you for writing excess code I don't know what to tell you, they are probably a-holes.

The problem is that in real world, you have to assume corners will be cut. Deadline pressure is the one constant, and Parkinson's law reigns supreme[0]. You may reason that a local cache is a premature optimization, then what happens is that those UI thumbnails get shipped in the prototype quality, they end up blocking the UI loop on network, and nobody ever goes back to implement local caching, because there are always new features with new deadlines on them.

Postponing optimization is fine, but if everyone is just postponing it, and nobody is treating it as priority, then it just never gets done. In most software, low performance is effectively an externality - it's unlikely to be the thing that kills your product/business[1], but it's causing real frustration in people and waste real money in the overall economy.

----

[0] - "Work expands so as to fill the time available for its completion"; https://en.wikipedia.org/wiki/Parkinson%27s_law.

[1] - Or at least not obviously so. Performance issues often masquerade under general complaints of bad UX, or the software feeling "off" somehow. Also performance is often a limiting factor in use cases; it can be what enables you to access a whole new market segment, or deny it to you.

> don't spend the time to optimize until you have measured whether this is your bottleneck and it will actually matter

Also seen as "don't optimize the idle loop"