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

Foreword

Foreword: Kent Beck

Here’s why I wrote the rules, near as I can remember.

As I was coming up as an engineer, the advice I always heard was, “Design for the future. Change is expensive. Make it cheap by anticipating it.” What I noticed in practice was that the more change I anticipated, the harder it got to make changes. My incorrect speculations interfered with changes I actually ended up making. Then I would have to choose between working around speculative cruft or ripping it out, both of which delayed progress on what I was trying to accomplish.

I wasn’t alone. Lots of folks noticed the cost of speculation. The prevailing response seemed to be that we just weren’t good enough at speculation. If we were better speculative designers, we would end up with better designs. This looked like a positive feedback loop to me: more speculation -> worse design -> more speculation.

The good news about disastrous positive feedback loops is that you can generally drive them backwards. I first experimented by ignoring any changes that seemed like they would happen longer than six month in the future. My designs were simpler, I started making progress sooner, and I stressed less about the unknowable future. I shortened the time horizon to three months. More better. One month. More. A week. A day. Oh, hell, what happens if I don’t add any design elements not demanded by the current code and tests? Still more better.

Now I had an ethos of software design, but I stupidly labelled it “simple”. Talk about a vague, loaded word that everyone will use to justify exactly what they are doing now. I soon tired of debating what “simple” “really” meant. I needed a clear explanation.

My approach to communicating complex ideas at the time was to formulate a simple set of rules, the emergent property of which was the complex outcome I was aiming at (cf patterns). (I have since become disenchanted with this strategy.) I thought about how I recognized simplicity, turned those criteria into actions, sorted them by priority (it’s no coincidence that human communication is number two), and posted them on Ward’s Wiki. And that’s why (and how) I wrote the rules.

– Kent Beck / @kentbeck

April 2014

Foreword: Joe Rainsberger

I can trace my interest in Code Retreat back to 2004, although of course, nobody had given it that name yet. Around that time, many of my friends and colleagues had become fascinated with the idea of intentional practice. We all looked at each other wondering how we could ever convince a group of already-overworked people to practise. We assumed that most employers would object to practising during work hours. We also assumed that people wouldn’t want to fail and learn in front of their peers. At most, we figured that small bands of crazy people might find each other and practise together from time to time, but that it would never really go anywhere. Even as Coding Dojos became more popular, I didn’t see intentional practice becoming any more significant than a fun way to pass time at conferences and a curiosity at only the most experimental workplaces. By 2007 I mostly forgot the whole thing.

Imagine my surprise when I received an invitation in January 2009 to come down to Ann Arbor, Michigan to attend the first-ever Code Retreat. I didn’t intend to go. I didn’t think that I could justify the expense of flying down to participate in a free event. But someone had recently burgled our house, and that left me feeling disconnected from the place. One morning I simply decided that, expensive or not, I wanted to go. I wanted to see my friends, and I figured I’d never get to see so many of them in one place for an event smaller than a conference.

I found myself in a room with about 40 eager programmers, some of which had traveled through snowy conditions from two hours’ drive away. I didn’t know what to expect. Conway’s Game of Life? Over and over again? All day? It sounded strange. It sounded like it wouldn’t work. Wow, does it ever work!

And now, five years and hundreds of Code Retreats later, Corey has distilled tens of thousands of hours of collective learning into this powerful little book. I intend to recommend it as a guidebook to anyone who wants to learn the fundamentals of maintainable, cost-effective software design. I’ve been saying for years that if you simply follow Kent Beck’s rules of simple design, then you’ll see how every good design principle you’ve ever heard of reduces to some combination of “remove duplication” and “improve names”. Of course, waving my hands like this requires relatively little effort.

With this book, Corey demonstrates the Implementers Rule: implementers rule. I’ve wanted to see a book like this for years, but never had the energy to write it. Corey has literally spent years and traveled thousands of kilometers making it happen. That makes me happy.

In five short years, I have attended and helped facilitate perhaps a dozen Code Retreats in almost as many countries. I’ve participated in the Global Day of Code Retreat in Gent, Stockholm, and a five-minute walk from my house in Atlantic Canada. I’ve helped launch Legacy Code Retreat, a member of the Code Retreat family, which has taken root in Europe and already helped hundreds of programmers practise rescuing legacy code in a safe environment. Code Retreat seems intent on staying with us for years to come. Those facts and this book form a significant part of Corey’s professional legacy to us. I get to say, “I knew him when…” That makes me happy, too.

As you practise test-driven development and use the four elements of simple design to guide your decisions, you’re going to notice patterns. You’ll recognise that when you see duplication over here, that means that some code over here wants to become a brand new module. You’ll notice a recurring pattern in names that nudges you gradually-but-firmly towards moving this code over there. You’ll find some of those patterns in this book, but more importantly, you’ll notice patterns that you won’t find in this book. New patterns. Patterns that we know, but that nobody has taken the time to write down before. Perhaps even patterns that nobody has ever noticed before. When that happens, I hope that you’ll think back to this book and recognise how it and Code Retreat have helped you reach that wonderful learning moment.

That would make me really happy.

– J. B. Rainsberger / @jbrains

Summerside, PEI, Canada

March 2014