I've never interpreted "Premature optimization..." to mean don't think about performance, just that you don't have to actually implement mechanisms to increase performance until you actually have requirements to do so - you should always ask of a design "how could I make this perform better if I had to".

To me, it rather meant: "Ultrahard" optimization is perfectly fine and a good idea, but not before it has become clear that the requirements won't change anymore (because highly optimized code is very often much harder to change to include additional requirements).

Any different interpretation in my opinion leads to slow, overbloated software.

Yeah - I've heard that described as "It's easier to make working things fast than fast thing work" - or something like that.

I've found that mentioning bloat is the fastest way to turn a technical conversation hostile.

Do we need a dozen components of half a million lines each maintained by a separate team for the hotdesk reservation page? I'm not sure, but I'm definitely not willing to endure the conversation that would follow from asking.

It is forever baffling to me that so many devs don’t seem to appreciate that small performance issues compound, especially when they’re in a hot path, and have dependent calls.

Databases in particular, since that’s my job. “This query runs in 2 msec, it’s fast enough.” OK, but it gets called 10x per flow because the ORM is absurdly stupid; if you cut it down by 500 microseconds, you’d save 5 msec. Or if you’d make the ORM behave, you could save 18 msec, plus the RTT for each query you neglected to account for.

> Too many people have the "Premature optimization is the root of all evil" quote internalized to a degree they won't even think about any criticisms or suggestions.

Yeah I find it frustrating how many people interpret that quote as "don't bother optimizing your software". Here's the quote in context from the paper it comes from:

> Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. 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.

Knuth isn't saying "don't bother optimizing", he's saying "don't bother optimizing before you profile your code". These are two very different points.

I'm old.

My boss (and mentor) from 25 years ago told me to think of the problems I was solving with a 3-step path:

1. Get a solution working

2. Make the solution correct

3. Make the solution efficient

Most importantly, he emphasizes that the work must be done in that order. I've taken that everywhere with me.

I think one of the problems is that quite often, due to business pressure to ship, step 3 is simply skipped. Often, software is shipped half-way through step 2 -- software that is at best partially correct.

The pushes the problem down to the user, who might be building a system around the shipped code. This compounds the problem of software bloat, as all the gaps have to be bridged.

I've found that sometimes if you start 1. without even considering 3. it can be significant amounts of work to go back and restructure. Especially if in doing 3. is a fairly big change that results in lots of QA.

So for example, we have a lot of code that just does some work every render frame, when really it should only do that work when values change. Whats worse is that, every frame, the code queries parameters that are accessors in c# which in turn do heaps more work.

I had to fix a lot of these kinds of things when trying to do get our game to work on the Nintendo Switch.

> Make It Work

> Make It Right

> Make It Fast

https://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast

I like Knuth and think he’s a great writer, but this particular paper [1] is… hard to read. Almost as if it is an unedited stream of consciousness rather than something he intended to be published.

Reading the section you are quoting from (as well as the section of the conclusion dealing with efficiency), I think it should be clear that in the context of this paper, “optimization” means performance enhancements that render the program incomprehensible and unmaintainable. This is so far removed from what anyone in the last 30+ years thinks of when they read the word “optimization” that we are probably better off pretending that this paper was never written. And smacking anyone that quotes it.

[1] https://dl.acm.org/doi/10.1145/356635.356640

I actually think it's a lovely paper (and he obviously intended to publish it, and put a lot of effort into compiling and editing it) and illustrates the nature of his writing very well: he's managed to be encyclopedic about all the topics he chose to discuss, while still having it be very personal (the matter at stake is one of programmers' style and preferences after all). This blog post (https://blog.plover.com/prog/Hoare-logic.html) calls it “my single all-time favorite computer science paper” and here's a recent HN thread with at least two others agreeing it's a great paper: https://news.ycombinator.com/item?id=44416265

I've posted a better scan here: https://shreevatsa.net/tmp/2025-06/DEK-P67-Structured.progra...

What I once said to a less experienced developer in a code review is:

> Don't write stupid slow code

The context was that they wrote a double-lookup in a dictionary, and I was encouraging them to get into the habit of only doing a single lookup.

Naively, one could argue that I was proposing a premature optimization; but the point was that we should develop habits where we choose the more efficient route when it adds no cost to our workflow and keeps code just as readable.