Huh, I've always understood that quote very differently, with emphasis on "premature" ... not as in, "don't optimize" but more as in "don't optimize before you've understood the problem" ... or, as a CS professor of mine said "Make it work first, THEN make it work fast" ...

Another one from my personal experience: apply DRY principles (don't repeat yourself) the third time you need something. Or in other words: you're allowed to copy-and-paste the same piece of code in two different places.

Far too often we generalise a piece of logic that we need in one or two places, making things more complicated for ourselves whenever they inevitably start to differ. And chances are very slim we will actually need it more than twice.

Premature generalisation is the most common mistake that separates a junior developer from an experienced one.

> and the missing context is essential.

Oh yes, I'd recommend everyone who uses the phrase reads the rest of the paper to see the kinds of optimisations that Knuth considers justified. For example, optimising memory accesses in quicksort.

I was a bit worried you are paraphrasing Rob Pike, but no, he actually agrees with that Knuth quote.

I am almost certain that people building bloated software are not willfully misunderstanding this quote; it's likely they never heard about it. Let's not ignore the relevance of this half a century old advice just because many programmers do not care about efficiency or do not understand how computers work. Premature optimization is exactly that, the fact that is premature makes it wrong, regardless if it's about GOTO statements in the 70s or a some modern equivalent where in the name of craft or fun people make their apps a lot more complex than they should be. I wouldn't be surprised if some of the brutally inefficient code you mention was so because people optimized prematurely for web-scale and their app never ever needed those abstractions and extra components. The advice applies both to hackers doing micro-optimizations and architecture astronauts dreaming too big IMHO.

Ignoring optimization opportunities until you see the profile only works when you actually profile!

Profiling never achieved its place in most developers’ core loop the way that compiling, linting, or unit testing did.

How many real CI/CD pipelines spit out flame graphs alongside test results?

I don't think the quote itself is responsible for any of that.

It's true that premature optimization (that is, optimization before you've measured the software and determined whether the optimization is going to make any real-world difference) is bad.

The reality, though, is that most programmers aren't grappling with whether their optimizations are premature, they're grappling with whether to optimize at all. At most companies, once the code works, it ships. There's little, if any, time given for an extra "optimization" pass.

It's only after customers start complaining about performance (or higher-ups start complaining about compute costs) that programmers are given any time to go through and optimize things. By which point refactoring the code is now much harder than it wouldn've been originally.

Totally agree. I’ve see that quote used to justify wilfully ignoring basic performance techniques. Then people are surprised when the app is creaking exactly due to the lack of care taken earlier. I would tend to argue the other way most of the time: a little performance consideration goes a long way!

Maybe I’ve had an unrepresentative career, but I’ve never worked anywhere where there’s much time to fiddle with performance optimisations, let alone those that make the code/system significantly harder to understand. I expect that’s true of most people working in mainstream tech companies of the last twenty years or so. And so that quote is basically never applicable.

I wish we lived in a world where quotes could be that powerful. But I'm afraid in reality this quote, like any other, is just used as a justification after the fact.

Actually, I do not believe devs are to blame, or that CS education is to blame; I believe that's an unfortunate law of society that complexity piles up faster than we can manage it. Of course the economic system rewards shiping today at the expense of tomorrow's maintenance, and also rewards splitting systems in seemingly independent subsystems that are simpler in isolation but results in a more complex machinery (cloud, microservices...)

I'm even wondering if it's not a more fundamental law than that, because adding complexity is always simpler than removing it, right? Kind of a second law of termodynamic for code.

Slow code is more of a project management problem. Features are important and visible on the roadmap. Performance usually isn't until it hits "unacceptable", which may take a while to feed back. That's all it is.

(AI will probably make this worse as well, having a bloat tendency all of its own)

This discussion kind of irks me. I just read these posts as: "The quote saying A is bad. Actually it said A all along!"

It's just complaining about others making a different value judgement for what is a worthwhile optimization. Hiding behind the 'true meaning of the quote' is pointless.

> generations of programmers have now been raised to believe that brutally inefficient, bloated, and slow software is just fine.

I believe people don't think about Knuth when they choose to write app in Electron. Some other forces might be at play here.

A lot of developers get enamored by fetishes. Just one example, because it's one i always struggle to vanquish in any of my teams.

Devs are obsessed with introducing functional-style constructs everywhere, just for the sake of it. FP is great for some classes of software, but baseline crufty for anything that requires responsiveness (front-ends basically), let alone anything at real interactive speeds (games, geo-software, ...)

The "premature optimization" quote is then always used as a way to ignore that entire code paths will be spamming the heap with hundreds of thousands of temporary junk, useless lexical scopes, and so forth. Writing it lean the first time is never considered, because of adherence to these fetishes (mutability is bad, oo is bad, loops lead to off-by-one errors, ...). It's absolutely exhausting to have these conversations, it's always starting from the ground up and these quotes like "premature optimization is the root of all evil" are only used as invocations to ward of criticism.

> From his 1974 paper, "Structured Programming with go to Statements":

> He was talking about using GOTO statements in C.

I don’t think he was talking about C. That paper is from December 1974, and (early) C is from 1972, and “The UNIX Time-Sharing System” (https://dsf.berkeley.edu/cs262/unix.pdf) is from July 1974, so time wise, he could have known C, but AFAICT that paper doesn’t mention C, and the examples are PL/I or (what to me looks like) pseudocode, using ‘:=’ for assignment, ‘if…fi’ and ‘while…repeat’ for block, ‘go to’ and not C’s ‘goto’, etc.

> Multiple generations of programmers have now been raised to believe that brutally inefficient, bloated, and slow software is just fine

100%

I agree. Faster hardware or horizontal scaling on distributed cloud environments can mask the problem; but it certainly doesn't solve the problem of bloated, inefficient software.

While it might not be necessary to spend hours fine-tuning every function; code optimization should be the mindset of every programmer no matter what they are coding.

How many fewer data centers would we need if all that software running in them was more efficient?

https://didgets.substack.com/p/finding-and-fixing-a-billion-...

I think the bigger problem is that "Premature optimization is the root of all evil" is a statement made by software engineers to feel more comfortable in their shortcomings.

That's not to bemoan the engineer with shortcomings. Even the most experienced and educated engineer might find themself outside their comfort zone, implementing code without the ability to anticipate the performance characteristics under the hood. A mental model of computation can only go so far.

Articulated more succinctly, one might say "Use the profiler, and use it often."

Picking the starting point is very important. "optimization" is the process of going from that starting point to a more performant point.

If you don't know enough to pick good starting points you probably won't know enough to optimize well. So don't optimize prematurely.

If you are experienced enough to pick good starting points, still don't optimize prematurely.

If you see a bad starting point picked by someone else, by all means, point it out if it will be problematic now or in the foreseeable future, because that's a bug.

I hear you, friend!

While you were seeing those problems with Java at Google, I saw seeing it with Python.

So many levels of indirection. Holy cow! So many unneeded superclasses and mixins! You can’t reason about code if the indirection is deeper than the human mind can grasp.

There was also a belief that list comprehensions were magically better somehow and would expand to 10-line monstrosities of unreadable code when a nested for loop would have been more readable and just as fast but because list comprehensions were fetishized nobody would stop at their natural readability limits. The result was like reading the run-on sentence you just suffered through.

Don't confuse premature pessimization for the warnings against premature optimization.

I can write bubble sort, it is simple and I have confidence it will work. I wrote quicksort for class once - I turned in something that mostly worked but there were bugs I couldn't fix in time (but I could if I spent more time - I think...)

However writing bubble sort is wrong because any good language has a sort in the standard library (likely timsort or something else than quicksort in the real world)

Anyone else feel like bloat is usually not an algorithmic problem, but rather a library or environment issue most of the time?

Totally agree. Out of this context, the word "premature" can mean too many things.

As someone currently writing 16-18 tables all with common definition, and crud, Id like some abstraction

I always point out the operational word is "premature".

> Multiple generations of programmers have now been raised to believe that brutally inefficient, bloated, and slow software is just fine. There is no limit to the amount of boilerplate and indirection a computer can be forced to execute. There is no ceiling to the crystalline abstractions emerging from these geniuses. There is no amount of time too long for a JVM to spend starting.

I think that's due to people doing premature optimization! If people took the quote to heart, they would be less inclined to increasing the amount of boilerplate and indirection.

At least before the LLM world you would have to trade money (aka more compute) for time to market. What is the point of spending a single second optimizing a query when your database has 10 users?

Of course today this has changed. You can have multiple agents working on micro optimizing everything and have the pie and eat it too.

I too learned this the hard way, via a supposedly concurrent priority queue that did quadratic-time work while holding a lock over the entire thing. I was told that "premature optimization is the root of all evil."

Sorry, folks, but that's just an excuse to make dumb choices. Premature _micro_optimization is the root of all evil.

EDIT: It was great training for when I started working on browser performance, though!

This is the sort of pontifical statement that old guys like me tend to make which is strictly wrong but also contains a lot of wisdom.

Yes, software is bloated, full of useless abstractions and bad design. You kids(well, anyone programming post 1980, so myself included) should be ashamed. Also let's not forget that those abstractions helped us solve problems and our friends in silicon valley(ok that no longer makes sense but imagine if SillyValley still just made HW) covered our mistakes. But yeah, we write crap a lot of the time.

But as other folks have said, it doesn't mean "don't optimize."

I've always used my own version of the phrase, which is: "Don't be stupid." As in, don't do dumb, expensive things unless you need to for a prototype. Don't start with a design that is far from optimal and slow. After profiling, fix the slow things. I'm pretty sure that's what most folks do on some level.

In all honesty, this is one of the less abused quotes, and I have seen more benefit from it than harm.

Like you, I've seen people produce a lot of slow code, but it's mostly been from people who would have a really hard time writing faster code that's less wrong.

I hate slow software, but I'd pick it anytime over bogus software. Also, generally, it's easier to fix performance problems than incorrect behavior, especially so when the error has created data that's stored somewhere we might not have access to. But even more so, when the harm has reached the real world.

So you're saying people have misunderstood "premature optimisation is the root of all evil" as "optimisation is the root of all evil"?

I don't think you can blame this phrase if people are going to drop an entire word out of an eight word sentence. The very first word, no less.

> I have lived the absolute nightmares that evolve from the willful misunderstanding of this quote.

how do you know which code was written using this quote in mind.

It has less to do with a quote and more to do with CS education (and the market) rewarding minimal functionality over performance, security, fault-tolerance, etc.

The average university CS student in USA (and India I presume) is taught to "hack it" at any cost, and we see the results.

> I have lived the absolute nightmares that evolve from the willful misunderstanding of this quote.

Then the quote wasn’t the problem. The wilful misunderstanding was the problem.