March 2018
Volume 33 Number 3
[Don't Get Me Started]
This Is Not A Drill
By David Platt | March 2018
.jpg "David Platt")
You’ve no doubt heard about the false alarm on Jan. 13 that caused much of the state of Hawaii to duck and cover. Just what you need while evading the cold winter and enjoying a piña colada on the beach: a text shouting “BALLISTIC MISSILE THREAT INBOUND TO HAWAII. SEEK IMMEDIATE SHELTER. THIS IS NOT A DRILL.”
The alarm was false, of course. The investigation revealed that the employee who triggered the alert mistakenly thought the event was real and not a drill. But the incident brought to light something else: the sad state of the software used by the emergency management office.
You can see that terrible design in Figure 1, which news outlets say depicts the emergency management interface in use during the event. The official should have selected “DRILL – PACOM (CDW) – STATE ONLY,” the seventh link from the top, for the regular internal test that occurs on each shift. For whatever reason, the guy clicked on “PACOM (CDW) – STATE ONLY,” two links above it, triggering the real thing.
.png "The Alert Menu Screen Initially Provided by the Hawaii Governor’s Office")
Figure 1 The Alert Menu Screen Initially Provided by the Hawaii Governor’s Office
Of course there was a confirmation box: “Are you sure?” Like every user everywhere in the history of the universe, this user cruised right through on autopilot: “Yes.”
Oops.
Ideally we want software operations to be reversible. That’s fine for cutting and pasting text. But in the real world, we encounter operations that, by their very nature, are not reversible—ejecting from a fighter plane, say, or amputating a leg. This alert falls into that category. While the alert was eventually rescinded, the damage was done—to frightened tourists; to cardiac patients; to the confidence of the population; to the innocence of children; to stockpiles of premium booze, hastily chugged. How do we design applications to handle irreversible operations, preventing false alarms without impeding the real alarms?
First, we design for cognitive clarity. I can discern no pattern to the arrangement of the items in Figure 1, with test alerts and real ones randomly comingled. Try putting them on different sides of the page, in different tables, maybe in different colors. Consistency in nomenclature would help as well: What’s the difference between a drill and a demo test or a test message? Change the nomenclature to always use, say, DRILL and REAL.
Next, we design to avoid slips. A slip happens when the user doesn’t type or click as precisely as the application requires, thereby activating something he didn’t intend. That’s why we don’t put an ejection seat button right next to a radio button: an air pocket or a sneeze bumps the user’s finger half a centimeter too far, and kablooey!
You can see these ideas in the design of real ejection seats (ejectionsite.com). The trigger is on a separate handle and uniquely marked (cognitive clarity), located away from other controls, and triggered by a motion used for nothing else (slip prevention). Our irreversible apps should use similar techniques.
Now, what about the confirmation box? It’s supposed to make the user stop and think, but it never does. Ever. Anywhere. On anything. The user clicks “Yes” three times a day, and “No” essentially never, so the affirmation becomes automatic. Because this does not protect our expensive and dangerous irreversible operation, what would?
This operation is not split-second critical, as an ejection seat would be. There is time for another opinion, which the app should require: “Alice, I’m sending you a drill request.” “Bob, I’ve received your drill request and I’m authorizing it.” Perhaps require the users to type “drill” or “real” correctly, further differentiating the operations.
Similar multi-person control is required for launching these deadly missiles. Anyone wishing to explore further can read the book “Command and Control,” by Eric Schlosser (Penguin, 2013).
The application UI shown in Figure 1 would constitute gross negligence. If one of my students submitted a project like this, I’d flunk his sorry ass so fast he’d change his major to Sanskrit. To anyone who wants to see how easily these kinds of mistakes can escalate, I recommend “Fail Safe,” by Eugene Burdick and Harvey Wheeler (McGraw-Hill, 1962), with its shattering final chapter entitled “The Sacrifice of Abraham.”
As I wrote in my very first Don’t Get Me Started column in February 2010 (msdn.com/magazine/ee309884): “Humans are not going to stop being human any time soon, no matter how much you might wish they would evolve into something more logical. Good applications recognize this, and adjust to their human users, instead of hoping, futilely, for the opposite.” Do the missiles actually have to fly before we learn this lesson?
David S. Platt teaches programming .NET at Harvard University Extension School and at companies all over the world. He’s the author of 11 programming books, including “Why Software Sucks” (Addison-Wesley Professional, 2006) and “Introducing Microsoft .NET” (Microsoft Press, 2002). Microsoft named him a Software Legend in 2002. He wonders whether he should tape down two of his daughter’s fingers so she learns how to count in octal. You can contact him at rollthunder.com.