Monday, January 25, 2010

Lessons on Human Error, Re-learned Once Again

On a recent trip I had an experience showing the foolishness of trusting in human rationality.  After checking in to my hotel, I got to my room, and could not unlock the door.  It was the usual insert-magnetic-card lock, but when I did so either nothing happened, or it clicked quietly and a little red LED flashed.

I determined there were two possible answers: first, the card was bad; and second, the battery in the door reader was weak.  I returned to the desk, got new cards, and tried again.  Same failure mode with both cards.  While I was standing there despondently inserting the cards one after another, hoping things would change and I wouldn't have to trudge back downstairs and ask for another room, a hotel maintenance man came by, asked what the problem was, took one of the cards, and immediately opened the door.

What had happened?  As an external observer, you can probably guess, but I'll tell it in order, so you can see where things went wrong.

First, I had trouble locating the motel. It's on the northwest corner of an intersection, and I didn't know what it looked like.  I followed the GPS woman's advice to turn onto the side street, but saw nothing that resembled a Motel 6.  I looped around the blook and approached from the other direction, at which point I could see the sign and the driveway (which was invisible and inaccessible from the side street).  This left me disgruntled.

Second, on arriving I was miffed to notice that I would have to pay extra for internet access during my stay.  Another negative, in this case attributed to the hotel itself.

Third, when juggling my luggage at the front desk, I put the keycard in my shirt pocket with my phone, remembering only as I approached the door a rumor that the docking hardware on the Motorola Droid could affect magnetic card strips.

At this point, I was pre-disposed to think poorly of the motel, and had reason to believe the card I'd been given wouldn't work.  That it didn't simply confirmed my predisposition.  When I went back, the desk manager reprogrammed my card, and gave me a second "just in case", strengthening my hypothesis that the cards were likely to be faulty.

I blame the fourth contributing factor most of all.  Here is a photo of the front and back of the card:

 


As you can see, the most important piece of information the card has to convey is that Domino's is the recommended local restaurant, and its number  is helpfully provided in large type.  Now, when holding such a card up in front of you to read it, you would naturally place your thumb on the white part, just below the number.  When inserting it into the reader, you'll keep holding it that way.

Unless you want the door to open.  Then, apparently, you are to understand that the two-millimeter triangles on either side of the fine print (which warns of minimum pizza purchase requirements and that the drivers carry little cash) are not merely decoration, but are intended to tell you the direction in which the card is to be inserted.

The maintenance man, being familiar with the cards, immediately opened the door.  I had formed a hypothesis, and the outcomes of my experiments were consistent with that hypothesis, so I stuck with it.  The possibility of trying a different experiment, like turning the card around, didn't even occur to me.

Review: Rationality is strongly influenced by mood.  People, having formed an  opinion, will tend to see the evidence that supports it.  In the absence of inconsistent evidence, people will rarely actively search for an alternative  interpretation that contradicts their beliefs.  And input from an external party can disrupt the bad perspective, leading to better understanding.

None of this is news.  See, for example, James Reason, Human Error.  Relevance?

Well, it has clear relevance to most activities related to design and implementation of complex systems.  In particular, I have a new task to ensure high reliability in software used in a wireless sensor and control network.  What my experience has suggested is that, at a minimum, code reviews should be required for all changes that will go into a release of this software.

The process support for how we go about doing that is another essay.

No comments:

Post a Comment