Emergence

Posted on: 21 March 2013

A suitably ambiguous title I know, but it will become clear soon enough. On a slow evening earlier this week, after a brief perusal of the latest goings-on on Twitter, I found myself on the 37signals website. More specifically, reading their free downloadable "Getting Real" book. Flicking through it, I stumbled upon a brief excerpt from (I assume) a book called The Pragmatic Programmers. This particular page caught my attention the most.

"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."

I love this idea.

I'm a coder/programmer/engineer, whatever you want to call it, but fundamentally I enjoy solving problems through code. The whole concept of "emergence", where functionality and features are born organically out of code I've written intrigues me.

The writer, Andrew Hunt, goes on to explain '“Emergence” comes from middle 17th century Latin in the sense of an “unforeseen occurrence.”', that "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.".

The gist of the excerpt is that many, bloated, modern software development practises decrease the chance of emergence occurring; the idea of tying a process down, reducing the creativity it could've born. It all comes down to the KISS principal (Keep It Simple, Stupid); do you not over-complicate your system, and the simplicity will speak volumes.

The example Andrew gives is a simulation of a flock of birds, where simple rules programmed into the application, can produce a mesmerising end product. A basic collision-detection algorithm can produce complex behaviours as "the flock wends and wafts its way gracefully through the sky".

In my day job, I manage to achieve lots of small wins and small examples of emerging behaviours by sticking to the DRY (Don't Repeat Yourself) mantra. By adhering to simple separation of concerns principals - separating business logic from business data - applications can be transformed simply by swapping between datasets. With a tightly-coupled system and an ignorance of the bigger picture whilst building, happy accidents (read: emergence) seldom occur.

To borrow Andrew's closing line, Keep it small. Keep it simple. Let it happen.