anti-fragile software

I recently watched a video of Nassim Taleb in which he explains the difference between anti-fragility and robustness in terms of economics and nature. A short explanation is that "anti-fragile" describes something that benefits from mistreatment as opposed to "robust" which describes something that can survive or tolerate mistreatment.

After thinking about this, I realized a big problem with software development is that we expend tremendous energy trying to make systems robust, but seem to give little or no thought to making them anti-fragile. To counter this problem, I thought I'd share a few ideas on how to make software development more anti-fragile.

#1 Embrace the idea that unexpected results can often be positive experiences. "Bugs" should be a thing of the past and should simply be observations about what the system does instead of an indictment of how poorly someone has implemented some other person's idea of how the software should function.

#2 Create a culture around facilitating change instead of trying to restrict it. Instead of having a "Change Management Process" or a "Change Control Process", have a "Change facilitation process". The focus should be on getting changes done, NOT restricting them.

#3 Avoid unecessary monocultures. Anybody with a lawn knows how difficult it is to keep out "non-grass" plants (otherwise known as weeds). In the same note, expending effort to keep every server and every desktop on the exact same platform is more effort than can ever be recouped. At runtime, it doesn't matter if your system uses ruby, python, linux, windows, and z Series, it just matters that it works and all the pieces can work together.

These are just a few ideas and as with any solution, there are negative consequences for attempting to pursue this path. What I wonder is, what other things can we do to make development more anti-fragile?

Comments

Unknown said…
Great post, this hits home big time. One of my frequent complaints about my new shop is the false expectation by development teams that the server environment in which everyone operates in never changes.

If you want to be agile in a growing environment, recognize the fact that changes to the operating system, database, storage and deployment strategies are going to happen with absolute certainty. We'll do our best to mitigate the risk but let's all work together to keep it simple, roll with the changes and communicate in a civil manner. The DEV vs OPs holy war won't end over night but we have to start somewhere.

Popular posts from this blog

Push versus pull deployment models

the myth of asynchronous JDBC

Installing virtualbox guest additions on Centos 7 minimal image