Understanding the Four Rules of Simple Design and other lessons from watching thousands of pairs work on Conway's Game of Life (2014)

Introduction

From 2009 to 2014, I traveled the world working with software developers, both individually and in teams, to improve their craft. I did this primarily through a training workshop format called coderetreat. During these day-long events, we worked on improving our ability to make good choices around the minute-by-minute decisions we make while writing.

Over those years, I watched thousands of pairs of programmers work on exactly the same system, Conway’s Game of Life. As a facilitator of these coderetreat workshops, I had the unique opportunity to provide feedback, both direct and through questions, on improving the act of writing adaptable, simple code. As time progressed, I began to see patterns arise, common techniques and designs that spanned languages, stayed the same between companies, and crossed national borders. My job as a facilitator was to ask the questions that would push people past these common ideas, gently (and sometimes not so gently) prodding the participants into opening their minds to alternate ways to approach their design.

This book contains some of those patterns, designs and my responses to them. Grouped into a series of examples against the backdrop of Conway’s Game of Life, I’ve done my best not just to write the mechanics — the What — of the refactorings, but to focus on the ideas behind them — theWhy —.

This Book

Who It Is For

This book is for developers. I know that sounds a bit vague, but I’m not sure how better to state it. Okay, let me try.

It is for beginners.

Are you just learning to program? WELCOME! Perhaps you are in the throes of discovering what it’s like to make, what it’s like to wake up in the morning and create something that wasn’t there yesterday. Exciting, right? And it’s a wonderful career/hobby. This book is for you. You haven’t had to maintain a larger application, yet. You haven’t had the pleasure of wading through reams and reams of spaghetti code, trying to track down that one elusive place to make your change safely. And then you find that codebase was written by you. The ideas contained in this book are about some of the fundamentals of software development, principles you need to think about when writing an application to do your best to ensure this doesn’t happen.

It is for intermediate developers.

Nice! You’ve been programming a while, written a few systems, and you’re feeling pretty solid. Maybe you’ve been coding for a handful of years, and have established “your way” to be effective. Unfortunately, at this stage, it is easy to hit a plateau with your skills. Once effective, it can happen that you stop learning, either consciously or subconsciously. After all, you know what you’re doing, right? Now is the time to go back to the fundamentals, really analyze the “Why” behind the decisions you make. By stripping your thoughts down to the core, you can build them back up with even more insight and understanding.

It is for advanced practitioners.

You’ve been doing this for a very long time. Over the years, you’ve figured out how to build systems that can stand the test of time, easily accepting any changes that come. Awesome! This book is for you, too. It is easy to lose sight of the fact that others have to maintain your code, often without the context you have. And sometimes we forget the fundamentals. After all, we tend not to think about them anymore. Going back and thinking about the basics, though, can often shed light on some of the decisions we make, helping us continue to fine-tune our practice.

What It Is (And Isn’t) About

Throughout the building of a system, there are many levels of design decisions, ranging from the large up-front thinking (à la hammock-driven development) to the almost continuous decisions made around things such as naming variables and extracting methods.

This book is focused on the latter. While there are important considerations and thoughts to be had at all stages of the software development lifecycle, I’m choosing, for the purposes of this book, to assume they have happened. Instead, the examples here are low-level, focused on decisions that are made in the minute-by-minute rush of writing code.

This book is not about any particular technique. It’s not about any particular language. While the examples use an object-based/object-oriented language, most of the ideas transcend that and focus instead on the fundamentals of writing adaptable code — code that can accept change as it is needed.

And lastly, this book is not a step-by-step guide to building Conway’s Game of Life. In fact, we spend very little time on the actual system itself. As with coderetreat, GoL is just a backdrop that we use to investigate how best to apply the 4 rules of simple design, and other design guidelines, at the micro-level when writing code.

Format

This book is built as a series of essays, a series of examples, highlighting different ways to think about your code in the context of the 4 rules of simple design. Rather than grouping them by the individual rule, however, I’m celebrating the fact that the rules feed into each other iteratively. Often, completing a refactoring based on “Expresses Intent,” for example, will highlight a further refactoring based on “Eliminate Duplication.” Because of this, while the examples can stand on their own, they are best read through in the order presented.

Why Ruby?

Most of the examples in this book are written in Ruby.

I chose Ruby because it has a readable syntax with a minimum of ceremony. The code snippets are small, and I try to use little-to-no ruby-specific functionality. If you have a familiarity with any type of language, you should be able to understand the examples with little effort.