Global Moxie

Tune-ups are important, but when? Photo by Boskizzi.

This week has already seen a flurry of updates for the Big Medium 2 beta. In addition to the library editor, a major new feature, I also made some deep changes to the JavaScript plumbing that drives Big Medium’s interface. It feels much faster.

Friends, this is what we call optimization. For code monkeys, optimization is tantalizing and sorely tempting and, at many stages of a project, should be avoided like a kid with pink eye.

“Avoid premature optimization” is one of the axioms of software development. It’s basically fancy talk for “if it ain’t broke, don’t fix it” — or maybe, “if it ain’t really broke, don’t fix it.”

For programmers, “optimization” refers to making things go faster or using fewer resources. Efficiency. At first blush, it seems hard to argue with fast and efficient software, right? Trouble is, making a piece of code run faster often makes the code denser, more complex, harder to understand. And that in turn makes it tougher to debug and maintain. Wikipedia describes the phenomenon this way:

“Premature optimization” is a phrase used to describe a situation where a programmer lets performance considerations affect the design of a piece of code. This can result in a design that is not as clean as it could have been or code that is incorrect, because the code is complicated by the optimization and the programmer is distracted by optimizing.

Sidestepping premature optimization turns out to be good general wisdom for life: Don’t get obsessed with a potential problem until it actually becomes a problem. The implicit suggestion here is that life’s curveballs often come from places where you least expect them, so it’s a waste of time and energy to focus too much on hypotheticals.

In programming as in life, this doesn’t mean that you go blithely traipsing along like Little Red Riding Coder, without regard to lurking wolves. You lay out your path as wisely as you can, but then try not to get too freaked out by the little gremlins that turn up along the way.

Eventually, though, you have to deal with the gremlins. Code has to be optimized at some point. It’s a question of when and to what degree: If you spend too much effort designing your code for efficiency up front, you tend to make the code less flexible for changes down the road. It makes the code harder to unravel if you need to take it in new directions.

Photo by Boskizzi.

For the most part, that means that optimization and performance tuning tends to happen toward the end of software projects. You design it, you build it and only then do you figure out how to make it faster (or lighter or smaller).

This is why mature code bases tend to run faster than new ones, even with more features and code. After all, it’s only when a program is built that you can reliably find its bottlenecks (usually in different places than you might have first thought). This is even true of the big boys: When Apple first released Mac OSX, it was dog slow; it was only several years later that it became truly speedy.

Speed takes a back seat to finishing the features. No point in making the car fast ’til you give it all its wheels.

Even though it’s still in beta, Big Medium 2 is at least road-ready, holding its own at several production sites already. There’s still more work to be done under the hood before it’s ready for the chrome and detailing, but... ah, to hell with the car metaphor. Here’s what I’m trying to say:

Big Medium 2 is getting ever closer to being feature-complete, which means that I’ve been able to pay a bit more attention to optimization issues. The recent JavaScript improvements were a satisfying first step, and I’m looking forward to tuning more features over the next few weeks.

First things first, though: Gotta get the features out the door. There’s still more to do.

Tags: productivity, programming