What is the best retort to “premature optimization is the root of all evil” [closed]

Question

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?

Answer 1

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

Answer 2

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 ?

Answer 3

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

Answer 4

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

Answer 5

I posted a brief blog post titled "Some people are very, very, very selective when they quote Knuth"

Quoting the post:

People who selectively quote Knuth as saying, “premature optimization is the root of all evil,” when they speak of how cheap hardware is and how wasteful a particular performance improvement is might have missed a tome, or 2, or 3, or 4 of his covering algorithms :)

Answer 6

The BEST retort: "I agree"

Answer 7

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