Not the Happy Path or I am a Hi-Lo

I was at a local tester meeting tonight.  Tons of fun and a great conversation.  There was a student from a local college attending.  In the course of the discussion we were discussing the dangers of trusting the "happy path."  The student asked, "What do you mean by that?"

So, we explained about looking only for what "worked" and not investigating other issues that were more problematic and probably more error-prone.  In the midst of this, a story from over 20 years ago flooded back into my memory.

Mind you, it influenced me greatly at the time.  It led me to some of my early revelations of software, development, testing and "revealed truth."

When the IBM PC AT was state of the art, I worked as a developer (programmer) for a small manufacturer that had its own warehouses and distribution center for its finished product.  The company was a family run company located in fairly old buildings, well, from the late 1800's and early 1900's.  One individual was the nemesis of the software development folks. 

He was in charge of the warehouse - both finished products and component pieces.  Any sofftware running on machines in the warehouse had to be run past him for approval.  These were scattered around the varous floors of the warehouses.  Now, these warehouses were monsters.  Support posts were massive beams, 24"x24".  The PCs were usually located near a beam. 

The very old warehouses had a very small amount of leeway for placing pallets and the like.  Placing a case or pallet even a few inches away from where it was supposed to be could cause a fair amount of problems for the hi-lo operators moving material from one area to another. 

The curious bit was that at least once a week, a h-lo would hit (referred to as "bump") a support beam.  This was usually result from navigating away from mis-placed pallets.  Sometimes it was simply the operator missing a turn.  Once in a while, they'd hit the power conduit that powered a PC on an early network connection.  Once in a great while, they'd "take out" the PC itself.  Oops.

Back to my story. 

This same nemisis of software developemtn was finicky.  Extremely finicky.  He wanted to make sure that any data entered could be retrieved under any circumstnace.  If the user hit "enter" or "save" he had the expectation that the data would be fully retrievable.

His favorite tactic during demonstrations where changes or enhancements were being demonstrated, was to have the demonstrator enter components or finished part information.  He'd sometimes have the demonstrator repeat the process.  In the middle of the repeat, after clicking "save" or going to the next page, he'd say "I'm a hi-lo." and unplug the power cord. 

He'd count 20 and plug it back in. 

Then he'd sit down next to the demonstrator and say "Show me what you just entered."

If you couldn't, he refused to accept the change until it could pass his "test." 

How much work is it for your users to recover their work after a "that will never happen" event?