
Discover more from Software Design: Tidy First?
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
, 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.
Ergodic Development
Another strategy to reduce ergodicity is diversification. It's implicitly treated in Luca's book but not explicitly mentioned. How would that translate in software development? I think modularity in code structure and cross functionality in teams would be important aspects.
Very nice. Total common sense. When is the book being released.