Premature Optimization Considered Healthy

Some computer scientist by the name of Donald Knuth once said,

Premature optimization is the root of all evil (or at least most of it) in programming.

Bah! What did he know?

Of course we all know what he meant, but when you take his statement at face value, the claim is a bit vague.  What exactly is it that is being optimized?

Well speed of course! At least that is the optimization that Knuth refers to and it is what developers typically mean when they use the term optimize.  But there are many factors in software that can be optimized, not all of which are evil to optimize prematurely.

The key positive optimization that comes to mind is optimizing developer productivity.  I hardly see anything evil about optimizing productivity early in a project.  It is most certainly a healthy thing to do, hence the misleading title of this post.

However as with all things, optimizations bring with them tradeoffs.  Optimizing for developer productivity often comes at the price of optimizing code execution speed.  Likewise optimizing for speed will come at the cost of developer productivity.

Security is another example of an optimization that bears with it various trade-offs.

The point of all this is to keep in mind that at all times within a software project, whether explicitely or implicitely, you are optimizing for something.  It is important to be intentional about what exactly you wish to optimize.

If you start optimizing for performance early, keep in mind Knuth’s forewarning.  If you are optimizing for productivity early, then you are on the right track.  This does not mean that you should never consider performance. On the contrary, a good developer should definitely design for performance and measure measure measure.

The danger to avoid is diverting too much optimization attention to areas that provide too little gain, as discussed in my last post on Ruby Performance.