This is a review of the original version of "Code Simplicity". A revised edition was published in June 2012.

At 92 pages (or 2242 Kindle locations) Code Simplicity (O'Reilly, 2012) by Google engineer and blogger Max Kanat-Alexander must be one of the shortest titles in the O'Reilly catalogue. I confess that after a first reading my main thought was that it could have been even shorter.

One excellent chapter on the application of simplicity to software development stood out from the rest which seemed to consist mostly of sweeping generalisations, dubious examples and grandiose calls for the establishment of a "science of software design" (as if no previous attempts to address the topic had been made).

A virtue of the book's brevity, however, is that it is easily re-read and on doing so I realised that my expectations were wrong and I was missing the author's primary intent—which is indeed to make generalisations that should hold true regardless of specific languages or contexts.

Hence you'll find no code in Code Simplicity. Instead Kanat-Alexander conducts you through a deliberately abstract consideration of the nature of software and how you should think about it as a coder.

Here to help

As developers our minds focus mostly on the nitty-gritty specifics of programming, on techniques and technologies for solving technical problems. But it is useful to be reminded of the ultimate purpose of almost all the software we write: to help people, and keep helping them day after day. Kanat-Alexander goes as far as to assert that:

People who cannot conceive of helping another person will write bad software.

Which leads to the question: how do you maximise the long-term helpfulness of your software whilst minimising the effort required to do so? Answer: by seeking ways of simplifying your code at every opportunity.

Laying down the law

He may offer no code, but Kanat-Alexander does present a decent range of approaches to consider adopting. These he categorises into a small number of universally applicable "laws" and a larger number of general "rules", all supported by various useful "facts" and "definitions".

As the author acknowledges, many of these—such as D.R.Y.—are well known, but setting them out together as a coherent set of abstract tools for improving the quality, maintainability and ongoing "helpfulness" of your code is in itself very helpful. I was grateful in particular for the following reminders:

• Not only should you break up your code into re-usable modules that are as simple, focussed and understandable as possible, you also need to make sure they stay that way.
• The optimum length of a variable or function name will depend on the frequency with which it is used. It needs to be long enough to convey its purpose, but frequently used long names can make the code as a whole less readable.
• Comments should normally only explain why you have done something, not what you have done (which should be clear from your naming and formatting).
• Simplicity is relative: what may seem simple to you now, may no longer seem so in 6 months, still less to another developer taking over your code. The safest approach is to make as few assumptions as possible and aim for the level of "stupid, dumb simple", as Kanat-Alexander bluntly puts it.
• Keeping to that level is hard because we fear appearing to be condescending to our peers, or worse, we sub-consciously or otherwise want them to admire our cleverness.
• Y.A.G.N.I. isn't always true: sometimes you will end up needing a feature that won't be used initially, but normally you can't predict exactly how it will need to be implemented since the environment is likely to change. Coding it now is therefore a waste of time. Wait until it's actually needed so that you have all the contextual information required.

Simplicity as a mindset

If you are about to read Code Simplicity and are expecting to be shown how to produce code that's simple, prepare to be disappointed.

If, however, you are looking to embrace and cultivate simplicity as an attitude of mind to bring to your software coding practice, read this book.

At least twice.