Beyond 'Foolproof': Smart Error Handling in Software Design

The power of language cannot be overstated. Choosing the right words is crucial, but avoiding inappropriate ones is equally, if not more, important. Take, for instance, the term "foolproof," often used to describe software applications designed to withstand incorrect user input. This term creates the implication that users are fools – a notion that's both disrespectful and counterproductive to good business practices. In reality, if an application can fail due to user actions, the fool is not the user, but the developer who failed to anticipate and handle potential errors.

Let me give you a few examples of applications that did not handle incorrect data effectively and some examples where correct data was blocked.

Doing a scan of our database before a PCI audit, we were shocked to find a couple of 16 digit numbers that appeared to be unencrypted credit card numbers. This was a shock as we were confident that we had handled encryption correctly. On closer examination, these were in the name field. Two people had entered their credit card numbers in the name field. We should have ensured that data entered into the name field was not all numeric (preventing any numeric input, which blocks people who have "3rd in their name).

In another role we had a web form that required users to enter their SSN. We did not block them from entering any nine-digit number. But we would raise an exception on the backend if the SSN was not in a valid format. Users who did not wish to share their SSN frequently entered all zeros. Our exception system was flooded by reports of invalid SSN, making it hard to spot exceptions on which we could take action.

SQL injection can be a problem. The correct way to handle it is to sanitize on the back end. The incorrect way is to be overzealous on the front end and prevent people from using special characters. I have had to quickly fix a system that stopped users from having apostrophes in their names, excluding many Irish people from registering on our platform.

In April 1996, AOL's profanity filter prevented residents of the town of Scunthorpe, England from creating AOL accounts because the town's name contained a rude word. This bug resulted in the blocking of online content due to the presence of obscene substrings being named “The Scunthorpe Problem”.

The responsibility for creating robust, user-friendly applications lies squarely with developers and designers. Rather than labeling systems as "foolproof," we should strive for "error-resistant" or "user-friendly" designs that anticipate and gracefully handle a wide range of inputs.