An Optimization That’s Never Premature

rootsI’m pretty sure every software developer worth his or her salt, has heard of Fred Brook’s C.A.R Hoare’s statement, “premature optimization is the root of all evil,” famously repeated by Donald Kunth. One of the things you quickly learn when doing software optimization is that everything is a trade-off, you can increase performance by increasing complexity, decreasing reliability, limiting the degree of precision required, etc.

But I think there is one optimization that is never premature — readability.

I’m not the only one who sees readability as a key metric in writing maintainable software. Dave Thomas (author of The Pragmatic Programmer, and Ruby advocate) recently wrote the following:

But there was a problem [with my use of Perl]. Perl is a great language…. But even on my most charitable days I could never really claim that these Perl programs were exemplars of readability. And, in turn, this lack of readability made it hard for me to pick one of them up six months after I’d written it and make some change—even small alterations could involve long periods of head-scratching as I tried to work out exactly what the entries in my hash of arrays of hash references actually contained.

Amen, Dave! If you can’t read you code: you can’t adapt it to changing requirements, you can’t build new features into it, you can’t optimize it’s performance. In other words, you can’t maintain it.
And the documented truth of software development is that most of the time and money spent on any sucessful software product is going to be spent in maintenance and upgrades — not initial development.

Writing code that is difficult to read is like running up your credit card buying expensive toys; even though you don’t pay today, the bill is going to come due eventually — and the longer you wait the more it’ll cost.

6 Responses to “An Optimization That’s Never Premature”


  1. That quote about optimization is most often attributed to Donald Knuth, although Knuth was quoting C. A. R. Hoare.

  2. Thanks Marius,

    I guess this means I shouldn’t post late at night. I was thinking Donald Kunth, and Fred Brooks came out through my fingers. But, I didn not know that the woute origonated with Tony Hoare, so I guess I still would have been wrong ;)

    Anyway, I’ve updated the article.

  3. 3Bob

    Well, not every optimization is a trade-off. Sometimes by doing something the “dumb” way you gain a bit of clarity and see a better way of doing it. And the better way is a gain across the board — speed, memory usage, code size, readability/maintainability, etc.

    Gaining that clarity are among the most fun moments in programming!

  4. Bob,

    That’s true, but I guess I’ve defined optimization as a trade-off, so I don’t think of those changes which are improvements in all areas as “optimizations.” Instead, I think of those things as better design.

    It’s only when I am stuck in a corner, and need something I can’t get without considering the trade-off’s that I start wearing my optimization hat.

  5. Amen, and I definitely identify with Dave Thomas’s Perl quote. I have a lot of difficulty understanding my own Perl programs after the fact.

  6. Here’s another optimization that can also turn into automatic programming style:
    Computing loop invariants outside of the loop.

    Back in the mists of time, I might have routinely had to do this as part of an optimization step. Now, its only the odd, less obvious case that might be found in an optimization sweep.

Comments are currently closed.