This past week I received a great practical example of how not to design a system. Because of my recent stroke, changes are happening in my life. One of those is diet. Another is physical activity, the “exercise” word. That has prompted me to join a “gym”, specifically LA Fitness. That experience has provided me with my latest example of how not to do technology.
As I joined, they wanted my checking account number so they could autodraft my account each month for my dues. I got no problem with that but they wanted a check. I can provide my bank routing numbers. I can provide my checking account number. But a real check? I don’t use checks. I’ve never ordered any. So I just dropped by my bank on my next trip and had them quickly imprint a “counter check”. Should work.
Then I dropped by LA Fitness to make my initial payment and get the process started. Alas, as part of their automation processs they installed MICR readers on each desk. And rather than TYPE the numbers they “scan” the check. Alas for some reason UNKNOWN … my check would not scan. It was … for the process of getting me signed up … a catastrophic event. The sign up could not proceed. There was no apparent override (or at least they didn’t know about one). The failure of this technology step, the inability of the MICR Reader on the desk of the salesman was about to trash the sale.
Long story short, I went back to the bank, got a new check, went back to LA Fitness, and by then, they had figured out that maybe they didn’t have to use the MICR Reader anyway. But the experience once again showed the prevalent technology issue: Exception Processing: what to do when things go wrong.
Every new computer programmer learns this: 10% of the program is about doing things right … 90% of the program is about checking for and processing errors. Unfortunately, even as computer programmers learn this they forget that human/non-computer systems also have errors. Like what happens when the MICR reader won’t read the MICR code.
I know why they use the technology to read the MICR. It reduces errors. It reduces mis-typed bank numbers and account numbers. But they didn’t address what to do when that fails.
And for this customer, telling me to go away and come back with another check seems like the wrong answer.