I have the feeling that a lot of developers disregard corner and edge cases. Often they tend to just ignore these.

I was once working on a logistics project. In the order management of the application there was a case where about 5-10% of the orders had to be specially handled. One colleague said that we just shouldn't handle that case automatically, which would have lead to a high manual workload of the applications users. I think this has somewhat to do with a bad attitude.

Another example I noticed shortly was in a comment to one of my answers here. Since this was just a comment, I think the reason for that was just, that the commentator did not pay too much attention for it.

Have you made similar experiences? Is this something you see very often? Is this just a matter of attitude or are there other reasons?

1 Answer 1


The cost is one of the reasons.

When you're implementing a feature which is used by half of your 1 000 000 users, it means that the cost of the feature is divided by 500 000. Even if implementing it is terribly expensive, it doesn't matter. If this feature costs you $100 000, each user will pay ten cents, given that only half of the users will pay for the feature they don't use.

When, on the other hand, a feature is used only by a few of your users, not only it doesn't worth to implement it, but often, you will even stop supporting an existent one and remove it from the product. This is what happens often in Microsoft products: when you read that a feature, used by thousands of users, was discontinued in the next version of Windows, it is easy to understand: maintaining a codebase used by only a few thousands of users is too expensive for a product with so many customers.

The same applies to bugs. If 1% of your users are encountering a bug, it may be too expensive to solve it. The less costly way would be to refund those users, and never hear from them again.

The second reason is that it is difficult to find the edge cases.

An example. I was recently working on a standardization of username/password authentication for my company.

  • One way was to do it in the same way as it is done by Microsoft, PayPal and others: the bad way. In other words, you don't really care about the edge cases, and try to circumvent them by having passwords with the maximum length of 16 characters, etc.

    Those companies know that most users will use a password such as "horse123", and will never experience any problem. On the other hand, I with my 25-characters randomly generated passwords, can't access my Microsoft account from Windows 8 Metro apps done by Microsoft itself, and I can't access my PayPal account, unless I manually tweak the password to be actually different from the one I used when registering.

    But they really don't care, because I'm different from 99.9% of users.

  • The other way is to try to find all the edge cases. For example, if you want to support any unicode character in a password, you should know that some characters may have multiple unicode representations, and while the user will believe that he enters the same password, your app will reply that the password is sometimes right, sometimes wrong, depending on the unicode form. In the same way, some characters should be forbidden: if the system allows \u0014, for example, bad things will happen (like Internet Explorer 10 hanging for 30 seconds when submitting a form with a password containing such characters).

In general, it comes to what is more convenient to do business-wise.

  • You can spend the next few months searching for edge cases,

  • or you can implement three or four cool features in your product.

Ask your boss what should you do among those two options.

  • Thanks for pointing me more towards the business/management view. Didn't had that in mind. Oct 3, 2012 at 19:17

Not the answer you're looking for? Browse other questions tagged or ask your own question.