The Architect´s Napkin

Software Architecture on the Back of a Napkin
posts - 69 , comments - 229 , trackbacks - 0

My Links



Post Categories

Image Galleries

What does Antifragility mean?

The notion of Antifragility has hit the software community, it seems. Russ Miles has posted a couple of small articles on it in his blog, asking what it could mean for software development – but also listing a couple of ingrediences he thinks are needed.

I´ve read the canonical book on antifragility by Nassim Taleb, too. And I second Russ´ description: Antifragile software is software “that thrives on the unknown and change”.

But still… what does it mean? “To thrive on the unknown and change” to me is too fuzzy for me to help me in my day to day work. Thus I cannot even judge if Russ is right when he says, micro services help to implement Antifragility.

That´s why I want to share some thoughts on the topic here. Maybe writing about it helps to clarify the issue for myself – at least ;-)

Is Antifragility something to strive for?

To me that´s a definite Yes. Yes, I want my software to be antifragile.

Clearly software should not be brittle/fragile.

That´s why there exists a canonical non-functional requirement called robustness.

But antifragility goes beyond that. Software should not just withstand stress, it should become better and better by being stressed. Software should improve because of strain, not despite it.

To be more concrete: Changing requirements – functional as well as non-functional – should cause software to be able to adapt even easier to further changes.

The status-quo seems to be the opposite: The more changes are heaped onto a software the more difficult changing it becomes. What we end up with is legacy code, a brownfield, a big ball of mud, spaghetti code. All these terms denote the same: a fragile code base. It´s fragile because the next change request might cause it to break down, i.e. to enter a state where it´s economically infeasible to further change it.

So, yes, I guess Antifragility is something we really need.

Fragility and robustness

But how can we implement Antifragility? How can we check, if approach A, tool T, concept C, principle P etc. benefit Antifragility or harm it?

I guess, we need to start with fragility and robustness to understand Antifragility.

What´s fragility? It´s when a small change in the environment causes harm. A glass vase is fragile, because a slight change in pressure can cause it to break. A football in contrast is not fragile. It´s robust with regard to pressure.

But maybe a football is not robust with regard to heat. Maybe it´s inflammable – and the glass vase not.

What distinguishes a glass vase from a football is their capability to compensate change of certain environment parameters. For short I call this capability a buffer.

If something is more robust or less fragile than something else, its buffers are larger. A glass vase and a football differ in their pressure buffers and their temperature buffers.

That means, if you want to make something more robust, then you need to increase its buffer regarding certain changes. For that you have to know the potential forces/stressors/attack angles. Do you want an item to be more robust regarding temperature or pressure or vibration or radiation or acceleration or viruses or traumata?

Into software you can build buffers for performance, scalability, security, portability etc. Software “can come under attack” from all sorts of non-functional angles. Today it´s 10 users per second, tomorrow it´s 1000 users. That´s stress on a software system. Does it have buffer capacity to compensate it? If so, it´s robust. If not, it´s fragile with regard to the number of users per second.


With this definition of fragility/robustness in place, what does Antifragility mean? Nassim Taleb says, it goes beyond robustness. Robustness is not the opposite of fragility, but just fragility on another level or less fragility.

I´d like to call Nietzsche to the witness stand. To me he´s the godfather of Antifragility, so to speak, because he says:

“What doesn´t kill me, makes me stronger.” (Maxims and Arrows, 8)

Yes, that´s what to me in a nutshell describes Antifragility.

Let me dissect his statement:

First Nietzsche acknowledges there are forces/stressed that can destroy an item. And I´d say, Nassim Talebl does not object. Antifragility does not equal immortality.

Destruction occurs if the buffer capacity of some robustness is exceeded. A glass vase might withstand a larger temperature change than a football. But in the end even glass melts and thus the vase form is destroyed.

That´s the same for antifragile systems. They have buffers, too. And those buffers can be stressed too hard.

But here´s the catch: What if the buffer capacity is not exceeded? What if some stress could be compensated?

For a more or less fragile/robust item this means, well, nothing special. It did not get destroyed. That´s it. Or maybe the buffer capacity is now lower. That´s what we call “wear and tear”.

An antifragile system, though, gets stronger. It changes for the better. No wear and tear, but increased buffer capacity. That´s the difference between levels of fragility and Antifragility.

Fragile, even robust items have static buffers at best. Usually though, their buffers decrease under repeated stress. Antifragile systems on the other hand have dynamic buffer which grow because of stress. Of course, they don´t do that during stress, but after stress. That´s why antifragile systems need rest.

Antifragile systems need time to replenish buffer resources – and extend their buffers. Try that out for yourself with some HIIT (high intensity interval training) for push-ups. It´s a simple proof for the Antifragility of your body. It might hurt a bit ;-) but you can literally watch over the course of a couple of days how your buffers grow, how you get stronger.

HIIT combines high stress (near depletion of buffers) and rest – and thus promotes growth.

And that´s what Antifragility is about: growth. Antifragile systems grow as a reaction to stress. Increasing stressed buffers happens in anticipation of future stresses. Antifragile systems don´t want to be caught off guard again, so they increase their robustness. In essence that´s learning. A larger buffer next time means less risk of harm/destruction through a particular type of stress.

At the same time, though, unused buffers shrink. That´s called atrophy. Stay in bed for a month and you´ll become very weak. Not after a night in bed, not after a day or two. But prolonged underusage of muscles causes them to dwindle.

That´s just economical. Keeping muscle power buffers large costs energy. If those buffers are not used, well, then why spend the energy? It can be put to good use at other buffers or saved altogether.

Antifragility thus does not just mean growth, but also reduction. Stripping down buffers is nothing to fear for a truely antifragile system, because it can build up any buffer at any time if need be.

This (meta-)capability of course is also limited, however. It´s a buffer like any other. And it can be grown – or it can shrink. That´s what we usually call aging. A system ages if it loses its Antifragility. In the end it´s just robust – and finally worn down by some stress.

Becoming alive

If we want to talk about Antifragility in software development we need to talk about life. Software needs to become alive. Or the system consisting of code + humans needs to become alive. Truely alive.

We need to identify stressors. We need to identify buffers to compensate those stressors. We need to measure the capacity of those buffers. We need to find ways to increase – and decrease their capacities timely and at will in reaction to stresses. We need to assess risks of stress recurrence in order to determine if increase or decrease is appropriate. We need to rest. And finally we need to accept death.

To me that means, Antifragility is much, much more than SOLID code plus some micro services plus message based communication via busses plus reactive programming etc. First of all it´s not just about code, because code itself is not and cannot be alive. Thus code itself cannot change itself for the better after stress, like no football can increase its temperature robustness.

Rather the “socio-mechanical” system made up of humans and their code needs to be formed in a way to be antifragile. Which of course also implies certain beneficial structures and relationship in code. But that´s not all to think about.

So we´re not there, yet, I´d say. Antifragility is more than Agility + Clean Code. First of all it´s a mindset, a worldview. And as usual, to instill that into people is not that easy. It will take another 10 to 20 years…

Therefore let today be the first day of another journey in software development. Let the Antifragility years begin…

Print | posted on Wednesday, March 5, 2014 9:28 PM | Filed Under [ Thinking outside of the box ]



# re: What does Antifragility mean?

Well written. Especially these sentences: "Antifragility is more than Agility + Clean Code. ... "It will take another 10 to 20 years…"
3/15/2014 2:18 PM | Andreas
Post A Comment

Powered by: