Your customer is not the corner case: you are.
In general parlance the term ‘corner case’ is used to refer to an unusual situation. More formally, it’s a state defined by all the state’s variables being at their extremes. In other words, everything that could go wrong, goes wrong. Or ‘right’ if you’re in an optimistic frame of mind. So, for example, the Challenger disaster probably would not have happened if the air temperature hadn’t been so low and the wind hadn’t been blowing in the worst possible direction. The combination of the two led to a corner case that was outside the experience of those involved.
When developing software, it’s very easy to consider our interaction with our products to be the norm. In fact, if we could somehow measure the way people use the products we are developing we would find that we are very much a corner case user. It is a rare developer indeed that manages to come even close to replicating the usage of his end users. The bizarre things that users do and the utterly baffling thought processes that lead them to their ineffable decisions are normal and to be expected. Very few of your users will deliberately interact with your software in a manner designed to cause it pain. Some of your users will misinterpret your intentions with delightfully comic consequences. Some of them will occasionally encounter a ‘senior moment’ in an otherwise perfectly sensible work week. And some of them will just naturally exude weapons grade stupidity. This is the natural way of the world. Accept it and embrace it. But understand that it is not the way that you will interact with your software.
Perhaps the main reason for this discrepancy is that, as developers, we have intimate knowledge of the internals of the product. To our end users, however, the product is a black box. Or at least it should be. If it isn’t, you may want to revisit your design… Now, we may make conscious efforts to avoid using this insider knowledge. If we’re vigilant and determined we can often address certain assumptions from the perspective of the user. For example, users may not be aware that spaces are not allowed in logins in your application. We can look at the code and spot that potential error and test and adjust appropriately. In theory, given sufficient time and effort, we can make a reasonable stab at covering most of the bases.
This rather misses the point though. The user is approaching the software in a fundamentally different way. For the user, these assumptions are a purely passive occurrence. They happen not because of a rational analysis of the underlying code, but rather as a result of intuition and experience in other, similar or dissimilar, situations. The wide ranging nature of those experiences leads to a correspondingly wide range of responses.
Now, clued up users may well be familiar with some apps not allowing spaces in passwords and as a result they may avoid using them in your app. Less experienced users, however, might wonder what’s so special about spaces that precludes them from a password. And they would be quite right to wonder this. It’s truly bizarre to restrict passwords in this way. It’s rooted in lazy design and ancient history. Today’s software should just work in the frame of reference that is most familiar to most users. There’s no excuse for arcane incantations on the desktop any more. They’re only acceptable to those of us living at the corners but unfortunately we’re the only ones who can stop requiring them of the rest of the world.