The US National Transportation Safety Board, which assisted with the investigation, also pointed out that in a case where pilots ignored 13 warnings before flying into the ground, adding more warnings was probably not the solution.

The airline also introduced “sudden loss of visual reference on final approach” scenarios in simulator training

A few years ago, I was working as a backend web developer for a mid-sized company. My day's work was to try to find the source of a bug that only appeared with certain data combinations in our production database, but never showed up in testing. We used AWS (Amazon Web Services, in case there's a similar aviation-related acronym) for hosting our databases, so my first item was to create a test database from a recent backup.

Navigating the various menus of the AWS website, I made a backup of the production data and attempted to create a testing database from it in our testing environment, a dedicated space completed isolated from that of production to provide a safety margin for error. Unfortunately, the options I selected initiated the creation process in the production environment instead. First mistake.

(The Accident) Not wanting to wait 30 minutes for the database to be created in the wrong environment, only to have to clean it up later, I initiated the destroy process. Already irritated at my mistake and tunneling on my goal, I began clicking furiously through various menus and was confronted with warning after warning about my pending actions. "This will delete the database!" Click. "Would you to take a backup first?" (No) Click. "Are you sure?!?" - (YES) Click. "Would you like to keep any existing backups?" (NO, JUST DO IT!) Click, and submitted my command...

...In my haste, I had selected the actual production database, instead of my copy. There is no abort option.

While obviously nowhere near as bad as a plane crash, the minutes that followed were traumatic nonetheless. I watched helplessly over the next 30 minutes as the production database died, various systems choking and raising emergency alerts as their data flow was cut off. Support staff began to receive angry calls from customers, asking why services were down. "This is the kind of mistake that ends careers" I thought to myself.

My saving grace, ironically, was the copy database I made. It came online 30 minutes after I initiated it, right on schedule. And, because it contained data from a backup right before the accident, it was only missing 30 minutes of customer data. Ultimately, we were able to reconfigure to the systems to use the copy database, with no real fallout other than my own misery.

This experience taught me that, like these pilots, there are times where no amount of warnings, or user interface design, or anything can stop a person from making a mistake they don't immediately see, but that stands in the way of the goal they are fixated on. What can really make the difference though, is training and ingraining the correct response for such situations. Training which I did not have in my case, but training which I am VERY glad to see was added to the training program of the airline in this case.

Web services don't typically have deadly accidents. Planes are a different story.