(Another post in my “What is ‘Good Code’?” series…)

Yes, optimized.

But for what?

A lot of programmers seem to think that raw speed of execution is the only possible answer. If pushed, they may admit it’s also possible to optimize for minimal memory usage or minimal size of executable. Compilers have switches for that.

Get out of the box. Photo credit: lel4nd (Flickr).

Emerson said, “A foolish consistency is the hobgoblin of little minds.” In modern terms, he was deploring the lazy instinct to accept established wisdom instead of thinking outside the box. And I think optimization is one of those topics where we need a larger vision.

What about optimizing for:

• Speed of coding (sometimes programmer time is the most constrained resource…)?
• Ease of use (often, low learning curve and productive users outweighs all other factors…)?
• Speed of testing (sometimes provably correct is the most important success criterion…)?
• Full utilization (the major promise of physical-to-virtual-to-cloud migration)?
• Ease of understanding and maintenance?
• Integration with external systems?

Selecting the criteria against which you optimize is more than a technical question. It’s a strategic one, driven by business and organizational goals. Programmers who relentlessly pursue speed of execution to the exclusion of other considerations are not doing their teams or their companies a favor.

Action Item

Optimize one function for ease of understanding and maintenance. Make a short list of how your choices were different than they might have been if you optimized for speed of execution.