Truths about code optimization

In his blog, Russ Olsen shares some words of wisdom about optimizing Java code (or any code for that matter). It's mostly common sense such as starting with working code, profiling first, and re-profiling after each change. I agreed with all of it until I got down to the last section where he wrote:

Much of the time optimization is the process of taking nice code and making it longer, more complex, harder to read. In short, less nice. Really we should stop using the term optimization. We should call it what it really is: screwing up the code so that the it performs better or maybe justifiable mutilation.

If that's what you find yourself doing when optimizing a program, it's time to step back and rethink your strategy. I've found that most performance problems are really caused by bad algorithms, and not "short, simple, easy to read code" as Russ seems to suggest here. Good algorithms are elegant and thoughtful, not hacked up mutilated kludges.

In my opinion, developer performance is much more important than run-time performance. Why? Because a productive developer will have time to architect things the right way, to do the profiling, and to refine and refactor the algorithms. An unproductive developer dealing with screwed up and mutilated code will only have time to fight fires, hosing down one section after another until the whole soggy mess collapses.