3 ms·

I have never, in 18 years of professional programming, heard "premature optimization..." used to mean that "you should never optimize your code!" Not saying it

I have never, in 18 years of professional programming, heard "premature optimization..." used to mean that "you should never optimize your code!" Not saying it never happens, but I have never heard it once used that way. I do occasionally hear it used to mean "don't spend the time to optimize until you have measured whether this is your bottleneck and it will actually matter", or "get it working first so that you know this is actually what you even want, otherwise you will end up optimizing things that get cut soon after". Both of which are valid.

trashtester 4y ago
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.
JKCalhoun 4y ago
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).
- peteradio 4y ago
  > 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.
- TeMPOraL 4y ago
  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 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.
cratermoon 4y ago
> 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"

trashtester 4y ago

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.

JKCalhoun 4y ago

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).

peteradio 4y ago
> 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.
TeMPOraL 4y ago
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 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.

cratermoon 4y ago

> 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"