Building Antifragile Software
Imagine an application to run a business that is one method, 10,000 lines long. Worst thing in the world, right? Just thinking about such a think makes me shudder because you can look at it and know it's bad. But let's play with the idea a little bit.
So let's say the function of this application is to generate an invoice for a purchase with lots of line items. Cool, you may think if you like thinking about how software solves problems, an obvious thing that we could separate (to make this system a little more robust) is have the invoice built in two "phases". Phase 1 is preparing individual components (header, lines, footer) and then Phase 2 is composing them into an invoice.
Now you have a dramatically more robust system. You can fiddle with one part (say, the footer) feeling pretty safe that you are not going to change the "guts" of the invoice.
No problem there, let's go a little further - there is a huge variety to the type of line items on this invoice. Some are services (a gardener mowing your lawn), and some are goods in the more traditional sense (tacos). We could then break these things apart and have different types of line items generated by different pieces.
We're even better. Now we can change the taco acquisition code without worrying about the gardener.
Smaller pieces mean more robust programs. Robust programs are Good, and you should want to build software that is at least robust.
But Nassim Nicholas Taleb, in his (highly pompous on the order of magnitude of David Brooks teaching a course at Yale on humility by presenting to them the writings of David Brooks) recent book, Antifragility, argues that there's a step further that biological systems, networks, and a few other systems tend to have. Antifragility. A fragile item is one that hates (and is damaged by) change. A robust system tolerates change. An antifragile system thrives on change.
How can we make software more than just robust, then? How can we build "antifragile" software?
I've been considering this a lot recently, and will continue to do so, but I think that the first step (and something I've been studying aggressively recently) is building your software in small bits. Use small objects that do one thing. It's a truism that's taught in courses and books, but I've found that the PAIN that I have had to deal with while building systems where the parts were way too big is a much more effective teacher than the most eloquent writer or lecturer. Small bits make for robust software, as I mentioned above but I think that they can make for more "antifragile" software with the addition of a stressor - competition.
A critter that is antifragile in nature loves variation. Why? Because it can respond to the new conditions faster than the things with which is competing for resources. Every living thing is competing for resources all the time, and small advantages can have hugely nonlinear outcomes (a baseball star making hundreds of millions of dollars isn't really that much better in absolute terms than a minimum wage MLB player).
Properly object-oriented, SOLID, software can be adapted faster and better. Change your business requirements, and the software needs to change to adapt. The faster you can change your software, the better-equipped you are to deal with a volatile (and largely fragile) world.
I think that the next phase of antifragility comes from caching - the more of your data you can generate and "remember", the faster each subsequent request can become - but I think that for now, I'm going to let this digest.