Beyond Agile: Antifragility for Software Development
Unpredictable, even damaging events occur frequently in agile software projects. In Part 2 of his article dealing with Antifragility, Gerrit Beine looks at the options we have when it comes to agility.
The first written occurrence of options can be found in Aristotle’s Politics. This anecdote is about Thales of Miletus, a Greek philosopher and mathematician. The relevant part of the story starts with a discussion between Thales and some of his friends. These friends had reached a certain degree of wealth. In their view, Thales was not able to reach their level of wealth and because of this, they question why he should be a philosopher. Thales proved them wrong.
The whole region around Miletus thrived from the harvesting of olives and production of olive oil. Thales made a contract with all the owners of olive presses in the region around Miletus. This contract offered him the prerogative to use the olive presses during the harvest season for a little compensation. During this harvest season Thales used his privilege to sublet the olive presses and earn a certain amount of money from the venture.
Aristotle, who wrote Thales’ story, underlined a gross misjudgement: He supposed that Thales’ success was founded on his knowledge regarding the prosperous olive harvest season. But it was exactly this knowledge that was completely irrelevant for Thales. The only relevant aspect was the asymmetrical design of the contract Thales made with the owners of the olive presses. As the olive harvest was a future event, Thales was, in the best case, able to make use of some indications, but not of certain, fact-based knowledge. Knowledge regarding future events is always on the 2OI. Aristotle missed the core of the story, like many people after him.
What Thales really did was to create an option (the privilege to make preferred use of the olive presses) as an insurance against his ignorance (the success of the olive harvest season). The price to pay for this option was little, the possible return was high. Thales recognised the principle of the asymmetry of options and the possibility of using them to deal with ignorance.
How can the Thales example of contracting for the privilege to use olive presses be transferred to software development? The answer to this question is to transfer the principle of asymmetry.
In Thales’ case it just so happened that he made use of very successful asymmetry: the gain (by subletting the olive presses) exceeded the possible losses (the compensation for the contract to get the privilege for using the olive presses) by quite a bit (Figure 1).
Thales limited his possible losses in the most absolute way. In the case of an unsuccessful harvest, he would only have to pay for the compensation of the privilege. His gains, however, were not limited, and he could sublet the olive presses at an arbitrary price, corresponding to demand. This asymmetry protected Thales against high losses and offered possible gains without any knowledge of the future event of the olive harvest. As mentioned before, future events are always 2OI. Thales accepted his inability to know about the future and uses asymmetry to create an option that allowed him to benefit from his ignorance.
Besides such successful asymmetry, based on the options we can see opposite examples, such as asymmetries based on an idea to secure gains as early as possible and thus eliminating options. This kind of asymmetry may lead to giant losses, much higher than the expected gains. An example of such asymmetry can be found in Thomas Mann’s Buddenbrooks, the so-called “Pöppenrader Harvest”. Tony Buddenbrook suggests to buy all wheat in the field prior to the harvest. His intention was to secure the gain of the later sale of the corn. But before the harvest, the wheat was destroyed by a storm (a Black Swan) and Tony’s family lost not only the money paid already for the wheat, but also the gains they expected. Their presumed securing of gains lead to their complete ruination (Figure 2).
In software projects many people act like Tony Buddenbrook. The above mentioned behaviour of taking the bull by the horns is nothing but an attempt to secure gains as early as possible. The reason for this behaviour is the pursuit of short-term rewards and the end result of doing something good for the project. However, preserving options in software development is a long-term rewarded activity and therefore less desirable. In addition, it’s not possible to differentiate afterwards if a problem with “The Requirement” occurred because of too many or to little facts. This perception requires some intensive research and most projects don’t have the time for this.
Yet, even this lack of time in software projects is a reason to preserve as many options as possible.
Agility and options
How can options be preserved in a software project that has strict constraints regarding budget and time? The answer is to avoid the behaviour described above. Software is a complex system and as such does not follow linear principles.
The performance topic may serve as an example I’ve met in every software project so far. As long as I can influence the requirements, I follow the principle of “first make it run, then make it fast”. According to this I slice and prioritise the requirements. When the functional requirement is ready, I collect feedback from users and delegate the decision regarding the system’s performance to them.
In most cases, the performance is satisfying (the experienced performance can be much better then the measured performance) and my team don’t need to work on the “make it fast” part of the requirement. It’s a gain for the whole project as the team can focus on the next requirement. Besides, this spares all project stakeholders regarding the discussion if customers and users should be able to specify concrete performance requirements. Often, they are not able to do this. Performance is on the 2OI until real people work with real software.
Often, I met developers telling me that this way of prioritising requirements is nonsense. The common argument always follows the same scheme. If one does it right in the beginning, a lot of effort would be saved afterwards. Sometimes, this is true, but not in the majority of the cases. The performance optimisation of software usually leads to an increase in its complexity.
Complexity causes effort whose estimation is a problem of the 2OI. If it’s not possible to estimate that effort, it’s quite hard to calculate how it’s been saved. Therefore, the supposed saving of future effort is not a valid argument to give up options. But other than that, such a statement cannot be falsified and is therefore not a valid argument.
Additionally, it’s not sure if the accomplishment of this effort is really necessary. This is definitely a question on the 2OI. In such cases, it’s a better idea to follow Thales instead of Tony Buddenbrook. Keeping the option of “then make it fast” is more desirable then giving up the option of “first make it run”.
Even though this case uses the simple example of performance it is possible to adopt the principle behind it to deal with many other non-functional requirements which have an impact on the complexity of software. And it is usable for functional requirements, too.
On the road to antifragility
The principle of antifragility describes a system that will not be harmed or destroyed by a Black Swan but benefit from it (Figure 3). Antifragility benefits from options and avoids the linear forecast of future events. Insofar, Thales acted in terms of antifragility while Tony Buddenbrook did the opposite.
Since Taleb’s book became available, a number of documents have been written regarding the question of how software needs to be designed to be antifragile. Advocates of microservices see microservices as an implementation of antifragile software architecture. But it becomes clear that this is not the case when Taleb says “Technology is inherently fragile”; software as a technology cannot be antifragile by itself.
Software can suffice the principle of antifragility only in combination with its process of development – exactly in the case when options have been preserved during development. Such a perspective enforces a mindshift while planning a software project or during the design of software architecture. These jobs need to change into the direction of managing and keeping options.
This preserving of options will be a major challenge for software architects in the future. The continuous development of software leads inevitably to a constant loss of options as every new feature, every new module creates facts and complexity. In the future, software architects and project managers need to think more about the question of when will be last possible time to make a decision and less with the decision itself.