Rebellious users are a pain. Introducing a feature that changes the standard workflow is a harbinger of confused users and new help-desk tickets. Eventually, a user might stumble onto some workaround to avoid the new feature, and this workaround will then be passed down and changed via interoffice oral tradition. Ancient tribes that were present for the creation of the world 6,000 years ago passed down tales of the earth mother. We pass down keyboard shortcuts.

Jesse B. worked on banking software years ago. As banks control lots and lots of (other peoples') money, they make the rules. Jesse was entangled in maintenance of an application for tellers and retail banking clerks. His time was dedicated to customization and enhancement for a particular client bank.

Jesse's contact was Sherri, a liaison from the bank. She was great at distilling requirements and changes reported by the bank and communicating them in a way that developers would understand. Jesse had grown to enjoy their weekly meetings.

One week, though, Sherri brought up an issue that the bank had been experiencing. Note I didn't say "the users" — this issue existed bankwide. Sherri explained, "The totals are getting out of synch when the tellers cancel out of the cash counter dialog."

This was a big huge major gigantic horrible problem. This issue was affecting the running totals for tellers' activities during the day; cash in, cash out, checks in, traveler's checks sold, and so on. When these totals didn't add up correctly at the end of the day, it was a major priority to determine the problem. As such, Jesse dropped everything he was doing and began investigating immediately.

Jesse recalled Sherri's description of the issue: "The totals are getting out of synch when the tellers cancel out of the cash counter dialog." This dialog was a window that popped up after a transaction above a certain threshold, say $1,000. It worked much like the assignment that you probably had in CIS 101: it'd tell how much change was due in terms of each denomination (4 x $20 bills, 1 x $10 bills, 0 x quarters, 2 x dimes...) and asked tellers to enter the actual amount given. It was irritating for the users, but it was a requirement from the bank that helped prevent errors. In fact, the bank had required that all options for cancelling the window from appearing be removed; there could be no little "x" in the corner, no "Cancel," nothing.

Jesse was puzzled. There was no way for users to cancel the dialog, other than completing the transaction. He called Sherri and asked her to explain. "They're using control-alt-delete," she said matter-of-factly. After a few moments of silence, she continued, "we go into the task manager, in the 'Processes' screen, and cancel out of the cash counter dialog that way. It's quicker than filling out all the text boxes on the dialog."

To be clear, Jesse was serious about killing the process. After all, their software wasn't some rinkydink application that could be bothered to respond to "End Task" requests. No, the process had to be killed.

Jesse explained the gravity of users "cancelling the dialog" in this way; that it directly subverted the accounting measures by ending the application. She took the news in stride, though. "Oh, well maybe we should handle this as a training issue then."

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!