Wednesday, 27 January, 1999
Optifuscation
"But it has to be fast."
I've heard that statement used to justify the most unspeakable programming evils: code duplicated inline, convoluted macros, micro-optimized floating-point tricks, extensive global data, improper (or absent!) error handling, risky language idioms, and just about any other coding horror you can imagine.
The end does not justify the means. Especially when, all too often, the result is a program that executes slightly faster--right up until it crashes.
"It crashed," I'll say.
"Well, yeah, it still has a few little bugs, but it's fast!"
I've got news for you, fella, my customer is not impressed with how fast your program mangled her spreadsheet.
I can just picture a television reporter interviewing the primary architect of the Boeing 787 after it crashes on its maiden flight:
Reporter: "It crashed."
Architect: "Well, yeah, the wings need a little more support, but did you see how fast the landing gear came up?"
I've been developing software for a very long time now, and I'm beginning to believe that programmers are genetically conditioned to waste their time trying to write small, fast code rather than clear, correct, and complete programs. Decades of research has shown that programs written with local efficiency as a high priority, when compared to programs written with clarity as a primary goal:
- Take longer to develop
- Are more difficult to maintain
- Cost more to support
- Are less feature-rich
- Are less likely to work correctly
- Are more likely to crash inexplicably
- Are unlikely to be significantly more efficient
In spite of this, programmers forge ahead hacking away at locally-efficient code and consistently missing their ship dates. Genetics is the only possible explanation. Otherwise I'd have to conclude that programmers, as a rule, are stupid. What other explanation can there be for programmers--even experienced programmers--spending their time optifuscating non-critical code that doesn't even work?
I suspect that the real reason is that programmers are lazy. It's much easier to micro-optimize a bunch of little loops than it is to design and implement a new feature. And it's coding; thinking at the keyboard; programming by the seat of the pants. Implementing a solid design is just drudgery--there's little room for improvisation if you know what you're going to write before you sit down to code it up. All of the effort is in the design, and that's hard work. It's much easier to just start hacking.
I understand that some applications have to be small and fast. I also have many years of empirical evidence which suggests that the fabled 80/20 rule does not apply: it's more like 95/5. That is, 95 percent of a program's time is spent in 5 percent of the code. Which means that if you're optimizing something other than that critical 5 percent, you're wasting your time and your employer's money.
Yes, small, fast code is cool. But I'm not selling cool--I'm selling programs that provide solutions to customers' problems. Faster and smaller programs are nice, true. But as a programmer, your job depends on delivering correct programs on time and on budget. If you want to optimize something, concentrate on getting a bug-free and feature-rich product out the door ahead of schedule and under budget--your bank account will be optimized very nicely indeed.
There are two ways to develop software: you can either write a working program and spend a little time making it work faster, or you can write a fast program and spend the rest of your life making it work. Your decision.