-
A while ago I gave a little lightning talk on patterns of anti-fragility for web developers. In a way, such anti-fragility patterns are the things we may already know, but framed into an interesting triad of concepts. It’s about how we can build better and more robust code, using a minimal set of higher-order ideas about what such code should be like.
Generally, my thoughts on this are based on my personal experience in web development using Python and someone else’s definition of anti-fragile software may differ from mine.
Nassim Taleb in his “Antifragile: Things That Gain From Disorder” offers a good foundation, which we may use as an instrument for thinking about the future things that may affect us. This approach is universal, Talleb propagates it from fininacial world into other domains. Naturally, one of such domains is software engineering.
In simple words, the main idea is that *predicting specific future” is a wrong path. And predictions are usually wrong. And sometimes even if rely on prediction that is 80% true, relying on such prediction is still capable of causing a wave of bad consequences.
A simpler, yet more systemic approach, would be not to prepare for *specific* kind of future, but to be *generally* more prepared. For software that is to build code that is not excessively specific and capable of handling some future changes or at least not acting as an obstacle for them.
So, here my definitions of Talleb’s robust/fragile/anti-fragile concept triad for software engineering the way I see it.
Robust.
Robust is something that is true in any case, in kind of future.
In programming, we can add some simple things that can make our product robust.
Logging info/errors,
Adding unit tests,
Writing documentation
Building a micro-tool to automate workflow (using pip, django logging, unittest library, sphinx docs)
Adding properties to JSON (sorry for too diverse examples)
Adding classes that system can’t live without, and add other classes only as a last resort
These are all examples of activities that make our software more robust at almost zero expense. Understanding that the above is a list of pretty general items, I’d take a risk to state that a particular project can have a number of slightly more specific robust things than above, that can be added to it and bring benefits without bringing more complexity.
Anti-fragile.
When part of your project is extensible to a certain degree and is capable of rather getting better with time, than worse, we may call it anti-fragile. There is no 100% anti-fragile except robust, but if some solution/function/package is good enough, we may call it anti-fragile. Think in terms of tendency, ask yourself “Can it become better?”, anti-fragile code has intertia of developing in the right direction.
I think the items below can be put into anti-fragile category:
Adding a library to support a single feature, not tightly coupled to other parts of project.
Horizontal scaling (e.g. building a system that can add machines to cope with growing load)
Using composition instead of inheritance
Fragile.
Porting application to a different ORM
Decisions that exchange features for stability.
Adding code not covered with tests
Writing non-idiomatic code, implicit dependencies
Vague boundary conditions in code
I think this triad of robust/fragile/anti-fragile concepts can be helpful to beginner/intermediate developers to group diverse definitions of good code into something more meaningful. It would be also interesting to find more specific examples of these patterns in Python development which I plan to do in the nearest future. Any examples would be really appreciated.