I recently saw a talk from Brian Lonsdorf, where he talks about the obsession with speed in the JavaScript world. I have to say, I agree with him in many points. As a matter of fact, I don’t think it’s only in the JavaScript world (although it might be more evident nowadays) but it’s more or less generalized. It’s all about speed and scale!

Many of us have participated in discussions where an idea is being pitched and, it’s not even a full idea yet, and people are already focussing on “if it scales”. Or someone ditching some nice abstraction because “this way it will be faster”. It seems to be a current trend nowadays.

Brian makes (among many others) two points that I think are very interesting:

  1. even if you’re using some kind of abstraction, that does not mean that you can’t make your code more efficient. There are many ways to optimize your code before going into the “bare metal”;
  2. there are very smart people that deal with the “bare metal” daily, and doing a good job at it.

Let me derail a little bit to give an example. In Chapter 3 of his book, Practical Ruby for System Administration , Andre Ben Hamou talks about performance. In that chapter he has a cute little story about a competition between a Ruby and C developers where they aimed at writing some code to perform a task. Bottom line was, although the Ruby code was slower (although having enough performance for that specific job) it took a lot less time to write. He argues there that in order to go to a lower level (like having to resort to C code) there needs to be a very good reason. I couldn’t agree more.

I learnt that lesson the hard way. When I was still in college we had a class on Cryptography, where we had several assignments to do. Some of them involved cracking something and we were evaluated in the following way: first one to crack got 100%; the rest of people got a mark lower and lower depending on how much time they took to crack theirs after the first one (there was some kind of formula). Suffice to say the vast majority of us instead of coding something that would crack it, and leave it running (while we might still be improving our solution) , tried to find a “good solution”. Well, almost everyone gave up on that after the first assignment and it is a good example of what Andre was talking about in his book.

My post might have derailed a little bit from Brian’s original talk, but I think the broader concept is the same: there is so much focus on speed and scale nowadays, that we sometimes forget about maintainability. The war speed vs maintainability is old and will never end. But keep in mind speed sometimes means maintainability.

Think about it: you quickly have to make a fix for a critical bug. The easier it is to fix, the fastest you will make, the happier the client will be.

I encourage you to watch to Brian’s talk and spark some discussion about it.