10 July 2014

A common warning given by experienced software developers to peers and to novices is to avoid “premature optimization.”  The idea is that optimizing code before knowing where optimization is needed is usually wasteful and often counter-productive.  This way of thinking is typically attributed to a quote from an essay by Donald Knuth entitled “Structured Programming with go to Statements”.

There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified.

Michael A Jackson is widely attributed with the (clever) “Rules of Program Optimization”:

The First Rule of Program Optimization: Don't do it.
The Second Rule of Program Optimization (for experts only!): Don't do it yet.

It is true that premature optimization can and should be considered harmful.  Especially in network and/or I/O bound applications, most code optimization endeavors require significant effort, typically reduce the maintainability and readability of the code, and yield minimal benefit.  The gains from tightening a loop or asymptotic analysis of an algorithm are often miniscule compared to the I/O time involved in the operation of the software or the asymptotes considered are not of concern because the practical data sets under computation are not large enough for big-O complexity of the algorithm to be relevant.  This makes the above rules sound advice.  This does not, though, mean that performance should not be considered when designing and implementing systems.  Knuth makes this clear in the second paragraph in his quote.  Appeals to the principle of not prematurely optimizing are often an excuse for poorly written code, bad design decisions, and performance problems.  Most of the time, admonitions against premature optimization are motivated by experiences with unreadable and unmaintainable code that got into this condition in the name of performance enhancements.  This certainly exists and there are good reasons for these warnings.  It’s not always the case, though, and the pendulum may have swung too far in the opposite direction.  There are times when a decision in architecture or implementation can be made that doesn’t sacrifice maintainability or readability.  Sometimes another approach is simply better.  Sometimes optimization of code is worth it.  This thoughtful post about the other side of the premature optimization topic is worth a read.  In short, premature optimization is, indeed, inadvisable and irresponsible.  The question, then, becomes one of when optimization is premature and when it is appropriate.  This is a complex question for another post.  The point here is that optimization is not always evil.  In fact, it is essential in many times and places.

Optimization is not only often good for your application code (and sometimes even your test code), but it is also absolutely critical for yourself.  If you are interested in getting the most out of the time you put into your work, you should be taking measures to optimize yourself.  You can try to do things to optimize yourself that are counterproductive, so it’s important to measure the impact of the changes you make and assess whether they really help.  It’s also important to acknowledge that optimization of a developer is not necessarily the same thing as optimization of a team, and sometimes the former can undermine the latter.  There will be more on that in another post.  In most cases, though, it is in your best interests and in the best interests of those around you to be the best you can be.  Almost all software guys and ladies believe themselves to be exceptional.  I believe there are five core principles that make someone exceptional, not only in development, but in any activity.  I intend to dive more deeply into each of this in later posts, but to start, please consider this summary.


Colonnade among the ruins of the Asklepion in Kos island, Greece

To be the ultimate programmer you know you believe you are, here are my 5 main principles (pillars) of optimization of a software developer:

  • Upgrade Your Hardware
  • Upgrade Your Software
  • Upgrade Your Focus
  • Upgrade How You Work
  • Tap Your States of Utmost Productivity

Upgrade Your Hardware

Software is software because it is ultimately a construction of something useful in a virtual medium, limited in theory only by thought and by imagination.  The actual execution of software, though, in the real world is also limited by hardware capabilities.  We all know software can only run the way it is supposed to run if it is on adequate hardware and that sometimes the most cost-efficient way to scale a solution is to provide better/beefier/more servers.  As a software development professional, you are a thought worker.  Your labor is in your mind.  Your mind is the software you use to turn caffeine into code and your brain is the hardware on which it runs.  Your brain is the primary hardware in your system and the rest of your body is the hardware there to support the brain.  The easiest way to get more from what you have is to make your brain work better.  The best way to do that is to give it the right building blocks and fuel to operate effectively and to make sure the body supporting it is in sound and optimal condition.  When you give your brain and the supporting cast in the rest of your body what they need to thrive, you think more clearly and you feel better.  When you feel better, you can focus better.  When you focus better, you get more done.  When you think more clearly, you can get more done.  When you get more done, you feel more confident.  When you feel more confident, you generally feel better, and the cycle feeds itself.  Feel better and get more done now.  This is accomplished by addressing the following items:

Upgrade Your Software

In addition to making sure you mind is running on a brain capable of executing its instructions successfully and efficiently, it is of the utmost importance that you train your mind to work efficiently and with the capability of tackling the challenges you throw at it.  This is accomplished by addressing the following items:

  • Training for your mind
  • Training for your skills
  • Time away from work

Upgrade Your Focus

The biggest reason most of us don’t get as much done as we’d like is that we have too many distractions.  This is probably pretty obvious.  Here are some quick ways you can get more from your time by getting rid of distractions:

Upgrade How You Work

In order to work more effectively, you need to work more effectively.  Tooling is what separates humans from the other animals and using the right tools and using them correctly is what separates the optimized humans from the ordinary.  To work better, you need to:

  • Know how to use your tools
  • Use the right (and not the wrong) productivity tools
  • Get adequate time away from work
  • Upgrade where you work
  • Upgrade the hardware you use

Tap Your States of Utmost Productivity

“Flow” is that state, also called being in the “zone”, where your focus is so singular and sharp that your entire being goes into producing amazing output to where the result astounds even the producer.  Most of us have experienced this state, but few are able to find it predictably.  The best resource I have encountered regarding the predictable reproduction of flow states is Steven Kotler and his Flow Genome Project.  His book, The Rise of Superman: Decoding the Science of Ultimate Human Performance is worth a read.  To get more flow in your life:

  • Understand flow triggers
  • Understand the flow cycle
  • Structure your work around flow
  • Structure your existence around flow

blog comments powered by Disqus