Designing anything often involves breaking a situation into a finite number of cases and defining the software’s behavior in those cases. These are my views on two general kinds of cases.
A Corner Case
- Your UI asks the user to enter their name.
- The user enters “Ryu & Cammi”
Yes, I know someone who does this. He enters both his name and his wife’s name separated by “&”.
This is a corner case.
I admit it’s unlikely, but it is a real-world scenario. Probably a more common reason is that the user entered their company’s name (such as “Fitch & Mather”).
Often products will not handle cases like this well. Maybe the UI will throw a warning dialog, and forbid the user from proceeding. Maybe application will lose part of the string after the “&” character. That’s the wrong behavior. It’s rude to your customers; it doesn’t respect them.
I do not claim that support every corner case is critical. However, it is worth your time to explore the corner cases. At the very least decide early how your product will handle those cases instead of getting caught later in the development cycle. Later it will be too expensive and destabilizing to fix the behavior.
The Contrived Case
Contrived cases are cases that one as *composed* for the purpose of causing failure.
Common traits of contrived cases:
– Aren’t tied to the customer scenario or the customer’s reality
– Often depend on the existing of a customer behavior that is designed to break the product
– Are possible in theory but do not present themselves in practice
The Invisible Car
Akuma and Ryu are about to cross the street. Akuma looks in both directions to check for traffic.
Ryu: How do you know it’s safe to cross the street?
Akuma: I just looked both ways! I can’t see any cars at all.
Ryu: Sure, but what if the car was invisible?
Yes, in theory we are at risk from invisible cars. Cars aren’t invisible. This is a contrived case.
The renamed DLL
Imagine someone reported that your application failed on startup. He tells you that he deleted the foo.dll upon which the application depends and then launches the application. The application did not start. It just silently failed to load. He suggests that the application should continue to load and provide a meaningful error.
This is a contrived case. The desire for the application to give a warning is, by itself, reasonable. Who objects to good error-handling? The scenario is contrived because it involves a user deliberately sabotaging the product. Furthermore, this is not a situation into which one can easily arrive. The user must to take series of steps to make this occur. Why cater to such behavior?
Decide, don’t guess
It might be hard to tell the difference between corner cases and contrived cases. I don’t believe a strict rule is possible, but my guidance is this: base your decisions in your scenarios, talk to your customers, and get data if possible. At least make a decision with some solid thinking behind it. Don’t ignore it and don’t guess.