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. After working with such tools for seven years, I’ve become convinced that all compilers written from now on should be designed to provide all programmers with feedback indicating what parts of their programs are costing the most; indeed, this feedback should be supplied automatically unless it has been specifically turned off.

Donald Knuth

More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason – including blind stupidity.

William A. Wulf

Interestingly, despite the fact that neither of these quotes says anything specifically about goto, and that the sentiments can be applied to programming as a whole, they both come from papers talking about the use of gotos. Knuth’s quote is from Structured Programming with go to Statements, (Computing Surveys, Vol 6, No 4, December 1974, p268). Wulf’s quote is from A Case Against the GOTO (Proceedings of the ACM National Conference, ACM, Boston, August 1972, p796)

Knuth’s quote is usually abbreviated to “premature optimization is the root of all evil”, sometimes “97% of the time” is mentioned. I wanted to put the quote in context – the surrounding text adds a layer of nuance that isn’t present in the sound bite.

There is some interesting background information on the origin of Knuth’s quote at Shreevatsa R’s blog here.

Correctness is clearly the prime quality. If a system does not do what it is supposed to do, then everything else about it matters little.

Bertrand Meyer

The road to wisdom?
Well its plain and simple to express:
Err and err and err again,
but less and less and less.

Piet Hein

Piet Hein predicted the iterative model of development found in agile programming techniques, as well as inventing the board game hex.

Good programmers use their brains, but good guidelines save us having to think out every case.

Francis Glassborow

I have spent way too many hours in arguments over coding guidelines – where do we put the braces, are we using underscores or camel case? I have come to the conclusion that within reasonable boundaries I don’t care, but I really like the guidelines to be consistently applied. I don’t want to spend any time thinking about how we differentiate member variables, or what the convention for naming include guards is. There are much more interesting problems in the world.

A superior pilot uses his superior judgment to avoid situations which require the use of his superior skill.

Frank Borman – Apollo 8

I once had a programmer tell me that he had to use a goto because he needed to jump out of 10 levels of nesting (in C++ code). In the most literal sense he was correct – a return or an exception would not have worked in this situation. Of course he should never have got into 10 levels of nesting in the first place.

Sometimes the best solution to a problem is to back out and change the system so that the problem just doesn’t exist.

(For the avoidance of doubt, I am not claiming that using a goto qualifies as “superior skill”, but it is an extreme way of getting out of a problem. Also, I am not (entirely) anti-goto. If I ever come across a situation where a goto is the best way to achieve something in C++ I will use it. I have just never encountered such a situation since I switched from C to C++ 19 years ago.)

Should array indices start at 0 or 1? My compromise of 0.5 was rejected without, I thought, proper consideration.

Stan Kelly-Bootle

There is a fascinating piece by Edsger W. Dijkstra “Why numbering should start at zero” that discuss the various options available for describing ranges and explains why we should prefer one option over the others. Dijkstra is one of a number of programmers who have the ability to look at choices that seem obvious or arbitrary and come up with reasons for preferring one of the choices.

There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.

C.A.R. Hoare

The problem with simplicity is that it can be awfully complicated to get there. I have often found that when thinking about a problem I start with a solution that is simple, but naïve (and wrong). As I continue working through the problem I get cleverer and cleverer but more and more complicated. If I stick with it for long enough I continue to get cleverer and cleverer but get less and less complicated until (if the programming gods allow) I end up with a clever, but simple, solution that is also correct. I need to remember to have the confidence and patience to get over the hill to the simple solution.