ISE Blog

Lessons from the Fragile

What's the opposite of fragile?

Most people would answer "robust" or "resilient." If we subject something that is fragile to stress, shock, randomness or volatility, we can expect that it will be harmed. If we do the same to something that is robust or resilient, we can expect that it will resist harm - but won't be any better off than when we started. But what if something that is subjected to stress, shock, randomness or volatility actually benefited? That would be the opposite of fragile: antifragile. This is the core theme of Nassim Nicholas Taleb's book, Antifragile: Things That Gain from Disorder. 
 

What does fragility and antifragility look like?

As human beings, we often think of things that have uncertainty or randomness as having a range of possible outcomes that are centered around some "most likely" outcome, as in the diagram below.

Fragile Outcomes Chart

However, in many domains there is an asymmetry, where there are possible, but very unlikely, extreme outcomes, as illustrated in the diagram below (note that the likelihood of the extreme negative outcomes is much smaller than shown on my chart - but not zero). Such asymmetry is called a "long tail."

Fragile Asymmetric Outcomes ChartConsider the case of reinsurance. Reinsurance is insurance purchased by an insurance company to cover their risk in the case of a catastrophic event. The reinsurer is paid premiums, and is only liable in the case of the catastrophic event. What's the maximum upside for the reinsurer? If no claims are paid, they earn the value of the premiums paid, plus whatever investment income they have managed to make from holding that money. But what's the maximum downside? A single, unpredictable extreme event can have enormous negative consequences. Taleb calls this a negative "Black Swan" event, and uses the example of asbestos claims almost destroying Lloyd's of London. Since "Black Swan" events are unpredictable, calculating probability is of limited use, but we can detect these kinds of asymmetries and identify such situations as fragile. Taleb also points out that both uncertainty and time are as good as stress, shock, randomness and volatility as far as being triggers for asymmetric outcomes.

Positive Asymmetry - the Antifragile

If we look at the reverse of negative asymmetry, we find positive asymmetry, such as in the diagram below. Innovation can look like this: what's the maximum downside? We lose the money invested. What's the upside? Sometimes we'll innovate something that makes money; usually we'll learn something; rarely we'll innovate something that makes a lot of money - a positive "Black Swan" event.

Fragile Black Swan Chart

Taleb also points out that optionality and tinkering are both antifragile. Optionality is just that: having options. Taking an innovation perspective again (and also thinking about the pivot or persevere mentality of The Lean Startup), if we keep our eyes open we can detect when our innovation has revealed a better option and switch paths to that. Taleb uses the example of mobile phone company, Nokia, starting as a paper mill. Such options tend to have a ratchet effect, where what we have learned moves us forward, not backward. Tinkering is evolutionary experimentation: we try something, and if it has benefit, we keep it and build on it; if it does not have benefit, we drop it. The key is retaining our optionality and having the wisdom to recognize when something has a beneficial outcome. 

What can we learn from this? How can we apply it?
First, detect fragility and minimize exposure. Taleb makes the point that it doesn't matter how much upside you have from a situation, if the situation is inherently fragile then a single negative "Black Swan" event can wipe you out. His advice, therefore, is to first detect and reduce your exposure to fragility. 
 

Traditional Software Schedules are Fragile 

Consider the traditional software schedule below. Traditional software schedules typically divide work into layers (horizontal slices), and then into tasks (not shown in my level of detail here).

Software Schedules

There are at least several fragilities in this approach. The first is the likelihood of completing any given task in the time estimated. Consider the chart below: If I estimated a task to take 3 days, and it goes really well, I might complete it in 2 days, but it is unlikely I will complete it in 1 hour. But there are any number of things (my development environment got corrupted, my hard disk went bad, I did not understand what was needed to make my task work, …) that could make the task take longer - or much longer. Here is a fragility due to asymmetry again. (The horizontal axis is reversed from the previous charts, because in this case a longer duration is a more negative outcome.) Also, consider that due to dependencies, these kinds of fragilities tend to stack (accumulate), rather than negate each other. 

Fragile Estimation of Outcomes Chart

Another fragility to consider in the traditional software schedule is loss of optionality. It may not be until I am into the GUI or even the Integration phase of this project that I detect that the Database (DB) choices I have made won't actually work well, but at that point I have invested heavily in the existing DB approach and may not have the time or budget to adjust. This makes my project fragile to my design decisions. 
 
Integration and test are discovery activities where we find out (get feedback on) the work we have done so far. By leaving these until late in the project, we defer learning that may cause us to need to rework significant portions of what we have done. 
 
Agile project planning, by comparison, focuses us on creating small, fully tested vertical slices, and keeping our optionality open sprint-to-sprint. In a small slice and the timebox of a sprint, the largest cost of going down the wrong path is the time spent on a sprint - or less: we often timebox risky activities and explorations to limit their cost. Vertical slices allow us to reveal early learning so that we can make course corrections. And by constantly adjusting the product backlog and release plans to current knowledge, we keep our options open with respect to finding new and better aspects of the product or the process. 

What are your thoughts on being fragile or antifragile? Stayed tuned for another blog post on some great questions to ask yourself to determine the difference. 

Andrew Smith, Principal Architect

Andrew Smith, Principal Architect

Andrew is a Principal Architect at ISE and leads ISE’s Agile community. He recently earned two new Agile certifications: ICAgile Certified Expert – Agile Coaching (ICE-AC) and ACI Certified Teams Transformation Coach (ACI-CTTC). Andrew is passionate about creating great teams, great software and great customer experiences, and is constantly looking for ways to adapt industry experience and best practices into ISE. In his free time, Andrew enjoys dancing Argentine Tango, public speaking with Toastmasters International, and Yoga.