How Complex Systems Fail

Highlights from How Complex Systems Fail:

• Title) How Failure is Attributed to Proximate Cause
• 1) It is the presence of these hazards that drives the creation of defenses against hazard that characterize these systems
• 2) multiple layers of defense
• 3) Catastrophe requires multiple failures
• 4) Eradication of all latent failures is limited primarily by economic cost but also because it is difficult before the fact to see how such failures might contribute to an accident
• 5) complex systems run as broken systems
• 5) The system continues to function because it contains so many redundancies and because people can make it function, despite the presence of many flaws
• 6) It is impossible to eliminate the potential for such catastrophic failure
• 7) Post-accident attribution accident to a ‘root cause’ is fundamentally wrong
• 7) There are multiple contributors to accidents
• 7) social, cultural need to blame specific, localized forces or events for outcomes
• 8) Knowledge of the outcome makes it seem that events leading to the outcome should have appeared more salient to practitioners at the time than was actually the case
• 8)  It seems that practitioners “should have known”
• 9) dual roles
• 9) Outsiders rarely acknowledge the duality of this role
• 11) After an accident, practitioner actions may be regarded as ‘errors’ or ‘violations’
• 11) biased by hindsight and ignore the other driving forces, especially production pressure
• 13) Human expertise in complex systems is constantly changing
• 13) need to replace experts who leave
• 14) Change introduces new forms of failure
• 14) overt: open and observable
• 14) use of new technology
• 14) decrease the number of low consequence but high frequency failures
• 14) create opportunities for new, low frequency but high consequence failures
• 14) Not uncommonly, these new, rare catastrophes have even greater impact than those eliminated by the new technology
• 14) hard to see the contribution of technology to the failure
• What to do? Freeze a system from all and any change?
• 15) post-accident remedies usually increase the coupling and complexity
• 16) Safety is a characteristic of systems and not of their components
• 18) Failure free operations require experience with failure
• "Game day" and failure injection

Learning vi: mental notes

Though I use vi here and there for several years now, there's always some new trick to learn.
Lately I've had on my desk the book Learning the vi editor by Linda Lamb, published by O'Reilly.

Here I list, in no particular order, some notes as a way to reinforce what I've learned from the book. The focus is on things that called my attention, were new to me and/or that were not internalized yet in my day-to-day usage.


vi versus/and ex

ZZ = save and exit = :wq (ex command)
:e! = reload from disk
~ = toggle case
xp = transpose two characters

0 = go to beginning of line (same as ^)
W = move to the beginning of the next word, ignoring punctuation
B = move to the beginning of the previous word, ignoring punctuation
e = move to the end of the next word
E = move to the end of the next word, ignoring punctuation

. = repeat last command
Y = yy
P = put text before cursor
D = d$
C = c$
X = delete character before cursor
cc = change line = ddO = 0D
"3p = put contents of buffer number 3 (not the last buffer)
U = undo all edits on a single line
A = append at the end of the line
I = insert at the beginning of the line
s = c+space = xi = substitute character
S = cc = substitute line

50i* = insert 50 times *

ea = append to the end of a word
J = join consecutive lines

Quick and easy statistics with Python 3

Today I discovered that Python 3 (starting with 3.4) includes a new module in the standard library: statistics!

The full docs: https://docs.python.org/3/library/statistics.html

It is a useful library for quick explorations in the terminal. Fire an iPython shell, gather some data in a list, e.g. k, and then:

In [8]: import statistics

In [9]: statistics.mean(k)

Out[9]: 354.2944444444444

In [10]: statistics.stdev(k)

Out[10]: 29.47088274648779

Profit!

Go Exceptions: An Introduction

Estimated reading time: 12 seconds.

Table of Contents

•  

[this section intentionally left blank]

Summing Up

Unlike many other languages, there are no exceptions in the Go programming language.

---

This post was inspired by the much lengthier Python Exceptions: An Introduction.