Shortlog - a log of everyday things

Home

2010-11-07

Daylight Saving Time is about to end. Prepare for your second 1am. I do wish that the US would get rid of the whole Daylight Savings Time nonsense, but I suspect that kinda falls into the same realm of likelihood as getting people to use ISO8601 timestamps and [SI units] (http://en.wikipedia.org/wiki/International_System_of_Units).

Why am I against Daylight Saving Time existing at all?

The more you know.

Bruce Schneier on TSA absurdity: "A terrorist attack cannot possibly destroy our contry's way of life; it's only our reaction to that attack that can do that kind of damage." I have the utmost respect for Schneier, one of the most eminent security experts in the world. I think he's completely right.

Schneier hits on a very interesting problem: that when something negative happens, everyone wants something do be done about it. They want to see responsive action being taken. I'd like to make a case for the argument that that's not always the right response to the problem. (I'm not going to try to defend it for the specific case of terrorism; Schneier does a fine job of that.)

Why not? The existence of a problem means that something should have been handled differently, right? Perhaps, for a given case, something could have been done differently to avoid the mistake. The question is: at what cost? The concept of diminishing returns (as well as the impossibility of perfection) applies to a great many fields. The most correct or efficient action could be to take no action at all. While a great many failures would benefit from corrective action, I think people too often get so caught up in the iterative refinement process that they stop thinking about the efficacy of continued effort. In the end, some things are going to break. Accidents will happen. Deal.

An analogy to computer science is the concept of system reliability through component failure. Redundant components can reduce the risk of losing system operability, but everything is expressed in terms of Mean Time To Failure and Mean Time To Data Loss. We know that eventually, redundancy efforts be damned, stuff is going to break. We can extend that time to an acceptable level. And then we operate with that accepted risk. Another parallel is the concept of servicability - rather than trying to completely prevent failure (which is extraordinarily costly), we design systems that can cope with failure, and have failed components replaced even while the system remains online. It's not perfect, but it's more efficient than trying to solve the problem in the wrong manner.

Another important point is that due to our human irrationality, we are extraordinarily poor at gauging when we should be taking such action. (Can you tell that I can't get enough of Dan Ariely's work?) When people suffer the consequences of a failure, they lose trust in a system that they assumed would protect them from such failures. Perhaps this is an issue of how we present these systems to the public - it's a great marketing ploy to show off some technology as "risk-free," or "guaranteeing safety." It's wildly comforting to our ears, and readily opens our wallets, but these terms come back to haunt us when the claims in question are shown to be false. People lose the faith they had in a system they were convinced was perfect - and then they want to see that system modified so that it is perfect, so they can have that faith back. The problem is the premise: the expectation that a system or service or product will be without fault is flawed, but our society has come to accept it as fact. False advertising has long effects.

In summary: yes, many failures deserve action to prevent future failures of the same type, but we seek such action more often than is wise.