Cascio on Resilience vs. Sustainability

Check out Jamais Cascio’s direct (and very short) exposition of an important distinction between sustainability and resilience.

Sustainability is inherently static. It presumes there’s a point at which we can maintain ourselves and the world, and once we find the right combination of behavior and technology that allows us some measure of stability…Resilience, conversely, accepts that change is inevitable and in many cases out of our hands, focusing instead on the need to be able to withstand the unexpected.

– from The Next Big Thing: Resilience By Jamais Cascio

He lists some of the key attributes or values to honor when designing resilient systems: diversity, redundancy, decentralization, collaboration, transparency, graceful failure, flexibility, and foresight.

I often interact with people who are very attached to “getting it right” or at least to how others are “getting it wrong.” Getting it right is great; and I thoroughly enjoy the moments when I do. But a winning strategy is knowing what to do when you get it wrong.  “If you want to increase your success rate, double your failure rate.” (Tom Watson) doesn’t just mean failing is okay, or even that the statistics are constant so endure the failures. It means you develop the ability to work off of the failures, understand the world through them and change the way you go at things.

One of the items in the list, fail gracefully, is a concept found in software development. Exception frameworks are common in most useful software languages and provide a mechanism for the developer to create a graceful path to failure for situations that are never supposed to happen like diving by zero, or addressing memory that doesn’t exist.  This idea has increased the usability of software many times over.

Also in software development practice, we have gone through a change of emphasis from foresight toward flexibility.  In software project management practices of 10 years ago, it was common to attempt to specify all details of a software project up front.  This ignored the inevitable education that comes from building a system and interacting with it over time.  Many software teams have moved to agile development methods–allowing later specification and more flexibility in the direction of software products as they are being built.  The potential problem with foresight is that seeing the future isn’t useful, it is the danger of committing to a particular (necessarily narrow) future and losing flexibility.

My experience pars with Cascio’s observations.  How to move these ideas into local community planning, city planning,  power grid evolution, communications grid evolution and other vital systems?