Black Swans in Software Engineering

What is the relationship between the Black Swan logic proposed by Nassim Taleb and Software Engineering ?

Books and technical content are good, they help us keep our knowledge up to date, but also I like to reflect on standards and concepts proposed by authors who do not are directly linked to the technology and study whether these concepts can be applied to specific areas of knowledge.

The Logic of the Black Swan, whose author is Nassim Taleb, seems to be in harmony with many events that we can observe in our reality, in the economy, in politics or even in how we develop software. If the subject is interesting and you want to find more information about the Black Swan Logic, the best source is The Black Swan book (in Amazon books or others stores).

Basically, the Black Swan Logic consists of a research related to highly improbable events, difficult, but occur and bring consequences together. Positive or negative. Does anyone else see resemblance to critical bugs that only reveal themselves in production environments? Although such events are highly improbable and difficult to predict, it is common and routine that people making such predictions and conveying the message that they have all the knowledge determine the future.

We have some basic examples only for the context of this article.

The financial crisis that began in the US in 2008 (Negative)

Big Wall Street investors, economics experts, real estate experts, big investment banks and even the US government itself sailed in calm waters with an accelerated economy and lots of dollars circling, everything seemed good to everyone until … Boommm !!!

Maybe a few months earlier, some people were already aware of details to wait for the crisis, but a crisis like 2008 does not occur in a few months, is the sum of many related variables for some years. At the beginning of the process, it is impossible to predict. After unlikely events occur all possible explanations.

The popularity of personal computers (Positive)

The technological giants of the 1970s and early 1980s ridiculed the idea that computers could be accessible to many people like television or radio. However, due to several unexpected events by the renowned experts of the time, in the spontaneous action of the market and consumers, today computers are in the hands of people everywhere.

The Black Swan Logic reveals our arrogance

How often when writing software with bad code, developers along with project managers consider that the most important thing is to deliver the code (big and complex) ready for production and make a profit? After all, everything was documented and combined with the customer and with the business areas and the entire team was very knowledgeable, nothing could go wrong.

Even worse, how often developers blame analysts because a complex and packed implementation of different possibilities has not been sufficiently documented, although the analyst has to make a large and complete document.

It seems clear that the problem was not specifically the developers, nor the analysts, nor the managers and even less the client. The problem was that in designing a comprehensive, complex, multi-variable system to build this system within a short and absurd time frame, an enabling environment for an event of Black Swan. The critical bug that can cost a lot of dollars/euros, the code that turns an indomitable monster and that generates more cost for maintenance than for optimization of new functionalities, illegible code which makes the team lose productivity.

The Black Swan Logic states that events of this nature are unpredictable because they are complex and have many related variables. An event that departs from this characteristic is the one that has simple nature or at least as simple as possible. If there is a large and complex smaller and simpler deliveries, we gradually learn to eliminate the chances of Black Swans.

However, this is not just about using agile methodologies and their various ways of delivering value quickly, more important than this is to code with the thought of eliminating large complexities.

* It is not helpful if the Scrum Master has full dedication to the most efficient agile method ifof the code do 7 things and are impossible to test.

* It is not helpful if code methods are simple and do specific things if the developerexpects completion of 12 methods, 5 classes and 2 configuration files to send all this complexityto the repository and receive conflicts that will require more time.

* Application architectures distributed in microservices are not advantageous just because they give resilience to a project, but also because they separate in smaller problems and with less complexity the parts of the application.

Developing software is about solving problems, we can not and do not want to get away from it. But if problems exist to be solved, it is best that we can do without creating new and more complex ones.