Antifragility has attracted some attention lately. I, too, pressed the “I like” button. :-) A cool concept, a term that was missing. Just when Agility starts to become lame, Antifragility takes over the torch to carry on the light of change… ;-)
What I find sad, though, is that the discussion seems to be too technical too soon. There´s the twitter hash tag #antifragilesoftware for example. It´s suggesting, there are tools and technologies and methods, to make software antifragile. But that´s impossible, I´d say. And so the hash tag is misleading and probably doing more harm than good to the generally valuable concept of Antifragility.
Yes, I´m guilty of using the hash tag, too. At first I hadn´t thought about Antifragility enough and was just happy, someone had brought up the term. Later I used it to not alienate others with yet another hash tag; I succumbed to the established pattern.
But here I am, trying to at least once say, why I think, the hash tag is wrong – even though it´s well meaning.
Antifragility as a property
Antifragility is a property. Something can be fast, shiny, edible – or antifragile. If it´s antifragile it thrives on change, it becomes better due to stress. What is antifragile “needs to be shaken and tossed” to improve. “Handle with care” is poison to whatever is antifragile.
As I explained in a previous article, I think Antifragility comes from buffers – which get adapted dynamically. Increase of buffer capacity in response to stress is what distinguishes Antifragility from robustness.
In order to determine if something is antifragile, we need to check its buffers. Are there buffers for expectable stresses? How large is their capacity before stress? Is stress on a buffer-challenging level? How large are the buffer capacities after such stress? If the buffer capacities is larger after challenging stress – of course given a reasonable recuperation period –, then I guess we can put the label “Antifragile” on the observed.
Antifragility is DIY
So far it seems, Antifragility is a property like any other. Maybe it´s new, maybe it´s not easy to achieve, but in the end, well, just another property we can build into our products. So why not build antifragile blenders, cars, and software?
Here´s where I disagree with the suggestion of #antifragilesoftware. I don´t think we can build Antifragility into anything material. And I include software in this, even though you might say it´s not material, but immaterial, virtual. Because what software shares with material things is: it´s dead. It´s not alive. It does not do anything out of its own volition.
But that´s what is at work in Antifragility: volition. Or “the will to live” to get Schopenhauer into the picture after I called Nietzsche the godfather of Antifragility ;-)
Antifragility is only a property of living beings, maybe it´s even at the core of the definition of what life is.
Take a glass, put it in a box, skake the box-with-glass, the glass cracks. The stress on the buffers of the box-with-glass was challenging. Now put some wood wool around the glass in the box. Shake the box-with-glass, the glass is not further damaged. Great! The box-with-glass is antifragile, right?
No, of course not. The box-with-glass is just robust. Because the box-with-glass did not change itself. It was build with a certain buffer. That buffer was challenged by stress. And that´s it. The box-with-glass did not react to this challenge – except it suffered it. It even deteriorated (the glass cracked).
It was you as the builder and observer who increased some buffer of the box-with-glass after the stress. You just improved its robustness.
If the box-with-glass was antifragile it would have reacted itself to the stress. It would have increased its buffer itself. That way the box-with-glass would have shown it learned from the stress.
Antifragility thus essentially is a Do-it-yourself property. Something is only antifragile if it itself reacts to stresses by increasing some buffer. Antifragility thus is a property of autopoietic systems only. Or even: Autopoiesis is defined by Antifragility.
To put it short: If you´re alive and want to stay alive you better be Antifragile.
Antifragility is needed to survive in a changing environment.
So if you want to build antifragility into something, well, then you have to bring it to life. You have to be a Frankenstein of some sorts ;-) Because after you built it, you need to leave it alone – and it needs to stay alive on its own.
You see, that´s why I don´t believe in #antifragilesoftware. Software is not alive. It won´t change by itself. We as its builders and observers change it when we deem it necessary.
Software itself can only be robust. We build buffers of certain sizes into it. But those buffers will never change out of the software´s own volition. At least not before the awakening of Skynet :-)
So forget SOLID, forget µServices, forget messaging, RabbitMQ or whatever your pet principles and technologies might be. Regardless of how much you apply them to software, the software itself will not become antifragile. Not even if you purposely (or accidentally) build a god class :-)
Enter the human
Since we cannot (yet) build anything material that´s alive, we need to incorporate something that´s alive already, if we want to achieve Antifragility. Enter the human.
If we include one or more humans into the picture, we actually can build living systems, ie. systems with the Antifragility property. Before were just technical systems, now it´s social systems.
Not every social system is alive of course. Take the people sitting on a bus. They form a social system, but I would have a hard time to call it autopoietic. There´s nothing holding those people together except a short term common destination (a bus stop). And even this destination does not cause the group of people to try to keep itself together in case the bus breaks down. Then they scatter and each passenger tries to reach his/her destination by some other means.
But if you put together people in order to achieve some goal, then the social system has a purpose – and it will try “to stay alive” until the goal is reached. Of course for this they need to be bestowed with sufficient autonomy.
I think a proper term for such a purpose oriented social system would be organization. A company is an organization, a team is an organization.
An organization like any other system has buffers. It can withstand certain stresses. But above that it is capable of extending its buffers, if it feels that would help its survival towards fulfilling its purpose. That´s what autonomy is for – at least in part.
“Dead” systems, i.e. purely material systems (including software) usually deteriorate under stress – some faster, some slower. At best they might be able to repair themselves: If a buffer got damaged they can bring it back to its original capacity. But then they don´t decide to do this; that´s what “just happens”. That´s how they are built, that´s an automatic response to damage, it´s a reflex.
“Dead” systems however don´t deliberate over buffer extension. They don´t learn. They don´t anticipate, assess risks, and as a result direct effort this way or that to increase buffer capacity to counter future stresses.
Let´s be realistic: that´s the material systems (including software) we´re building. Maybe in some lab mad scientists are doing better than that ;-), but I´d say that´s of no relevance to the current Antifragility discussion.
Software as a tool
If we want to build antifragile systems we´re stuck with humans. Antifragility “build to order” requires a social system. So how does software fit into the picture?
What´s the purpose of a software development team? It´s to help the customer respectively the users to satisfy some needs easier than without it. The customer for example says: “I want to get rich quick by offering an auction service to millions of people.” The customer then would be happy to accept any (!) solution, be that software or a bunch of people writing letters or trained ants. As it happens, though, software (plus hardware, of course) seems make it easier than training ants to reach this goal :-) That´s the only reason the “solution team” will deliver software to the customer. Software thus is just a tool. It´s not a purpose, it´s not a goal, it´s a tool fitting a job at a specific moment.
Of course, a software team would have a hard time delivering something other than software. That way software looks larger than a tool, it looks like a goal, even a purpose. But it is not. It is just a tool, which a software team builds to get its job “Make the life of the users easier” done.
I don´t want to belittle what developing software means. It´s a tough job. Software is complex. Nevertheless it´s just a tool.
On the other hand this view makes it easier to see how Antifragility and software go together. Since software is a tool, it can help or hinder Antifragility. A tool is a buffer. A tool has buffers. These buffers of cause serve Antifragility like any other buffers of a system.
So instead of saying, software should become antifragile – which it cannot. We should say, the socio-technical system consisting of humans plus software should become antifragile. A software company, a software team as organizations can have the property of Antifragility – or they can lack it.
A software producing organization can come under pressure. All sorts of buffers then can be deployed to withstand the stress. And afterwards the organization can decide to increase all sorts of buffers to cope with future stress in an even better way.
µServices or an OR mapper or SOLID or event sourcing are certain approaches to build software. They might help to make its buffers larger. Thus they would help the overall robustness of the organization building the software. But the software itself stays a tool. The software won´t become antifragile through them. Antifragility needs deliberation.
Robustness of any order of a software is just the foundation of Antifragility. It can build on it, because robustness helps survival. It´s not Antifragility, though. That´s Nassim Taleb´s point. Antifragility emerges only if there is some form of consciousness at play. Stress and buffer depletion need to be observed and assessed. Then decisions as to how to deal with the resulting state of buffers have to be taken. Attention has to be directed to some, and withdrawn from others. And energy has to be channeled to some to repair them or even increase them. Which on the other hand means, energy has to be withdrawn from others. That´s why buffers shrink.
Shrinking buffers are a passive effect of energy directed elsewhere. Buffers are rarely actively deconstructed. Rather they atrophy due to lack of attention and energy. That´s what´s happening when you focus your attention on the rearview mirror while driving. You might be increasing your buffer with regard to approaching cars – but at the same time the buffer between your car and the roadside might shrink, because you diverted your attention from looking ahead and steering.
If you want to be serious about Antifragility as a property of a socio-technical system, then you have to be serious about values, strategy, reflection, efficient decision making, autonomy, and accountability. There´s no Antifragility without them. Because Antifragility is about learning, and liviing. Software is just a tool, and technologies and technical principles can only buy you buffer capacity. But who´s to decide where to direct attention and energy to? Who´s to decide which buffers to increase as a result to stress? That requires human intelligence.
First and foremost Antifragility is about people.
That´s why I suggest to drop the #antifragilesoftware in favor of something more realistic like #antifragilityinsoftwaredevelopment. Ok, that´s a tad long. So maybe #antifragileteams?