The Antifragile Developer
Monday, 15.06.2020 - Antifragile, Barbell Strategy, Software Development, Software Engineering
What if you could benefit from stress, chaos and disorder?
The world out there is fast, interconnected and (especially these days) packed with uncertainty. Rare events happen quite more often than either anticipated or acknowledged. I’m speaking of such rare events which change the way you live your daily life. The downside or upside of such events depend highly on your current way of living.
The Fragile World We Live In
We are currently enduring such rare events. A pandemic followed by a global economic crisis. Granted, pandemics happen rarely. But they happened before. Economic crisis happen not as rarely as we think or we’re being told. Also, economic crisis happen on local scales as well. It could be a job loss caused by a change in an industry, change of customer behavior, competitors that won market share and your services aren’t able to compete anymore, the management was changed and things work differently now, legal changes,…
As software developers, we’re facing rare events as well. Events such as technical issues. Your service is disturbed by network issues (they really don’t happen that rarely), a service provider you’re relying on is down, a 3rd-party library you’re using introduced a severe bug, you yourself introduced a severe bug, the planned feature was completely underestimated and consumes a lot more time and resources (technical and financial resources), the platform you’d like to distribute your app on might reject your app because it does not implement certain platform-specific features,… Just to name a few.
What if we could benefit from such rare events? Can we at least protect us from the downside? Even introduce an upside we could benefit from?
The last months I’ve been working through Nassim Taleb’s Incerto Series. It took me a while and I’m still not completely done as they are not books one reads in just one go. At least not me. Every few paragraphs I had to stop and think about what I read. Not because the topics were hard to digest, but because of different viewpoints, ideas, thought patterns, etc. I picked up. I highly recommend the series to anyone who’s interested in anything related to probability and uncertainty in daily life. You might not like his style, though. Be warned. But I do like it. So much so in fact, that I’m on the verge of getting the high priced Deluxe Edition. But that’s for another day.
The one book of the series which stood out to me the most was (and still is) Antifragile. If I could pick only one book to read for the rest of the year, it’s this.
Know What to Look For
So, Antifragile. What is it? In short, the opposite of fragile. Obvious, isn’t it? Well, not so fast.
“Some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty. Yet, in spite of the ubiquity of the phenomenon, there is no word for the exact opposite of fragile. Let us call it antifragile. Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better.”
This word didn’t exist a couple of years ago. If I’d been asked “what is the opposite of fragile?” a couple of months ago, I probably would have answered: “robust”. But it’s wrong.
In situations of stress, chaos or disorder
- fragile things lose
- robust things are indifferent
- antifragile things gain
See? Robust can’t be the opposite of fragile, as it doesn’t behave the opposite way under the same circumstances.
With this in mind, we already have plenty of food for thought to examine the systems we have built or are currently building as software developers and how they behave in daily life situations, especially under shocks.
What we build as software developers, what we build as companies, how companies are built, how systems in general are built and behave in different situations. We can even view ourseleves and our positions, roles, skills, believes, etc. as systems and examine how each system performs in daily life under volatility.
What systems we identified are fragile? Does the fragilty of a system mean ruin under situations of stress? If so, can we avoid ruin? What do we need to do, so they become robust or at least less fragile and won’t lead to ruin anymore? Can we even create systems which benefit from shocks?
Before our systems or we ourselves can become antifragile, the systems need to become robust. There are probably different ways to build antifragile systems. But to me, the most intuitive one is to first avoid anything leading to potential ruin. Nassim Taleb mentions the Barbell strategy a few times. Once explained and understood, it makes sense how this strategy can potentially lead to antifragility.
In finance, a barbell strategy is formed when a trader invests in long and short duration bonds, but does not invest in Intermediate duration bonds. This strategy is useful when interest rates are rising; as the short term maturities are rolled over they receive a higher interest rate, raising the value. Taleb generalizes the phenomenon and applies it to other domains. Essentially it is the transformation of anything from fragile to antifragile.
A dual strategy, a combination of two extremes, one safe and one speculative, deemed more robust than a “monomodal” strategy; often a necessary condition for antifragility. For instance, in biological systems, the equivalent of marrying an accountant (stable life) and having an occasional fling with a rock star (good fun); for a writer, getting a stable sinecure and writing without the pressures of the market during spare time. Even trial and error are a form of barbell.
Meaning quite simply, if most, say 95%, of your systems are robust and are indifferent towards shocks, you can tinker with the other 5% of your systems. Provided, none of it leads to ruin. This part is important. The downside needs to be small and limited.
While 95% of your systems are robust and keep you going no matter what, you can focus on things with limited downside and potentially unlimited upside. Then, use the potential payoffs to get you ahead.
Becoming an Antifragile Developer
Much of my daily life I spend with developing software. So, naturally, I’ve started to apply the Barbell strategy and search for ways to make systems more robust at first, and maybe even antifragile eventually.
Actually, it’s not something I’ve just started. But I do it differently now. More deliberately. More effective. Many of us working in tech probably experienced fragility first-hand at some point in their carrer. A service or website going down because of network errors, hardware failure, bugs, a wrong command, a faulty SQL statement in a migration, and the bells of alarm start to ring. We already know about fragility and robustness. Intuitively and from experience. But the concepts of antifragility, the resulting thought patterns, frameworks and strategies give us new words and viewpoints to talk about.
We can challenge believes from a different perspective.
I can analyze systems and try to understand how it, or some of the parts its made of (subsystems) behave under volatility (e.g. stress, chaos, disorder, uncertainty). Is it fragile, robust, or antifragile? Understanding a systems characteristics, I can then challenge how the systems currently are built. What part needs to be rebuild. What needs to be added, or removed. Or even challenge its existence as a whole.
Walk Before You Run
Let’s make this concrete for a moment. Take this website. Websites can be built in various ways. Many different components can be involved, such as servers or databases, services for authentication, analytics, handling images, services to import data from different sources, build artifacts, backups,… But this website is a very simple blog with static content. I write the content and publish it. I don’t need most of the services listed above. It’s just a Phoenix application which reads Markdown files from disk at build time. Much in the same way as described by Jòse Valim in this blog post. It allows me to abandon a complex system such as databases. My backup system is a GitHub repository and a Docker image (which I can rebuild from scratch). The pages are mostly precompiled and served with little effort and low operational costs. This allows for a robust system which doesn’t really suffer under stress (e.g. high amount of concurrent requests). Granted, publishing new content with this system is not for everyone. To publish new content, you’d know which commands to run to compile, release and deploy a new version. But it’s the baseline for a robust system. From here on out, I could use the Barbell strategy and aim to make the publishing process more user friendly. 95% of the system should stay the same, with the remaining 5% I’d try to tinker with and find a way to reach the goal.
One might ask: “If you wanted to make your blog robust, why did you pick such a
young language and ecosystem such as Elixir? Isn’t it prone to be fragile?”.
Well, yes and no. Elixir is the 5%-part of my current Barbell strategy of my
professional carrer. More on that shortly. But why does it not increase
fragility in this case? Let’s examine again what this blog is made of mostly.
Broadly speaking, it’s a couple HTML tags (plus little framework specific
template syntax) and some CSS. The content (what you’re reading now) is
stored in separate Markdown files. Parsing Markdown and putting it in an HTML
div can be done with many programming languages today. If I had to decide
writing one of the biggest ecosystems regarding websites), I could do so
probably within a day. So, betting on Elixir would not ruin me even if it
turned out to be a failure. Right now, it’s actually doing the opposite
Making myself robust is another task I’d quickly aim for.
The Robust Self - Learning to walk
Searching for Antifragility
It turned out to be quite a robust system so far, even with all going on right now (the pandemic, the market downturn). But it’s not antifragile and probably never will be. But being robust gives me opportunities to play on other fields.
Therefore, my current 5% is learning Elixir, its ecosystem, and learning more of the business side of software. Especially the last part may lead to systems which benefit from shocks.