Exceptional exceptions
I should have known something interesting would happen today when I read my horoscope[1]:
Chug along as planned. Circumstances might create a series of minor emergencies that interrupt your routine. Remain fluid about plans.
Today I had a bizarre ATM experience. The machine gobbled my deposit envelope but kept beeping and prompting me to deposit the deposit envelope in the slot. But I had already made my deposit! So after 30 seconds of incessant beeping I pressed the cancel button. The beeping didn’t stop. I calmly walked inside spoke to a teller (we could hear the beeping inside the bank). She walked outside, looked at the screen, and followed instructions inserting an empty deposit envelope. The ATM then ejected my card and a receipt that indicated my transaction had been canceled. But the machine still had my deposit envelope.
After a short consultation, a more senior teller took over. She opened the back of the ATM, opened the deposit box, and sorted through the envelopes. My deposit envelope wasn’t there. She closed the machine (meanwhile as she was doing this someone else successfully made a deposit that landed in the deposit box). She went inside, consulted someone in a back office, made a phone call and then spoke with me. She had reached someone who she said was “a little unreasonable”. They suggested I file a dispute and then they would schedule a technician to search for my missing deposit envelope lost inside the machine. Meanwhile she rechecked the deposit box, took my name and phone number and said she would resolve this today. And she did. A technician came out, popped open the front panel of the ATM, and found my deposit envelope clinging to the top of the dispenser in a way that allowed other envelopes to slide over my envelope and drop into the deposit box.
My thanks and gratitude goes out to that persistent teller. Without her my deposit would still be in limbo.
What about the ATM? Could it have worked better? How could it have handled this really exceptional case? I am guessing that my envelope never was sensed (otherwise, how could the deposit slot still be waiting to accept an envelope). It was in limbo. But beeping a long time while displaying the “insert your deposit envelope in the deposit slot” didn’t help me out. Those instructions didn’t apply to me! The fact that a teller could insert a blank deposit envelope meant the deposit slot was working; the next depositor’s actions confirmed that. But somehow my deposit envelope hadn’t been recognized by the machine.
What about the behavior of cancel? Cancel didn’t mean immediately cancel. The machine kept incessantly beeping, demanding that an envelope be deposited. I was too stunned to know what it wanted. Even if I had figured out what it wanted, I don’t think putting in a blank envelope would’ve been a good thing to do. I can imagine the bank then claiming that I’d deposited an empty envelope and I probably would have had to file a dispute. In hindsight, my actions were the right ones to take. If cancel had immediately ejected my card, things might have been better. There was something disconcerting about cancel not having an immediate effect, even though it led to me going inside to find smart people who eventually tracked down the problem. It seems like a poor system design to have cancel wait until a hardware initiated action was complete. This could’ve been a result of poorly designed hardware. I just don’t know enough to say.
If cancel had been immediate, my card and a canceled deposit transaction would’ve been ejected. I still would’ve had to deal with the missing deposit envelope. But I suspect the story I told the teller wouldn’t have been so compelling.
The teller said that after a certain amount of beeping the ATM would have canceled my transaction anyway and swallowed my card (so this leads me to believe that there is some ability for the system to time out if expected hardware actions don’t occur). I still suspect a software bug. If the ATM had swallowed my deposit envelope this way during non business hours I suspect I would’ve stood at the machine until it stopped beeping, which would’ve led me down the same path but with undoubtedly more trouble. Hm.
As someone who has written many use cases, I would have specified that cancel should be immediate and that user transaction’s abort as soon as the cancel key was pressed (unless the transaction was beyond canceling and then some indication of that failed response signaled to the user). And then I would’ve written tests to push on all the weird cases I could think of.
How cancel is detected, when it should take effect, and what should happen often fall into that gray unspecified area. Most use case descriptions ignore or say very little about canceling actions. Specifying cancel exception behavior doesn’t fit well neatly with tying exceptions to specific use case steps since cancel can happen at many different places (and across many different use cases). Aren’t use cases best when they describe business-level steps, not lower level implementation details? Sure, but sometimes it is important to specify these pesky interaction details that make your system be responsive or react predictably.
My advice: when you want to specify these things, start by writing statements that describe when cancel is enabled (and when it is not), when the software should detect it, what should happen, and what should not be allowed to happen. You may need to define invariants that must be preserved, describe detailed cancel actions, or develop state models. These descriptions, in addition to use cases can specify interaction design. It’s unrealistic to squeeze every little detail into a use case description.
Disclaimer: On the rare day that I read my horoscope I forget it by the time I’ve finished reading Dilbert and Doonesbury. But today’s horoscope was strange enough that I remembered it. ↩︎
- Previous: Customer service that works!
- Next: John Vlissides