Someone once mentioned that he enjoys reading my articles because they are to the point. The reason for that is because I often leave out edge cases. I will make statements such as βX is true rather than βX is true, except for A, B, C, D, and E. Also F in cases of G.β
The reason isnβt because the edge cases arenβt important. The reason is that they arenβt always necessary. Ever read an academic paper? Many people would consider them dry. Part of that is because an academic has to cover every single edge case. Every. Single. One.
If they donβt, if they miss anything, someone else will point it out and it will appear to discredit the whole paper. A Phd candidateβs thesis review is called a βdefense for a reason. Their paper is attacked from every possible angle to make sure they have covered everything.
Covering everything can be distracting though. I used to write like that. Then I received feedback from a writer that my writing was all over the place. It was unfocused. There were too many sentences and paragraphs that distracted the reader from the overall theme.
Writing something that everyone can enjoy reading requires making sure there is a good flow. Every paragraph should provide the setup for the next one. When edge cases help provide this setup, I include them. When edge cases break this flow, I leave them out.
The result is often lots of comments pointing out all the things I missed. Iβm ok with this. Sometimes Iβve thought of the edge case and I intentionally chose to leave it out. Sometimes I missed it and learned something from the comment. Regardless, I donβt worry about people pointing out that I missed things. My target audience isnβt someone who can point out the things I missed. My target audience is someone who needs a starting point from where they can learn to start pointing out the things I missed.
So how does any of this tie into software development?
Software developers are trained to think about edge cases. Itβs crucial in many of the things we do. All these security breaches that are plaguing us right now? Those are edge cases not properly accounted for.
But context is important here too. Security is like writing an academic paper: every single edge case has to be accounted for. The same is true for safety critical systems such as pacemakers or airplanes. The cost of not accounting for edge cases is extremely high and the consequences are dire.
Yet there are plenty of areas where taking edge cases into account can have a negative impact on a business and/or the user.
Take emails for example. Guess which of these emails are invalid:
- βJoe smithβ@example.com
- ββjoe\smithββ@example.com
- joe@[smith example].com
- Joe smith@example.com
Only the last one is actually an invalid email address. The others are perfectly fine according to the standards written for emails.
Who would actually use βjoe smithβ@example.com over joe.smith@example.com though? The first is a really confusing email to communicate to other people and itβs harder to remember. It doesnβt matter that it is a valid email address, it is a bad user experience. It also happens to be harder for developers to account for. Accounting for this edge case may benefit one or two people in the world, but would negatively impact the greater majority.
Another example is the feed feature in products like Facebook or Twitter. An infinite scrolling feed is a really great experience if all you care about is casually browsing for interesting posts. There is an edge case though for people who want to look for specific posts being made. This is best served by a paging implementation that youβll see in search engines like Google or Bing.
But paging is a poorer user experience for those who are casually browsing. Facebook and Twitter have optimized their feeds to be used a certain way, which happens to be the way most of their users like. Theyβve let go of the edge case of other uses.
Itβs important to think about edge cases. Developers are trained to do so in order to prevent critical errors. But this thought process should also include whether a given edge case actually needs to be accounted for. Trying to account for every edge case imaginable will result in software never getting shipped or software that loses its original purpose.
Top comments (1)
I would submit that if your code grows too many edge cases, itβs a sure sign youβre modelling the problem domain poorly, and you need to step back and attempt a refactoring.