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.

24  
Isn't the original: "the LOVE of money is the root of all evil?" –  barrycarter May 28 '11 at 15:41
74  
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

"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

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

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

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

The BEST retort: "I agree"

share|improve this answer

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

share|improve this answer

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