Premature optimization

Sometimes you hear developers say: "Knuth has said that premature optimization is the root of all evil, so we'll just make things work for now and we'll make them fast later".

Software developed with this premise rarely gets fast, not even later. If you think about it, would you feel comfortable with the approach "we'll add error checking later"?

Now, Knuth normally doesn't write unwise things, at he didn't do it in this case either, but his words have been taken out of context and misused. If you look at page 268 in this possible source of the quote, you can see that it expands to

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3 %. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified.

In other words, we should only focus on optimizing the parts of the software that has an impact on overall performance.

So how do we know which these parts are? Developers are known to be notoriously bad at guessing this, but the old profiling trick works well in this case too. The important thing is to profile constantly during the development and to have performance goals that the profiling results can be compared to. The real question is not if the code is fast, but if the code is fast enough.