Performance is premature optimization

by Guido García on 18/01/2014

I will burn in hell, but performance is premature optimization nowadays. Despite it is very interesting from an engineering perspective, from the practical point of view of someone who wants to follow the make-shit-happen startup mantra, my advice is not to worry much about it when it comes to choosing a programming language.

There are things that matter more than the technology stack you choose. In this post I will try to explain why; then you can vent your rage in the comments section.

Get Shit Done

Your project is not Twitter

It is not Facebook either, and it probably won’t. I am sorry.

Chances of your next project being popular are slim. Even if you are so lucky, you app will not be popular from day one. Even if you are popular enough, hardware is so cheap at that point that it could be considered free for all practical purposes (around one dollar per day for a 1CPU/1GB machine; go compare that with our wages).

Your project will fail

Face it. You are not alone, most projects fail and there is nothing wrong with it. They fail before performance becomes an issue. I do not know a single project that has failed solely due to a bad choice of a programming language.

So I think that, as a rule of thumb, it is a good idea to choose the technology that allows you to try and develop small components faster (nodejs, is that you?). You will have time to throw some of those components away and rebuild their ultra-efficient alternatives from scratch in the unlikely case of needing it.


You are not going to need performance; stop worrying and get shit done instead. I always have a Moët Et Chandon Dom Pérignon 1955 on the fridge to celebrate the day I face performance issues due to choosing X over Y.

Hold on

There are 3 comments in this article:

  1. 27/01/2014DrSlump says:

    While raw computing power and storage keeps getting cheaper and cheaper, performance is always something to have in mind when developing. It has a huge impact on the global user experience, it’s not the same to serve a request into the tenths of than on the hundredths of milliseconds.

    There is also the issue on the development model being followed for the product. If as a developer I have a say on the product, with continues delivery practices in place and the possibility to schedule hardening/refactoring efforts on the project when needed… then I’m all for forgetting about most performance concerns until they actually arise. If I’m being employed in a more traditional “consultancy” style, with a fixed deliveries roadmap and so on, I feel that the developer team should take performance into account from day one, at least to support the level of performance expected and payed for by the customer.

  2. 28/01/2014Guido García says:

    Thanks for your comment. That is a good point. I was thinking about in-house development of new services. I agree with you, for a turnkey project with a strict deadline, quality should not be negotiable because iteration is not always possible.

  3. 7/02/2014Big teams are not agile in the digital world - My name is Guido says:

    […] See also “Performance is premature optimization” […]

Write a comment: