Ergodic Development

Stayin' Alive, Stayin' Alive 🎶

Whether you're a brother or whether you're a mother
You're stayin' alive, stayin' alive
Feel the city breakin' and everybody shakin'
And we're stayin' alive, stayin' alive
Ah, ha, ha, ha, stayin' alive, stayin' alive
Ah, ha, ha, ha, stayin' alive
— BeeGees

Ergodicity reminds us to divide our systems into:

• Those that tend to continue roughly as is, regardless of perturbations (ergodic)

• Those that experience Game Over in response to change (non-ergodic—not a great name)

Treat these 2 flavors of systems very differently. Treat Game Over systems gingerly, as there is no going back once they are gone.

Non-ergodic systems can be exhausting to manage, so

Luca Dellanna

, in his lovely short book Ergodicity, offers 3 general strategies for transforming Game Over systems into sustaining systems:

• Reduce exposure to irreversibility

• Skin in the game

• Load redistribution

What would happen if we applied these strategies to software development? (Hint, it’s going to end up looking a lot like XP. Hope you aren’t surprised.)

Ergodic Development

What follows assumes that we want the software development project to survive. Which is true, economically. At one point the OS/360 PL/1 compiler was bringing in $300m annually with a team of 3 people to support it. Ergodicity can be ridiculously profitable.

More Reversibility

We would plan & execute in smaller cycles so decisions would be cheaper. Go the wrong direction for a week? Monday it’s a new game. Push the design the wrong direction? Throw the change away & start over. The change we made would have caused errors in production? Glad we found out now before any damage was done.

All this insurance we pay for is going to seem expensive. But, as always, compared to what? It’s expensive compared to the universe in which we just do the right thing the first time. Unfortunately (or fortunately) we don’t live in that universe.

Skin In The Game

Making sure consequences flow to actors creates value 2 ways:

• Encourages good behavior

• Discourages bad behavior

If we want skin in the game in our software project we will:

• Programmers are on call for production support.

• Programmers test their own changes, tests they are responsible for keeping healthy.

• Everyone sits together (or is on frequent video calls) so user problems are immediately experienced by those who caused the problems.

• Software designers who make changes are also responsible for helping those affected by those changes.

• Ideally, the team uses the product in their daily work.

In each of these cases, we are doing “extra” work. The folks with skin in the game could go faster if they didn’t have skin in the game. However, lack of feedback feeds risk of Game Over. Survival over optimization.

Load Redistribution

We would have a big enough team serving a wide enough variety of needs that when any one of those needs spiked we could quickly add attention to it. We would encourage migration across teams so if one team experienced a spike we could quickly augment it. We would encourage cross-specialty collaboration so no one kind of task would become a bottleneck.

In what is becoming a theme, preparing to redistribute load costs more than maintaining silos. We don’t mind paying the price, though, because we care about survival. We want to make non-ergodic, Game Over, development as ergodic as possible.

And Next…

When I had the idea for this essay I thought it would end up being more complete. Instead I have just barely started applying the lessons of ergodicity to software development. Read the book. Apply it yourself. Comment.

Meta-Cognitive Note—you’ll notice I’ve been applying ergodicity a bunch of different ways recently. This is a habit, both for me & the most successful of my coaching students. When you get a new idea, try over-apply it. That’s the only way you’ll find the boundaries of its application.