Everything isn’t about the Knuth quote

It’s hard to describe how tiring it is to hear someone quote Donald Knuth (or Tony Hoare) in the wrong context. I’m not the only one annoyed by this. In “Structured Programming with go to Statements”, Knuth says:

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

After having read Knuth’s paper containing this quote, I can agree that it’s certainly a brilliant piece of advice in the context of programming. What is irritating to me is the blanket application of this pearl of wisdom to anything that has to do with computers, especially systems performance, web operations and architecture decisions.

For the record: I firmly believe in these principles:

  1. Done >= perfect.
  2. Don’t waste time building elaborate simulations for what the future might bring to your capacity.
  3. Performance tuning is better left outside the capacity planning process.

But I think sometimes folks lean on the Knuth/Hoare way too much, in the wrong situation. This was meant to be a blog post of my own, but I think this article pretty much sums up my current feelings about it.

7 Comments Everything isn’t about the Knuth quote

  1. Mikhail P

    Yeah, the wrong interpretation of that quotation gets used a lot, particularly in the Web 2.0 world, where everyone just wants to grab a big ass framework that does everything for you, but then end up with an app that has a mess of bottlenecks deep in some abstraction layers because little thought was ever given to how well the tools fit the job.

  2. Ask Bjørn Hansen

    Yeah, indeed.

    It’s so often misapplied as an excuse for making a mess of the code. “We’ll get back and optimize it later”, when it’s not optimization but sanity that’s lacking.

    A sane interpretation is “don’t prematurely make the code worse for the sake of optimizing performance”, not “premature thinking is a waste of time”.

    – ask

  3. Pingback: Goldilocks and premature optimization « With Feeling

  4. Pingback: Goldilocks and premature optimization | With Feeling

  5. Jonathan Hartley

    I think that perhaps what is most lacking from inexperienced implementations is a proper separation of concerns. If the code is structured with ‘single responsibility principle’ firmly in mind then I think a lot of the original post’s concerns disappear. That 20% of problematic code isn’t ‘scattered throughout’, but is instead nicely compartmentalised. In such a situation, deferal of all optimisation until after the performance characteristics of the entire running system could be measured seems entirely justifiable and dersireable. The problematic parts can be easily isolated and replaced using localised code changes. The original design suffers only the minimal distortion. The article hasn’t made it clear to me why speculative optimisation as you go is better than this.

  6. Pingback: Новости » Blog Archive » [Перевод] Как стать ведущим разработчиком. Часть 2

  7. Pingback: Статьи на Английском php » Программирование в удовольствие

Leave a Reply

Your email address will not be published. Required fields are marked *