Not online fitness shopping. Not the brogrammer pumping iron. This is a brief discussion of Antifragile – the latest book by Nassim Nicholas Taleb – and relevant insights for software delivery or other complex work.
This isn’t meant to be an exhaustive exploration of the topics. It’s more a join-the-dots exercise, and it’s left up to the reader to explore topics of interest.
Antifragile
Antifragile is a word coined by Taleb to describe things that gain from disorder. Not things that are impervious to disorder; the words for that are robust, or resilient. Of course, things that are harmed by disorder are fragile. Consideration of the fragile, the robust, and the antifragile leads Taleb in many interesting directions.
Fragile, Robust, and Antifragile Software
A running software program is fragile. It is harmed by the most minor variations in its source code, its build process, its dependencies, its runtime environment and its inputs.
But software is eating the world. The global software ecosystem has grown enormously over an extended time – time being a primary source of variation – and hence appears to be antifragile. How do we reconcile this apparent paradox?
Here is a grossly simplified perspective.
First, software code can evolve very quickly, passing on an improved design to the next generation of runtime instances. In this way, tools, platforms, libraries and products rapidly become more robust. However, human intervention is still required for true operational robustness.
Second, humans exercise optionality in selecting progressively better software. In this way, beneficial variation can be captured, deleterious variation discarded, and software goes from robust to antifragile.
So – as fragile parts create an antifragile whole – runtime software instances are fragile, but fragile instances that are constantly improved and selected by humans create an antifragile software ecosystem. (If software starts doing this for itself, we may be in trouble!)
Some Delivery Takeaways
Yes, I know that’s an oxymoron. Nonetheless, here are some of my highlights. It’s a while now since I read the book, and I might add to this in future, so don’t take it as the last word.
Dumbbell Delivery
The idea of “dumbbell”/”barbell” risk management is that you place your bets in one of two places, but not in between. You first ensure that you are protected from catastrophic downside, then expose yourself to a portfolio of potentially large upsides. In such cases, you are antifragile.
If, instead, you spread yourself across the middle of the dumbell, you carry both unacceptably large downside exposure and insufficiently large upside exposure. In such cases, you are fragile.
For me, “dumbbell delivery” is how we counter insidious elements of the construct of two-speed-IT (insidious because no one has ever asked to go slow, or asked for high risk as the alternative). We ensure any project is as protected as possible from catastrophic downside – by decoupling the commission of error from any impact on operations or reputation – and as exposed as possible to potentially large upsides – by providing maximum freedom to teams to discover and exploit opportunities in a timely manner.
Donald Reinertsen makes a similar argument for expoliting the asymmetries of product development payoffs in The Principles of Product Development Flow.
Via Negativa
Those who intervene in complex systems may cause more harm than good. This is known as iatrogenics in medicine. To manage complex systems, removing existing interventions is more likely to be successful than making additional interventions, as each additional intervention produces unanticipated (side) effects by itself, and unanticipated interactions with other interventions in tandem. Via negativa is the philosophy of managing by taking things away.
Software delivery, and organisations in general, are complex in that they are difficult to understand and respond unpredictably to interventions. What’s an example of an intervention we could take away? Well, let’s say a project is “running late”. Instead of adding bodies to the team or hours to the schedule, start by trying to eliminate work through a focus on scope and quality. Also, why not remove targets?
Big Projects, Monolithic Systems
Anything big tends to be fragile. Break it into smaller pieces for greater robustness. Check.
Waterfall and Agile
Waterfall done by the book is fragile. Agile done as intended is antifragile.
Procrustean Beds
Forcing natural variation into pre-defined, largely arbitrary containers creates fragility. Velocity commitments and other forms of management by performance target come to mind.
Skin in the Game
Of course, anyone making predictions should have skin in the game. On the other hand, Hammurabi’s code is the converse of the safe-to-fail environment.
The Lindy Effect on Technology lifespan
The life expectancy of a technology increases the longer it has been around. Remember this the next time you want to try something shiny.
Phenomenology and Theory
Phenomenology may be superior to theory for decision-making in complex work. Phenomenology says “if x, then we often observe y“. Theory says “if x, then y, because z“. Theory leads to the illusion of greater certainty, and probably a greater willingness to intervene (see above).
Flaneurs and Tourists
Chart your own professional journey. Allow yourself the time and space for happy discoveries.