Anti-fragile software
By David Vallejo Fernandez (University Professor).
Taleb tells, in his book Antifragile, who things are classified into three columns: brittle, robust, and antifragile. Fragile things love peace of mind and are easy to break, like a fine crystal glass at a New Year's Eve celebration. The robust, or resilient, things withstand shocks when some turbulence arises and maintain their status, like the small business that diversifies and maintains a large client base. Anti-fragile things go further than robust things, and even benefit from uncertainty, risk or volatility, just like mother nature. Taleb offers a very visual example, drawing on Greek mythology, to understand the difference between these three qualities. Damocles is a fragile character, since it is only a matter of time until the horse hair that holds the sword above his head breaks and ends his life. The Phoenix bird is a robust creature, because it is capable of being reborn from its ashes when it dies. The Hydra, a mythological being in the shape of a serpent with many heads, benefited from negative situations, since every time a head was cut off, two new ones were born.
interesting reflect on this classification in the context of software. Software development is a complex process, where the number of existing interdependencies is high, sometimes even difficult to detect, and the appearance of an error or bug can cause non-linear responses. Unfortunately, we humans have a hard time understanding nonlinearity, as we tend to think in linear terms. If the manifestation of a bug in a computer system generates a 10% decrease in its functionality, the appearance of two bugs, related or not, could generate an effect much greater, or much less, than double the initial effect (that is, say, double that 10%).
El fragile software, like Damocles, lives waiting for a failure that will inevitably appear. Fragile software is the enemy of time. In the same way that the public debt of a country weakens it when it comes to negotiating with its partners, the interests derived from a software with technical debt will cause, in the long term, higher maintenance costs. The entropy of the software will increase as its maintenance becomes more complex, impacting an initial design that has to be modified eventually.
El robust software, on the other hand, is designed considering that it must face the passage of time and that, at the same time, it must respond adequately to the presence of errors. Testing and code debugging are the go-to techniques for increasing software robustness. Dijkstra stated that if debugging is the process of removing bugs from software, then programming must be the process of introducing them. Bug-free code does not exist. We cannot predict when they will manifest with undesirable consequences. Sometimes robust is not robust enough, and it is very difficult, if not impossible, to estimate the probability and impact associated with a possible software failure. Risk management offers a false sense of security.
Considering the nature of antifragility, the creation of antifragile software would benefit from the introduction of stressors or random elements. The philosophy of release early, release often, popularized by Eric S. Raymond in his essay The Cathedral and the Bazaar and inspired by the Linux kernel development model, fits this idea. Not all software cathedrals must be built in a perfectly orchestrated way. The bazaar is dynamic, bustling, ever-changing, and full of merchants with different approaches and individual goals. Having users from the beginning increases the progress of a development shaped progressively through a random use of the software, improving the quality of the final result. This philosophy, which eliminates the risk of creating software that nobody ends up using, is one of the principles of the Open Source. Software open source it evolves thanks to the collaborative effort of its programmers, and it stands the test of time as long as it continues to provide real value to its users.
