Velocity 2012: Richard Cook, "How Complex Systems Fail"

except every single good thing we have is built upon failure. got a gsm phone? broadband? how about a modem? a pc? basic chemistry? cryptography? the very notion of cryptography is embracing the failure of having private data leaked. did you know 802.11 was initially made for infrared? do you remember how much it sucked? maybe if would have progressed faster if it was out in the wild faster. that's how it's progressing now. yeah, you may not like it. and every now and then I hear the idea that "when you're dealing with critical things, like healthcare where someone's life may depend on it, you cannot afford failure". except that's not true. those systems actually embrace failure more than anything else. google reliability engineering.or look at this: [LINK] there is a nice talk on failure from richard cook at the velocity conf: [VIDEO]

The field is called "Operations Research". I had the pleasure of meeting Dr Cook in the speaker lounge right before he gave this keynote at Velocity 2012: [VIDEO]

Richards Cooks How complex systems fail from velocity a couple of years ago [VIDEO] and the paper that's the basis for it is also nice to have handy [LINK]

> We should probably be doing modelling and formal verification and stuff like that. This is interesting. Is this a hypothetical notion or can you share any personal experience of having worked on any projects where this is done successfully? I bring this up because there is typically a narrow band of applicability of purely theoretical constructs in most complex systems (AWS & Azure teams both use formal methods [1] to find bugs and to increase confidence in critical algorithms but I don't believe they do this system-wide. Also the verification is only done on the abstraction, not the actual implementation.). Richard Cook gave a talk on "How Complex Systems Fail" [2] which addresses this point, and advocates for designing for resiliency as opposed to designing to exhaustively handle all failure modes (which are impossible to predict). Design people often design from some idealized notion of inputs and/or worst case scenarios. Ops people know what can go wrong will go wrong, which is why ops is there to handle the deviations from the norm. Real world design exposes lift points, reveals controls and supports continuous maintenance. Highly reliable systems are evolved, not just designed. [1] [LINK] [2] [VIDEO]

To build on this discussion, what are some highlights in that book that you found useful? I ask because I've read some systems thinking books (e.g. Systemantics) that were difficult to apply in real life. I come from the perspective of someone with a systems/theory builder personality. The only systems thinking book that I found remotely practical was The Fifth Discipline by Peter Senge. The most useful piece of short writing on systems thinking that I've come across is "How Complex Systems Fail" [1, 2], which talks about designing systems for resiliency, and not for rigid notions of reliability. [1] "How Complex Systems Fail" [LINK] [2] Its accompanying O'Reilly conference talk [VIDEO]

The accompanying talk by Richard I Cook at the O'Reilly Velocity conference is here: [VIDEO] When I worked in operations, I would watch this talk every couple of months to remind myself of the principles. The principles are summarized in the list, but the talk adds a bit more context. I find that this context matters for seeing how the principles might be applied.

Huh? See [LINK] and watch [VIDEO] The "chain analogy" is just that i.e. a Metaphor. You need to map it to your studies in Systems Science and Complexity Science . Start with the works of Henry Petroski. Then look at the works of Nassim Taleb , in particular Antifragile . Finally, do a search for "Failure in Complex Systems" and you get tons of journal articles one of which i have listed above.