Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Often I hear the sentiment ...

"Why worry about performance, write slow code, get your product to market ... don't worry about performance. You can sort that out later"

The culmination of this sentiment is:

"... premature optimization is the root of all evil ... #winning"

I was wondering, does anybody have a good retort to this one liner. Ideally an equally strong one liner that encompasses the reverse of this sentiment?

share|improve this question

closed as not constructive by gnat, Caleb, Jimmy Hoffa, Giorgio, GlenH7 Apr 17 '13 at 17:13

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

25  
Isn't the original: "the LOVE of money is the root of all evil?" –  barrycarter May 28 '11 at 15:41
78  
The correct sentiment is not to "write slow code" but rather to write the simplest possible implementation that can be easily and quickly implemented (i.e. code which saves your psychological health and time), and to ignore performance constraint until you know that it matters. –  Lie Ryan May 28 '11 at 16:22
14  
@barrycarter I believe the most scholarly translation is "The love of money is the root of all kinds of evil." –  ErikE May 28 '11 at 18:06
11  
"Premature pessimization is the root of unuseable software" –  quant_dev May 28 '11 at 20:54
9  
@Django: Because it's invariably used as a petulant excuse for criminally inefficient designs? –  Aaronaught May 28 '11 at 22:20

36 Answers 36

up vote 41 down vote accepted

I find the best retorts to be:

  • "polly want a cracker?"
  • mindless mantras are anathema to productive thought
  • dogma smothers karma
share|improve this answer
9  
+1 for point two! –  Max May 28 '11 at 15:08
8  
@Tchalvak: I think it means parrots just repeat what they've heard, and so do some programmers. –  Mike Dunlavey May 28 '11 at 18:46
36  
Kunth's quote is not "mindless mantra" it is taken out of context by people that don't understand its meaning, and make it mean whatever they want it to mean personally, much like any religious text that is mis-quoted and twisted around. The key word is PREMATURE which means, optimization before you actually KNOW what you need to be focusing on. –  Jarrod Roberson May 29 '11 at 18:18
6  
We should forget about small inefficiencies, say 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. Donald Knuth –  Jarrod Roberson May 29 '11 at 18:23
9  
@Jarrod: the question was a request for retorts. No one is questioning Knuth's wisdom. Calm down. Breathe. There. OK, now consider that for people who don't understand its meaning and who quote this out of context, it becomes a mindless mantra. Q.E.D. ;-) –  Steven A. Lowe May 29 '11 at 18:35

The best retort might be to memorize Knuth's entire dialogue about optimization and repeat it back to them verbatim. It's unlikely they'll ever say anything to you about optimization again! :)

There is no doubt that the grail of efficiency leads to abuse. 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. It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail.

Donald Knuth, 1974

share|improve this answer

Duplicate code is the root of all evil !

My retort suggests that there is a greater root of all evil: Duplicated code.

Quoting wikipedia: ( should I say duplicating wikipedia )

The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." The principle has been formulated by Andy Hunt and Dave Thomas in their book The Pragmatic Programmer. They apply it quite broadly to include "database schemas, test plans, the build system, even documentation."1 When the DRY principle is applied successfully, a modification of any single element of a system does not require a change in other logically unrelated elements. Additionally, elements that are logically related all change predictably and uniformly, and are thus kept in sync. Besides using methods and subroutines in their code, Thomas and Hunt rely on code generators, automatic build systems, and scripting languages to observe the DRY principle across layers.

The DRY Principle: Don't repeat yourself (wikipedia page):

Here's another link. An article

And related books:

  • "The Pragmatic Programmer" by Andrew Hunt, David Thomas
  • "Refactoring: Improving the Design of Existing Code" by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts
  • "Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin
share|improve this answer
1  
While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. –  Glenn Nelson Apr 17 '13 at 16:03

"This is not premature optimization; it is avoiding gratuitous pessimization." (Herb Sutter, Andrei Alexandrescu "C++ Coding Standards")

Certain efficient design patterns and coding idioms are just as easy to write as pessimized alternatives.

share|improve this answer
2  
make sure they are as easy to read too :) –  Jaap May 29 '11 at 12:32

The correct retort is:

What, all evil? You sincerely believe that all of the evil in the world derives from premature optimisation? Are you sure? Have you entirely lost all sense of proportion? Do you even know what evil is???

They will probably, when their view is cross-examined correctly, moderate it to "Premature optimisation can be a cause of some bad code."

share|improve this answer

Not optimizing prematurely should not be an excuse for not optimizing at all!

share|improve this answer

I like to remind people who use this statement in a dogmatic way that:

"It's easier to optimise a debugged program than to debug an optimised program"

... which is the crux of the argument: what is premature ?

share|improve this answer

"Performance is a feature!" - Jeff Atwood, StackOverflow Podcast

This is the correct retort to: "Why worry about performance, write slow code, get your product to market ... don't worry about performance. You can sort that out later".

Premature optimisation is a very different thing.

share|improve this answer

The BEST retort: "I agree"

share|improve this answer

I usually hand the person saying this my iPhone 3G, and ask them to bring up and use one of Apple's built-in apps (like mail or SMS) while I count the seconds out loud.

On a good day, my phone takes over twenty seconds to display text messages because some programmer at Apple was fond of repeating this cliche.

share|improve this answer

It might be more useful to ask a question instead, e.g. "why do you consider this optimization to be premature?" rather than getting into an exchange of quips.

share|improve this answer

"That statement applies to trade-offs between implementation complexity and performance, it's not an excuse for using the wrong tools out of ignorance" or less politely "Is that how you rationalize writing the insert insult you call code" :)

OTOH optimization without testing is an assumption (claim without proof) since it's usually impossible to account for all factors that could impact performance, and often factors accounted are also based on assumptions which may turn out to be false.

share|improve this answer

Premature optimization != early optimization.

I don't like how people try to use this quote as an excuse to not think about the problem at hand. Premature optimization means that it is occurring before the programmer knows that it actually makes a difference...this is sound advice. That doesn't mean that no optimization should occur before measuring; a good programmer can identify many performance bottlenecks without first measuring them (and profiling can help in less obvious situations).

share|improve this answer
3  
See Django Reinhardts longer quote of Knuts words: It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail. It's more or less the opposite of what you say. –  user unknown May 30 '11 at 2:27

The correct "retort" in all cases, is to complete the quote completely and educate them what he intended.

We should forget about small inefficiencies, say 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.

Donald Knuth
share|improve this answer

I can't believe nobody has suggested to complete the original quote. The full quote is

We should forget about small inefficiencies, say 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.

Donald Knuth

Sure, Knuth said it, but he said it in a manner which specifically limits what he's talking about. Someone taking this out of context in order to make a point clearly doesn't understand the original point Knuth was making.

Therefore, my response would be to ask them to read the original text again, specifically the paragraph before and after the bit they are quoting.

share|improve this answer
2  
Another retort, which is from the same article appears just before the above quote: The conventional wisdom shared by many of today's software engineers calls for ignoring efficiency in the small; but I believe this is simply an overreaction to the abuses they see being practiced by pennywise-and-pound-foolish programmers, who can't debug or maintain their "optimized" program. –  Allon Guralnek Nov 3 '11 at 18:54

I would say: "premature software design and planning is more important than programming itself"

In short, you better start to think about what you are going to code rather than typing it without planning what it is going to do; you will make tremendous optimisation with a good design than optimization.

share|improve this answer

When your code is functional, then optimization is no longer premature.

Optimization is premature when you spend time on making your code fast but your code doesn't do anything. It doesn't matter how fast your code is if it's unfinished or not useful.

But once it is useful, it makes sense to look for measurable performance gains that will improve the user experience.

share|improve this answer

The best retort was by Charles Cook in his blog entry from 4 Jun 2002 on Premature Optimization. The important line he said was:

But, conversely, when designing software at a system level, performance issues should always be considered from the beginning. A good software developer will do this automatically, having developed a feel for where performance issues will cause problems.

This blog entry by Charles Cook was selected by Randall Hyde in his book: "Write Great Code" published 2004.

share|improve this answer

I would ask them to explain the quote. And then help them understand it.


People repeat it as some mantra. It could have been written in Latin and Old Greek for all that matters, they would not think about it anyway.

Typically it gets started like this:

Alice: Is if (i == 0) faster than if (0 == i) ?

Bob: don't worry about this, as Knuth said "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. "

Alice (disappointed and subdued): Oh! Ah yeah I heard about this already. -- don't want to appear too dumb right ?

Later on:

Carol: I think we should review our algorithm here, O(N!) is pretty bad and won't allow us to scale at all.

Alice: It's okay, Knuth said it: "Premature Optimization is the root of all evil"! -- great sense of accomplishment

This quote is too widespread, I fear, and most of the times provided without any context. It's basically the equivalent to the unfamous RTFM. People get bashed on the head with this, and they don't want to appear dumb since they didn't know about this and everyone seems to, so they shut up and forget to ask why ??.

And then they reuse it themselves, propagating it, and not necessarily in appropriate situations because they have never been given the necessary information to judge whether or not it applied to a particular situation.

It's a vicious circle we are in, since when those cultists reuse it, they cannot provide the context at all, because they never knew it in the first place. But it comes from Knuth, the K in KMP!, the one behind Latex, the one behind "The Art of Computer Programming", so it cannot be wrong... right ?

share|improve this answer
6  
To be fair, give credit to Alice for at least asking a co-worker whether (i == 0) is faster than (0 == i), rather than posting a question on StackOverflow like most people do. –  Carson63000 May 28 '11 at 23:09
1  
This is my exact reaction to the quote. Sure, let's see if we can stack up some O(N) operations and make our screen refreshes O(N^40). Then hand it off to someone else to fix, because it works with our test code (N<5). I have been on the "fix" end of that equation and it sucked. –  Мסž May 29 '11 at 4:48

"Caring about your craft is not evil."

"Getting something right the first time, saves time."

"I know I can make it better."

share|improve this answer

It doesn't have an easy corollary, because it's true almost by definition.

It's not saying to write slow code, it's not saying optimization in general is bad. It's saying that optimization is not free, it comes at the cost of other (often more important) quality metrics, such as readability or flexibility, so you want to defer doing it until you know it's necessary.

pre·ma·ture
1. Happening or done too soon, especially before the natural or suitable time.
-- Cambridge Dictionary

This doesn't mean you should be completely unmindful of performance. It doesn't mean that if you know in advance a section of code is performance critical, that you shouldn't design it accordingly. But it does mean that if you're unrolling a loop in some routine that prompts for user input, you're probably doing it wrong.

share|improve this answer
2  
Too true... it seems everyone takes this as if the word premature was not in the sentence. Optimization, when it's needed and appropriate, is not premature, by very definition. –  Lawrence Dol May 28 '11 at 23:07
2  
"....that you shouldn't design it accordingly." The distinction is between design for performance and code for performance. Quite different, and one gives much greater returns the other. Code for performance is rarely cost effective and usually premature. –  mattnz May 30 '11 at 3:57

Belated pessimization is the leaf of no good.

share|improve this answer
1  
+1 That's hilarious. And very nearly makes sense! –  Rex Kerr May 28 '11 at 23:41

If by evil you mean wasted effort, isn't sloppy design even more evil?

share|improve this answer

"don't worry about performance" and "premature optimization is the root of all evil" are not saying the same thing.

One is saying, don't worry about optimizing. The other is saying, don't worry about optimizing until you have the blunt of the application written and profiled, because what you think the critical 3% will be and what the critical 3% actually is are usually two different things.

Thus, you should optimize, just don't do it prematurely.

share|improve this answer
1  
I think 3% is way more than what really counts. Other than waiting on the disk my experience is that the vast majority of time is spent in a few places--loops with very high run counts, sometimes routines called from within such loops. I've never found this to be even 1% of the code. –  Loren Pechtel May 29 '11 at 2:26
2  
s/usually/surprisingly often/ –  Pete Hodgson Sep 26 '11 at 6:50

Premature shipping is the root of all failure.

(In other words, a minor nuisance in design/coding like poor performance quickly turns into full-blown production failure once it's shipped. So don't be stupid and don't write sloppy code.)

share|improve this answer
2  
What would you call never shipping, if not failure? Perfection, including the best possible performance, is an unachievable goal. –  jmoreno May 28 '11 at 18:27
2  
@jmoreno: With the possible exception of Duke Nukem Forever, no software project "never ships" unless it's abandoned, which in the majority of cases is because the project has already failed for other reasons. Anyway, your question is entirely missing the point; you don't need to ship a perfect product, but you are responsible for shipping something that actually works, and in most cases "works" carries implications of acceptable performance levels. –  Aaronaught May 28 '11 at 19:01
1  
@jmoreno: Think twice about being first to market. Familiar term, yes; infallible one, absolutely not. In fact, I'd wager that the majority of software products you use today were developed and shipped by companies that were not, in fact, first to market. Not to say that performance was the singular reason why me-too'ers pulled ahead, but shipping first isn't always a great reason to cut corners. –  Aaronaught May 28 '11 at 22:16

Test first!

When you write essential load tests, in most cases you can judge if an optimization is premature or not.

Mind your complexity!

When you currently have an algorithm that's n^4 and you know need answers for n=1000 in 1 minute, you can start with an optimization right away.

share|improve this answer

The point of that statement is not to imply that you should write slow code or sloppy code just to get it done quickly, and someone who states it as you did "write slow code, get your product to market", is greatly misinterpreting it.

It's point is that you should not spend time micro-optimizing code that has not yet proven to be problematic.

The implication is that you aim to build a complete, well thought-out, and functioning application before squeezing out extra CPU cycles.

So I haven't answered your question. I offer no retort, other than to correct them about the purpose of avoiding premature micro-optimization.

Addendum As I was cooking breakfast, I thought of a better summation:

When developing new code, the time you might spend micro-optimizing every for-loop is much better spent thinking about higher-level organization and integration. That time spent on organization & integration at the earlier stages pays dividends when the time comes that you actually do need to optimize a component; a localized refactoring or optimization is likely then to require less rewriting and of surrounding code.

share|improve this answer
9  
This is a great answer, and it's so true. You can easily get caught up in micro problems simply because they're more in your face. It's harder to force yourself to look at the macro and make sure that the architecture is doing what it should be first. –  Django Reinhardt May 28 '11 at 23:44
27  
Don't leave us hanging. What'd you cook for breakfast? –  Jordan May 29 '11 at 2:21
2  
So, the best retort is probably "Yes". –  Marcin May 29 '11 at 12:04
2  
@Jordan Nothing special, just eggs on biscuits for my kids. Offers extra time to develop more sophisticated coding philosophies. –  Michael May 29 '11 at 12:55
16  
@Michael: you could crack the eggs on top of the biscuit dough and put the whole thing in the microwave for 2 minutes, but that might be premature optimization –  Steven A. Lowe May 29 '11 at 17:01

sure.. "a good design in the first place means you won't have to optimise later"

share|improve this answer

Best retort is obviously "it shows up on the profiles I've done".

share|improve this answer
4  
If the optimisation was premature, this seems unlikely to be true. To show an improvement by profiling, you need to have measured the before and the after. If you measured first and had determined there was a real problem, the optimisation isn't premature. –  Steve314 May 28 '11 at 19:28
2  
@Steve, Actually the optimization could still be premature, if you think about it. You could be sitting there trying to shave (measurable) seconds from an SQL Stored Proc that only gets called once a month. Those improvements would show up on profiles... just ones that aren't important to the project's success. –  Django Reinhardt May 29 '11 at 0:06
2  
@Django - The point of measurement is to identify bottlenecks, not just to say "module x takes y microseconds to run with data z". Referencing profiles in a retort that show measured but irrelevant savings would be a risky bluff too - someone may ask to see those profiles, and easily see the flaw. –  Steve314 May 29 '11 at 10:21

"yeah, but mature optimization is divine"

share|improve this answer
1  
Nice, that's what I was about to write... I think. It's hard to know now, since you already wrote it. +1 –  Yar May 28 '11 at 15:09
3  
Isn't that just backing-up the same statement? Shouldn't it be, "Yeah, AND mature optimization is divine". –  Django Reinhardt May 28 '11 at 23:43

Not the answer you're looking for? Browse other questions tagged or ask your own question.