Understanding the Four Rules of Simple Design

by Corey Haines

Modern software development is a game of ever-increasing frequency of change. This is why it is imperative to build systems that are flexible and can adapt to changing requirements, both expected and (more often) unexpected. That is why I've written this book.

From 2009 to 2014, I traveled the world working with software developers, both individually and in teams, to improve their craft. Primarily, I did this through a training workshop format called coderetreat. Over those years, I had the opportunity to watch 1000's of pairs of programmers work on exactly the same system, Conway's Game of Life. As time progressed, I began to see patterns arise. I noticed common techniques and designs that spanned languages and companies and crossed national borders.

As co-founder and a facilitator of coderetreat workshops, I had the unique opportunity to provide feedback, both direct and through questions, on improving the act of writing adaptable, simple code. Through the day, we worked on improving our ability to make good choices around the minute-by-minute decisions made while writing code.

This book is about those things I learned from watching these 1000's of pairs working on the same problem. It contains a large part of the feedback that I provide during a typical coderetreat. The primary focus is on the thought process behind refactoring, and how that is influenced by the 4 rules of simple design.

This book is not about Conway's Game of Life. Instead, it uses its domain as a backdrop to discuss the thoughts and ideas behind the 4 rules of simple design. It focuses on the small decisions made while designing your code with the goal of building robust, adaptable codebases that can stand the test of time.

Genres: Programming, Software, Technology, Coding, Computer Science, Design, Technical

83 pages, ebook

First published March 31, 2014

About the author

Corey has been developing software professionally since 1995. Also spent the past 10 years, and the past 5 in particular, mentoring and training software developers around the world.

Reviews

[Ed Limonov · Rating 4 out of 5]

The book is definitely worth reading, even though not exactly my style. I recommended it to a friend of mine and got back only positive feedback.

[Domas Markevicius · Rating 2 out of 5]

It's a short and borderline obvious book, which focuses on micro-decisions. I'm not impressed: introductions, forewords and telling us how great this book will be takes about a third of it. Then we see three lines worth of code refactored ad nauseam (well, maybe not really, as book is short). Of course author's intention is to give us greater insight by using simple examples, but enlightenment evaded me.

[Aleš Roubíček · Rating 4 out of 5]

Corry je jedním ze zakladatelů akce jménem Code Retreat. Jako dlouholetý facilitátor má možnost sledovat, jak různí vývojáři přistupují k tvorbě kódu a řešení problémů. Je to úžasný způsob, jak se učit a ověřovat své znalosti.

Kniha se zaměřuje na celkem úzce vymezené téma - 4 pravidla jednoduchého návrhu. Prochází pravidlo za pravidlem, ukazuje na různá řešení, která tyto pravidla porušují nebo naopak dodržují a jaké to má implikace na udržitelnost a případnou rozšiřitelnost návrhu.

Corry se také snaží vyvrátit některý zažité desinterpretace některých známých pravidel, jako je třeba DRY nebo co to je duplicita.

Mně osobně pomohla ujasnit si některé věci a doufám, že i posunout mě dál v roli facilitátora Code Retreatu.

[Fotis Koutoulakis · Rating 4 out of 5]

Solid and small book (reads more like a collection of blog posts) with code reviews of pieces of code discussing tradeoffs/improvements.

[Neil · Rating 4 out of 5]

Kent Beck has four rules for rule design (1. passes tests, 2. reveals intention, 3. no duplication, 4. fewest elements). Corey Haines started code retreats, where a group of people get together and pair on implementing Conway's Game of Life. They're then give some constraints, change pairs, and start over on the same task.

In this short book he goes through some things he's learned about design as a result of seeing the patterns that have come out across many code retreats. This is followed by some notes on other design rules and guidelines.

It was definitely thought provoking, and it helped to stop and write my own implementation of life, and then refactor it a bit as I read along. Some thoughts came up which seemed obvious things to consider, but weren't covered.

A bit of a mash together of thoughts and ideas, and felt slightly overpriced for what it is, but that said I'm glad I read it.

I'd give it 7/10, but rounded up to 4 / 5.

[Johnny · Rating 4 out of 5]

In „4 Rules of Simple Design“ Corey Haines uses Conway’s Game of Life to explain the main points you should follow to write maintainable software:
1. Tests Pass
2. Expresses Intent
3. No Duplication (DRY)
4. Small

The result of following those simple rules is code that can adapt to future change – without building all the possibilities in long before you need them. Reduced cost of maintenance is just one reason to follow those rules, more fun another.
For me Corey could have explained the rules with more examples. As this book is at the moment you may not get all your questions answered – but more updates are likely to come so this may change soon.

[Angelo · Rating 5 out of 5]

A short read (I blew through it in a single morning) that should be mandatory reading for anyone claiming to be serious about writing software. More accessible and readable than Clean Code: A Handbook of Agile Software Craftsmanship, more practical and applicable than The Pragmatic Programmer: From Journeyman to Master.

[Christian Panadero · Rating 5 out of 5]

I can't believe that I didn't read this book until today. A very comprehensive explanation of the 4 rules of simple design. Is incredible how in a little piece of code with a very simple domain we can think on a lot of things that could be improved just applying a fixed set of rules. This turns out how our profession is new and we are still learning how to craft better code.

[Ariejan de Vroom · Rating 4 out of 5]

Nice read. Pretty short, but very informative and insightful.

[Bjoern Rochel · Rating 4 out of 5]

Quick enjoyable read. Even in the smallest code pieces there's so much room for improvement, if only one cares about the story the code is telling

[Tjen Wellens · Rating 5 out of 5]

I believe the lessons from this book will help me break through the plateau I've been stuck at (unconsciously) for a long while now.

[Tiago Massoni · Rating 3 out of 5]

Reunidas de forma esperta por Kent Beck nos anos 90, as leis de "design simples" reúnem, de forma muita concisa, a sabedoria de boas decisões de projeto que levam a um programa fácil de mexer - talvez o requisito mais importante de qualquer software. Ele, claro, na época deu um jeito de promover sua ideia de "test-first", que faz muito sentido, mas que na época era estranha pra muita gente. Se levadas a cabo em todas as decisões de programação, acredito que as quatro regras - (1) test pass, (2) express intento, (3) no duplication, (4) small - acabam guiando a construção de programas de qualidade. Mesmo assim, é mais legal ainda saber por que essas leis funcionam do que simplesmente aplica-las inconscientemente.

[Peter Knobloch · Rating 4 out of 5]

This book was short. It gives examples by working through some of the design principles for Conway’s Game of Life.

It shows the examples only once, so you have to be watching very carefully. I felt that I need to work through the examples on my own and figure out what he’s trying to say.

I ended up following some of the links to external resources. They also helped clear up some concepts, but mostly through repetition.

I found more insight in the first proper explanation of The Law of Demeter. I even read the original paper, which was dense and not easy to read on the bus.

A good book to start on the TDD journey. Next up, I’m going to try Kent Beck’s book.

[Vaclav.makes · Rating 4 out of 5]

Stručná kniha, která se mi líbila právě vystížným podáním jak psát vzhledově jednoduché programy.

Obsahuje zajímavé myšlenky, hned jedna z prvních byla - neptejte se na mít dobrý design, ale jak stávající design vylepšit.

[Bugzmanov · Rating 4 out of 5]

Short read for those who are fascinated about OOP being ontology modeling tool. Shows different techniques how you can stretch your imagination and come up with alternative designs. Friendly reminder that OOP doesn't have to be about Services calling sequences of "load" and "save" on Repositories.

[Ian Gagorik · Rating 5 out of 5]

I was asked to read this book, and was very surprised by it. Well thought out, easy to understand, and a quick read. If you write code, you should read this book. Very helpful. Only critique, I wish there was a print version I could put on the shelf.

[Wolfram Kriesing · Rating 5 out of 5]

Great book! Short but explicit and precise. Must read!

[Cedd · Rating 4 out of 5]

A quick and easy read with some excellent points.

[Theofanis Despoudis · Rating 4 out of 5]

The book is good but unfortunately is very short and soon becomes forgettable.

[Mohamed Nijadi · Rating 4 out of 5]

Quick read on what the author considers best practices in writing code, with easy to understand examples.

[Jascha · Rating 3 out of 5]

At some point during his career, any developer reaches a plateau: he gets used to work and use specific tools and techniques that make his life easier. More often than not, anyway, there are better techniques that allow to get out of that comfort zone and stop up to the next level. Adapting can be hard, since it might require changing the way we think about a problem. While I don't remember taking any course on the subject at the University, there are, instead, many titles out there that cover this topic. Understanding the Four Rules of Simple Design belongs to this cateogory of books and targets developers that need a little help to get out of that plateau.

Released back in 2014, Understanding the Four Rules of Simple Design us a very thin book which spans only 80 pages. It's a very user-friendly read that does require very little understanding of programming.

The author focuses on four design concepts that the reader should understand whenever he is involved in the design, and then coding, of some software. It's not just about learning the features of a language. It's about writing fotware flexible enough to be able to adapt to changes.

Without getting too much into details, the author discusses the following topics: tests, express intent, don't repeat yourself, and small. Each starts with a scenario that is working but that is far from being flexible. Through step by step examples, written in Ruby, the author slowly gets the reader to a better and more flexible solution of the problem.

Each concept is coupled with short code snippets in Ruby. The code is short enough to illustrate the topics being discussed without getting the reader lost. Even if the reader is not familiar with Ruby, it does not take much to understand it.

A couple of personal thoughts, to wrap it all up. First, the concepts discussed in the book are nothing new. There are many excellent titles covering the same topics and more. Clean Code by R. Martin is the first title that comes to my mind among those excellent ones. Second, the price is honestly too high, for such a thin book.

As usual, you can find more reviews on my personal blog: books.lostinmalloc.com. Feel free to pass by and share your thoughts!

[Ravi Sinha · Rating 5 out of 5]

This book is great. It's a short and easy read. It starts off with the basics, talking about four rules of simple object oriented code design that form the basis of or lead directly to some of the fancier concepts in the realm, such as SOLID or Design Patterns. The basic premise is that your code will change according to your customer's whims, and yet you don't know how exactly it would change, so how do you write it such that it is as adaptable to unforeseen changes as possible. Although simple in the beginning, it picks up and turns into an intense discussion around low-level design decisions. You'll see code written and being thrown away, assumptions being questioned, and better decisions being made. I also liked the hands-on kind of way of looking at what looks like DRY but isn't _actually_ DRY. The emphasis is also on 'better' rather than 'good' - the confession that there's no such thing as 'ultimately good' is refreshing to read. Although the book uses Ruby and follows a test-driven development methodology, you'll gain good insight about developing systems in general. It might not be so if you are very experienced, but for intermediate programmers, definitely a good read. Might also be worth reading it, then going out in the real world and doing some coding, and coming back for a second read in a year and see if you can get even more out of it.

[Mindaugas Mozūras · Rating 3 out of 5]

In this book, Corey Haines uses Conway’s Game of Life as a basis for examples to explain 4 Rules of Simple Design. Those are:

* Tests Pass
* Express Intent
* No Duplication of knowledge
* Small

The rules themselves aren't new. Neither are any of the points Corey makes. They do work as good reminders though.

The book itself is well written and the examples provide insight. It's an easy read, but ends kind of abruptly. While I was aware of its length, I expected a bit more. Price to knowledge ratio can scare some of the potential readers away.

[Maurício Junior · Rating 4 out of 5]

It's a nice and short book to read about OOP, design and test-first methodology.

In this book Corey shows to us about 4 rules (Tests Pass, Expresses Intent, No Duplication (DRY), Small) to keep our software simple, maintainable and clean.
I believe that this book is a nice one for those that are starting to understand what is a good software that people can understand and what is a bad software that only machines can understand.

In the final pages of the book there are nice subjects to learn as SOLID principles, How to plan and execute a good Pair-Programming etc.

[Vadim · Rating 5 out of 5]

I would love to see more books like this one.

One note: as author mentioned "noticing coding patterns" it would be much better to have at least two or three examples per rule in different parts of GoL codebase so reader can start seeing these patterns as well.

Besides this it's a great book. Awesome job Corey! :)

[Franck Chauvel · Rating 3 out of 5]

Corey explains how four simple rules, initially summarised by K. Beck, makes design better. He shows how theses rules emerged tin the code retreats he facilitated. Although the book is short—more of a booklet—it distills a deep knowledge about coding as a though process, perfect to trigger and reflect on code katas, especially.

[Toño · Rating 4 out of 5]

Very interesting thoughts about Four Rules of Simple Design based in Game of Life Kata.
I agree with most of the conclusions and the review of Simple Design Rules.
In my opinion, I see in the final examples, a little bit of 'magic' and some jumps in the flow we were following with the author.

It's a good booklet, you can read it very quickly and you give away very useful information.

[Enrique · Rating 3 out of 5]

It's an small book which has a very clear examples of the four rules.
I'd understand the rule about minize duplication better thanks to this book.

All the examples are in Ruby but it's easy to read even when you don't know this language.

[Kai Evans · Rating 5 out of 5]

a bit simplistic but a good reminder of good stuff

[Melvin · Rating 4 out of 5]

Succinct and insightful reading on simple [low-level] design. The book is easy to read and the author's writing style is engaging.

I found the book (88 pages) a bit pricey (18 USD) though.