Hacker News Reader

Comment by gklitt | Hacker News Reader

The conclusion of the article reminds me of the idea behind blameless postmortems for system outages. Human mistakes are inevitable, and it's our responsibility to design resilient systems that acknowledge that simple fact.

While software engineering is an immature discipline in many ways, blameless postmortems seem like a counterexample -- they're a well-known best practice in software that don't seem as common in some other fields.

View on HN

Most vehicle collisions are not blameless though. They are caused by inattentive people; I've almost been hit multiple times by people either on their cell phone, or chatting with a passenger in their vehicle.

Other times drivers are purposely driving with a priority on agressivenss over safety.

If we ever get to a state of zero traffic fatalities then maybe blameless post-mortems would make sense. But there's too much blatantly bad behavior occuring.

It would be as if a pilot crashed buzzing the control tower. Clearly a human operator was being reckless and deserves punishment.

If you acknowledge that people are inherently inattentive or malicious then you can design a system that protects people even when someone is to blame.

Such a system probably wouldn't include people driving automobiles?

I think blameless post mortem works where you can take time and improve in the future. A more established process from the 80s coming from Toshiba is 5 whys, which is not exactly blameless (you do end up finding the issue), but the blame is usually on the process that needs fixing. The accident in that case is just the initial step and educating the drivers to notice the cyclist would not end up as the solution. Which I do like: people will keep making mistakes - either stop them or make the mistake obvious before it leads to the accident - punishing that driver may make us feel better but it won't improve the situation.

Reply on news.ycombinator.com