Applying Antifragility to Computer Code

The concept of antifragility is well-established by Dr. Taleb and has even been adopted by the mainstream to some extent (e.g. in Investopedia). This is a vast concept and it’s unlikely that I can do it justice, especially in a blog post. That’s why I suggest you familiarize yourself with it first before reading the rest of this article.

Antifragility is not only desirable but also essential to some extent, particularly when it comes to data science / AI work. Even though most data models are antifragile by nature (particularly the more sophisticated ones that manage to get every drop of signal from the data they are given), there are fragilities all over the place when it comes to how these models are used. A clear example of this is the computer code around them. I’m not referring to the code that’s used to implement them, usually coming from some specialized packages. That code is fine and usually better than most code found in data science / AI projects. The code around the models, however, be it the one taking care of ETL work, feature engineering, and even data visualization, may not always be good enough.

Antifragility applies to computer code in various ways. Here are the ones I’ve found so far:

1. Modular code, particularly in the form of independent functions. There is a reason functional languages are so popular. The fact that they seem to grow stronger the larger and more complex the projects get is a sign of their antifragility. However, you can employ modular code in any programming language, even OOP ones, for your data science / AI projects.
   
2. Comments, lots of comments. That’s not to say that you need to have a comment for every line of code, but the more comments you have that are useful to the user/reviewer, the better. Just imagine that you’ve forgotten about that program for some reason (say you had an amnesia episode). Would you be able to understand the code in it, without having to spend lots of time deciphering it? If not, then you probably need to add more comments.
   
3. At least one example showcasing the code. You may do that using a demo within the script file or, even better, by creating a Jupyter notebook of a particular use case where the code is employed. Naturally, if you have comments there too, along with headings and other organizational elements, that would make for a more antifragile situation.
   
4. Trying to break the code by attacking its vulnerabilities. This is often done in a professional setting (there are people who do this as their job) and is linked to unit testing. Every program has bugs, particularly in the first stages of its development. Finding those bugs may seem like a fragile situation but with the right attitude (e.g. a total quality management approach to it), these fragilities can be remedied and the program can be made more stable. So, as a process, this is a form of antifragility.
   

All this may seem like a lot of work and it may not agree with your temporal restrictions, particularly if you have strict deadlines. However, you can always improve on your code after you’ve cleared a milestone. This way, you can avoid some Black Swans like an error being thrown while the program you’ve made is already in production. Cheers!