I’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.