The term corner case is used in software programming conversations. Another common term is edge case. Definitions tend to vary, but the former includes problems encountered outside of normally expected parameters or usage. The latter includes problems discovered when pushing a known boundary. Although similar, a common observation is these types of problems or bugs usually are not found during basic testing by the developers or engineers. They are discovered by other people.
I have been writing scripts for many years. I am always astounded when I beat a script to death with testing and then days, weeks, months, and sometimes years later a unique or new condition appears that exposes a problem with the script.
The unique or new condition usually is a new or unanticipated usage case. Sometimes a simple environment condition narrows or expands to expose the flaw. Corner and edge cases appear the moment different people are involved. Many times when coding for other people I thought I had done a good job. The moment other people got involved testing or using the code they discovered problems. Everybody thinks and acts just a bit differently from others and this trait of human nature is what exposes the problems.
Free/libre software suffers from a lot of corner and edge cases, something often called paper cuts. The expression is rooted in the old adage of “Death by a thousand paper cuts.” The adage implies that a single paper cut is annoying but not threatening. A thousand paper cuts might cause sufficient blood loss to be threatening.
Likewise with use cases and expectations. While many coders are skilled to cover common use cases, those corner and edge cases tend to slip through the proverbial cracks. Further, a significant amount of free/libre code suffers because testing is limited to fellow geeks and technical enthusiasts.
The moment non technical users are introduced to the code the proverbial Hell breaks loose. Non technical users think differently than geeks and enthusiasts. The latter are willing to get dirty finger nails to make things work. More often than not that is the end of the discussion among such users.
Non technical users are different. Except in emergencies they are unwilling to get dirty. They expect point-and-click and they treat computers like appliances.
Without non technical users being involved, software is usable but not polished. Without polish software does not become popular or gets tagged as “not ready for prime time.”
The legendary Year of the Linux Desktop could happen quickly, but only with developers bringing non technical users into the fold.