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:
- Done >= perfect.
- Don’t waste time building elaborate simulations for what the future might bring to your capacity.
- 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.
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.
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
Pingback: Goldilocks and premature optimization « With Feeling
Pingback: Goldilocks and premature optimization | With Feeling
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.
Pingback: ÐовоÑти » Blog Archive » [Перевод] Как Ñтать ведущим разработчиком. ЧаÑÑ‚ÑŒ 2
Pingback: Статьи на ÐнглийÑком php » Программирование в удовольÑтвие
With a lot of respect to the website owner of kitchensoap.com
Hi there, my name is Yair
I have just lost my job because of the corona, so I am contacting now as many website owners as I can to find someone to hire me.
I worked on one of biggest ISP providers in my country for years as a group manager.
You can hire me online for anything you want me to do and I will do my best, and study the subject.
You can pay me how you decide
Please send me a job applications and your requirments of me and how and when you are going to pay.
My email is: yairmartay@gmail.com
Looking forward to work for you.
Respectfully,
Yair
Pingback: How To Become A Lead Developer. Part 2 | SUMclicks