It’s about time that a book is written about the 4 rules of simple design. These rules are possibly the most powerful yet least understood software design practices out there.

TL;DR

If you care about your software being easy to adapt to changing requirements and a continuously evolving environment, you should probably know about the 4 rules of simple design. Understanding the 4 Rules of Simple Design helps you grow a decent understanding of these rules. Or at least enough so that you can practice them yourself (at the next Coderetreat, maybe). So, go buy this wonderful book.

Slightly Longer Review

The 4 rules of simple design were originally codified by Kent Beck in the late 90’s. Kent Beck also writes about these rules in his book Extreme Programming Explained. The rules that will lead you to a simple design are

1. Tests pass
2. Express intent
3. DRY
4. Small

By themselves they are simple rules. Maybe this is why I find people underestimate them. But following these 4 simple rules does lead to better designs. That’s what makes them so interesting. The rules of simple design aren’t usually taught at trainings. The only training format, that I know of, that practices these rules is Coderetreat.

The author of Understanding the 4 Rules of Simple Design, Corey Haines, is to Coderetreat what Kent Beck is to Extreme Programming. Corey is like the father of Coderetreat. The past 5 years he has traveled the world to give trainings using the Coderetreat format. If someone can write a book about the rules of simple design, no doubt it’s him.

In the introductory part of the book Corey introduces himself, the Coderetreat format, and explains what Coderetreat is about and why it matters. He then discusses the 4 rules and explains what they mean.

These introductions lead to the examples chapter. This is the larger part of the book. The examples are based on the patterns that Corey noticed while facilitating Coderetreat sessions. They include how test names should influence the object’s API, what DRY actually means, how to replace procedural polymorphism, and much more. For each example Corey presents the case and then leads you through the thought process of improving the design.

Of course there are many other design principles that should not be forgotten. Some of these, the SOLID principles and Law of Demeter, are explained in this book as well. Corey mentions how focussing on the 4 rules of simple design naturally leads to satisfying most of the SOLID principles as well. I share this experience.

In only a hundred pages Corey has managed to describe the 4 rules of simple design with some great examples that no doubt show you the true power of these 4 simple rules.

However, simple design is hard and after reading this book everything won’t just fit like magic. Corey has done an excellent job writing this book. Software design is hard and in my experience the way to get better at is through practice. Reading this book is an excellent start,

The style of writing makes this book easy to read, from cover to cover. If you like a preview of some of Corey’s writing you should definitely read his blog post Some thoughts on pair-programming styles.

Completed with a further reading list, this book is most definitely worth it’s money. As it’s published through Leanpub you can set a price yourself. Although you really shouldn’t want to pay less than $20.

I would definitely recommend this book to programmers with all sorts of experience; from beginner to expert, from apprentice to master craftsman.

For a little critical note, I found it a bit disturbing that the first release didn’t include a picture of Zak the cat. It’s awesome that he had fixed that, so this wonderful book now comes with Corey’s trademark! ;-)

Disclaimer: what I’ve written here is my own personal opinion. I do not have any stakes in selling this book. I don’t benefit financially from Corey selling more copies, nor books sold to visitors of this blog.