Taleb says that fragility of the parts facilitates antifragility of the holon, that destruction of smaller parts creates strength at higher orders. It follows that in software systems, it is crucial that components are built to be disposable; fragile in that they can easily be replaced. The volatility within a codebase counterintuitively creates a stable system whole, because parts can be changed easily to respond to new requirements. We do not care for antifragility of classes, pipelines, service buses, even design patterns. They should be disposable. We care instead for whole system antifragility. If a pipeline needs to change for the system’s benefit, it should be easy to do so, this means each time the system is required to change, to step up, it does so because we are less tied to legacy decisions that no longer fit. It also means that when better design ideas are brought forth, they can be integrated. The system evolves, improving each time; it benefits from the volatility.
I recently worked on part of a system which was very much indisposable; entangled tightly with other parts and crucial to system operation. It served as a perfect example of the above because changes made to this system broke other (not originally apparent) behaviour and delayed the release cycle. The subsystem had been built as though it was a first class citizen; it was of the highest importance that it worked. Little consideration had been given to what impact this had on surrounding parts when it inevitably needed to change. By changing this subsystem we destabilised the greater whole: by breaking disparate components, by reducing QA confidence, by trying to get it to fit a mould it was not built for. If this part had been built, not with its own importance in mind, but with the greater system’s, then system stability would have remained intact. Rather than fit the change into the extant part, we could have reimplemented the part from the ground up, or extended it more elegantly via some builder mechanism.