Andrew Hunt: “Leave room for emergence” [a Getting Real excerpt] 37signals 22 Mar 2006

14 comments Latest by Kathy Sierra

Andrew Hunt, co-founder of The Pragmatic Programmers, on why you should leave room for emergence.

Emergence is one of the founding principles of agility, and is the closest one to pure magic. Emergent properties aren’t designed or built in, they simply happen as a dynamic result of the rest of the system. “Emergence” comes from middle 17th century Latin in the sense of an “unforeseen occurrence.” You can’t plan for it or schedule it, but you can cultivate an environment where you can let it happen and benefit from it.

A classic example of emergence lies in the flocking behavior of birds. A computer simulation can use as few as three simple rules (along the lines of “don’t run into each other”) and suddenly you get very complex behavior as the flock wends and wafts its way gracefully through the sky, reforming around obstacles, and so on. None of this advanced behavior (such as reforming the same shape around an obstacle) is specified by the rules; it emerges from the dynamics of the system.
Simple rules, as with the birds simulation, lead to complex behavior. Complex rules, as with the tax law in most countries, lead to stupid behavior.

Many common software development practices have the unfortunate side-effect of eliminating any chance for emergent behavior. Most attempts at optimization — tying something down very explicitly — reduces the breadth and scope of interactions and relationships, which is the very source of emergence. In the flocking birds example, as with a well-designed system, it’s the interactions and relationships that create the interesting behavior.

The harder we tighten things down, the less room there is for a creative, emergent solution. Whether it’s locking down requirements before they are well understood or prematurely optimizing code, or inventing complex navigation and workflow scenarios before letting end users play with the system, the result is the same: an overly complicated, stupid system instead of a clean, elegant system that harnesses emergence.

Keep it small. Keep it simple. Let it happen.

[This is an excerpt from Getting Real, the new book from 37signals on the smarter, faster, easier way to build a successful web app.]

14 comments so far (Jump to latest)

Nick 22 Mar 06

I’m not a very good programmer or designer, so mabey someone can help me out.

How exactly does that excerpt pertain to real world web app development?

Rabbit 22 Mar 06

Hmm… there’s another post on this blog about the ways in which people were using Tada lists. (Or was that in the book? They’re so alike I get them mixed up ;)

Anyway, since it doesn’t support “categories,” people were simply prefixing the items with their labels… e.g.

RUBY: Get better
HOUSE: Clean room
HOUSE: Clean bathroom
ERRAND: Get toilet paper
ERRAND: Make deposit


Simple rules, emergent conventions.

Nick 22 Mar 06

Ahh. That makes sense. Thanks Rabbit.

Mark Gallagher 22 Mar 06

Real world example of this:

We created an internal phonebook for our big bank (over 100,000 employees) with quick and easy access to “related people”.

No detailed requirements gathering, these were ideas from our small team.

Do a lookup on Joe Blow, you have single click access to:

- everyone in Joe’s department

- everyone on Joe’s floor (near his cube using mailcode data)

- everyone above and below Joe in the management hierarchy

We found employees using this data in ways we never expected or planned. Examples: building security used it when guests would visit a building, call centers used it to escalate customer problems, HR used in merger planning activities, etc.

By exposing the relationship data, we allowed the natural creativity of employees to use it in new and innovative ways.

Here are some screenshots

Note, nothing is being sold here, just sharing info.


Grant 22 Mar 06

This is exactly one of the tenets I used when developing my new user-centric recipes website.

Take a look at, then head over to my website, has every feature you’ll never use. They have 5+ different methods of searching, each with about 50 input boxes. Now, I tend to think of myself as a bit more savvy than the average user, and even I was lost on their site.

Constrast that with, where we have a single live-search input box.

Because we wanted to stay small and keep agile, adding or removing features became a breeze. I was able to RSS support in about 1/2 hour. This is probably a combination of us using Ruby on Rails with and a KISS methodology.

Thanks, 37signals.. you convinced us that not having every feature in the world isn’t a bad thing! Our users are thanking us, I’m sure.

Jan 22 Mar 06

This is exactly one of the tenets I used when developing my new user-centric recipes website

Speaking about cooking and recipes reminded me of that joel on software post on “Big Mac vs Naked Chef”. He talks about how there are very specific rules on making big macs (exactly 37 seconds for a hamburger), while a top chef like Jamie Olivier is basically improvising constantly. Emergent cooking in a way :)

Smith 22 Mar 06

Grant, your users are thanking you? Your site just launched 2 days ago…

Rabbit 22 Mar 06

Eh… Grant said:

Our users are thanking us, I’m sure.

Grant 22 Mar 06

Yeah, it’s a hypothetical thanks.

Gary R Boodhoo 22 Mar 06

Emergence is what makes life worth living! As a designer who also has done a fair amount of front end scripting, this was the very reason I embraced object oriented programming techniques. There’s just nothing more magical to me than to see a collection of simple behaviors combine into higher level interactions.

And it’s hardly just programming or design - I’ve found the challenge of working on large teams is to move beyond individual agendas (mostly) and individual desires for high level control (mostly) to see what the system itself suggests. A leap of faith is required to be sure, but without that leap, any product just tends to be more of the same.

random8r 22 Mar 06

This actually puts me in mind of fighting. The very best fighters have nothing prepared aside from knowing how to move their body effectively, and understanding how the body works and where its strengths and weaknesses are (therefore also on both sides of the equation - defense and attack).

Which actual techniques appear are almost certainly perfectly a result of the entire event as an interaction (ie attack & simultaneous response).

In other words, the entire purpose of an effective fighter is to “get out of the way” of the event. To disolve the even in the most effective way possible.

My teachers always said that the highest martial arts doesn’t involve physical fighting at all. Mostly it involves simply talking. You wouldn’t even know martial arts principles are being applied.

You’re probably wondering what this has to do with web or systems design?

Well, the most effectively designers are the ones that get out of the way of the design process, and don’t hinder it with “their own stuff” - they simply create function, style and form based around the context and environment they’re exposed to and the martials that they have at their disposals.

Nice :)

adam 22 Mar 06

To Mark Gallagher,

Just wanted to let you know that the blurred numbers in the SSN (I assume that is what they are) are still very much legible.

adam 22 Mar 06

umm…yeah - those are phone numbers


Kathy Sierra 23 Mar 06

This is one of my favorites for sure—that whole notion of complexity emerging from the simplest of rules…

Rabbit, when I saw your first comment I thought that
“RUBY: Get better”
was a directive.

I SO dream of the day when I can say, as you did:
“HOUSE: Clean room”

Post a comment

(Basic HTML is allowed)

NOTE: We'd rather not moderate, but off-topic, blatantly inflammatory, or otherwise inappropriate or vapid comments may be removed. Repeat offenders will be banned from commenting. Let's add value. Thank you.