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.
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. First things first: Gotta get the features out the door.
