I like that you've brought this up. You've raised the all-important practical side of software development. Life is about choices - selecting one thing over another. If the time to get the project live is constant, then you may need to choose between an implementation that works, and one that is fast. The warning against premature optimisation is well-deserved: it's far better to be slow and right than it is fast and wrong. I can always throw a faster CPU at the problem to speed it up, but I can't always throw hardware at a problem to correct the answer. That requires programmer time - which is far more expensive.

The product I work on has a key component of speed. It must respond within a certain amount of time - and that amount is always lessening. And, just for fun, we keep the hardware constant (or we adjust our requirements based on the new hardware). But then, to meet that requirement, we actually pay a group of people to focus solely on finding bottlenecks and reducing, if not outright eliminating, them. That's just the management-recognised cost of performance. We pay 20 people to get it right, and 2 people to get it fast. Trading off money for performance in the same amount of time.

If you don't have the budget to get everything done on time, working, and fast enough, I would have to drop "fast enough" every time. It's much easier to make a slow, working application fast than a fast, non-working application correct.

There are some simple things one can do to keep from getting slow in the first place, e.g., in C++, I encourage my coworkers to do:

  const size_t len = strlen(some_string) + strlen(other_string) + 1;
  char* copy = new char[len];
  memcpy(copy, '\0', len);
[download]

rather than doing that strlen twice each. (Well, actually, I encourage them to put the new and memcpy into an inline function.) Is that premature? Perhaps - but I look at it as a way to reduce the chance of errors: rather than duplicating code, I'm refactoring it. In a way that allows the compiler to make its own optimisations. That it allows the compiler to optimise isn't a premature optimisation - it's just a smarter way to do something which happens to be a faster alternative.

I suppose that means that even within "premature optimisation", there is a lot of fuzziness and leeway as to what constitutes "premature". Or even "optimisation".