Comment by ndiddy | Hacker News Reader

Comment by ndiddy | Hacker News Reader

Parent Full thread

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

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.

> Make It Work

> Make It Right

> Make It Fast

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

Reply on news.ycombinator.com