Software Resiliency

I just finished skimming a few books on software development and engineering and sat back for a moment to ponder what I had just read.  Ok, maybe that's not totally true. I was actually pondering whether I should drink a beer so late in the day when I had to get up early for work the next day.  But this isn't lost on my diatribe either.  

I thought about how years ago this wouldn't have been anything to "ponder" at all.  I would have consumed a six-pack and still been at the job site at 5:00 am ready to go.  Adding this thought into the blender with my previous thoughts about software engineering - I concocted an epiphany.  Holy cow!  I got to use that word in a sentence!

What I realized was that the most significant gain we have made in software engineering is indeed resilience.  Or should I say resiliency?  The accummulation of years of bug fixes, and design flaws that have tripped up so many home users, small office users and enterprise IT departments, and ultimately cost us enormous losses of time and money trying to either fix them or work our way around them.  Even when the decisions were made to switch race horses and pick an entirely different product or vendor, it cost us even more.  Switching gears like that is always costly.

Indeed, resiliency has resulted from a variety of reasons.  The Internet has been hugely to blame.  How else could we have achieved the automated processes we have become accustomed for self-updating our products, detecting "out of date" versions and online diagnostics?  Even if we internalize those with centralized autonomy (think WSUS), we still need an umbilical cord to the source in order to keep our base reference "fresh" and reliable.  But aside from having an avenue like that, we also have the software itself.

Granted, the most irritatingly cumbersome issue with product self-updating mechanisms is that they're almost always proprietary.  Beyond that, they also tend to take their own paths to a solution.  There's little similarity between them and that leads to redundancy that impacts our systems and productivity.  Having each vendor, not to mention vendor-products, employ their own unique services overhead for ensuring product reliability, drains our systems of precious RAM and CPU cycles.  It depletes our network pipes as well.  Past attempts to homogenize these disperate pathways seem to have fallen apart (think BigFix and a few others).

Microsoft has stepped in to build some very nicely paved roads in this regard.  In fact, they have done an outstanding job at building nicely constructed highways for logical services management.  However, they have been handicapped by legislative and litigative constraint.  Arguably this is a good thing, as it may prevent a grossely monopolistic environment.  However, like the demise of old "Ma Bell", the result is often less than ideal for the customer.

Somehow, in spite of all the heterogenious pursuits, the economic difficulties, and the legal entanglements, we are now enjoying the fruits of nearly two decades of unwittingly ambitious efforts to make our software resilient.  Maybe it was intended to reduce technical support costs. Maybe it was to impress customers.  Maybe it was a side effect of streamlining product suites to leverage symbiotic benefits.  Maybe it was just a good idea that snowballed slowly.   I would guess that it's a combination of all of these and then some.  Whatever the reason, it is truly amazing how far we've come with delivering on our expectations for software that "takes care of itself".

Sure, it's not quite there yet, but if you remember working with DOS, or early UNIX, or Windows 3.x or OS/2, you should understand where I'm coming from within a few minutes of fond recollection of the good ole days.  They weren't that good.  Software may not be as exciting to discover as it once was, but it sure has matured to become more reliable and self-sufficient.  Resiliency is a good thing.