The first and most obvious reason is that it takes effort. Much like simplicity, antifragility requires recognition and to be valued in order for it to be applied. Otherwise any antifragility is serendipitous at best.
Antifragile falls at the other end of the spectrum from fragile, with 'robust' the mid-point of the triad. Fragile software is evident in every decision to abandon a legacy codebase as it's fragility prevents it adapting to new needs. Robust software is often high quality for yesterday's problems and will withstand some change, but will often end up resisting your change when you really need it. All the best techniques of the craftsman often lead to this high quality but resistant to change software.
Antifragile software has been designed, architected and is delivered in such a way as to thrive on change. Change here, even the unexpected, is seen as an advantage.
After looking carefully over my recent and past software products, fragile design hurt me, robust design meant someone had to be upset, but antifragile design, architecture and delivery process delivered satisfaction to all quarters.
The fact is that people do occasionally deliver antifragile software. You only have to look to companies that are innovating at pace with their software products, and often with few people, to see antifragility in action.
The first step to getting these gains is to understand and value antifragility.
For more information on Antifragility generally, the canonical book by Nassim Nicholas Taleb is the place to start.
For more on Antifragility in Software, that's what my book is all about and I expect to have a complete draft ready this week. If you can spare 3 days in London to learn about how to develop and evolve software faster than the competition, then my course at Skills Matter would be time well spent.
For help adopting antifragility in your own software, contact my team at Simplicity Itself.
RSS Feed
