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.