Code Simplicity: The Fundamentals of Software

Max Kanat-Alexander (2012)
Review date: March, 2013

This short, less than a hundred pages long book has nine chapters. It basically starts with a problem statement: the design of programs is poor because there's no science around to guide it. This is the main topic of chapter two, "The Missing Science". The next chapter, on design, is about a rather sympathetic angle on software: the purpose of software is to help people, and all that follows.

Chapter four gradually builds up "The Equation of Software Design", which states when read out loud: The desirability of a change is directly proportional to the value now plus the future value, and inversely proportional to the effort of implementation plus the effort of maintenance. The next chapter, "Change", introduces the Law of Change (The longer your program exists, the more probable it is that any piece of it will change) along with some statistics to support it, and three ways of failing to deal with it:

Chapter six, on defects and design, is basically about not fixing things if they aren't broken and the DRY principle. Next is a chapter on what simplicity is about; for example consistency and readability.

The simplicity chapter is mirrored by a chapter on complexity, which lists driving forces behind programs becoming complex.

The last chapter is on testing. It's a very short chapter that basically says that your software works to the degree it has been tested and if you haven't tested it, you cannot say that it works.


What's really interesting about the book is that it actually attempts to build the science of software design, which means that that key concepts of a chapter are expressed as facts, definitions, rules, or laws. They all come together into one system in Appendix B. Neither of these are really proven or based on anything more than a rather short explanation in the surrounding text. On the other hand, pretty much all of these facts, rules, and definitions make sense. For example:

Fact: simplicity is relative

Rule: If you want to succeed, it is best to be stupid, dumb simple.

Rule: You can determine whether or not a technology is "bad" by looking at its survival potential, interoperability, and attention to quality.

Law: The Law of Testing: The degree to which you know how your software behaves is the degree to which you have accurately tested it.

These are all direct quotes from the book's second appendix. 

The reader quickly understands that the author is probably not serious in wanting to create a science based on a series of assertions and statements. The average reader would rather take that with a pinch of salt. On the other hand, it becomes quite apparent that the author has put a lot of mental effort into putting together all these definitions, rules, facts, and laws. Their strength, depth, and quality vary, as should be apparent from the list above, but again, intuitively they make sense. 

The way I read this book was from an angle where I could admire this rather different approach to writing a book on software. I really enjoyed this different take combined with an assertive manner.

This book hasn't given me any new insights, but it has given me a new perspective on some things. Above all, it's a true quote machine. The next time I need a quote to support a statement about software development in a conference slide or training material, I'll definitely turn to this book.

So did the reviewer like the book or not? Actually I did. It's so different from all other books I've read so far, and it's less than 100 pages, so reading it isn't really an effort. An experienced developer may not learn too much from it (I didn't), but he/she will surely get new angles on things. I'd say: don't put this one on the very top of your reading list, but read it someday.

Who should read this book

This book offers some new angles on some things we tend to assume in software development. It attempts to create the science of software design, which should appeal to novice developers looking for concrete advice or seasoned developers looking for alternative takes.


  • 2015-09-29

    It's been almost one and a half year since I reviwed a book! I've been too absorbed by Writing my own. Anyway, I'm back with Jeff Patton's relatively...
  • 2014-01-04

    New category! Performance! Reviewed The Every Computer Performance Book. Check it out!
  • 2013-09-10

    Reviewed a book that' slightly less technical, but much more fun to read. It's I.T. Confidential.
  • 2013-08-13

    Reviewed yet another book on Visual Studio 2012 and TFS. I also created a "Microsoft" category and moved the other TFS book there from the "Tools"...
  • 2013-08-05

    Updated the FAQ. Included information about getting a book reviewed.