Edge cases. You have to love them. It’s what will destroy your company and your employee’s morale. Chasing edge-cases can be a developers biggest pitfall if done in the wrong environment or their greatest strength if done in the right environment. How do you draw the balance and when? That’s what we’ll tackle in this article.

If you haven’t read my article on MVP software development, I encourage you to do so. It covers thinking in MVP terms, which we’ll cover throughout this article.

What is an Edge Case?

The best way that I can describe an edge-case in software development is when a user performs certain actions that lead to an undesirable outcome in the software that they’re using. For example, let’s say that we have an Add to Cart functionality. If the user follows through the steps as intended, they should arrive at the cart. However, if the user clicks on Logout and momentarily holds the Escape key while they click on the Add to Cart button, they may end up on a 404 page. This might be a bit of an over exaggeration, but I think I’ve driven the point across. Edge-cases just produce unintended consequences in the most obscure scenarios.

Is it an Edge Case or a Bug?

Technically, edge cases are bugs. However, what is the risk-to-reward ratio? How likely is it that the user will ever find this? And even if they do, how likely is it that this will impact business? That’s the question that development teams should be asking themselves when creating software. If the impact is low, and the steps to reproduce stray far away from normal user behavior, I would classify that as an edge case. If it’s normal user behavior that’s causing the disruption, I would classify that as a bug.

Set the bug-tolerance level with your client

Is your client going to be haunted at night by the edge-case that they found? Sometimes it’s worth fixing, however, seeking out edge-cases can be detrimental to your bottom line. The more you seek edge-cases, the more you’ll find them. At some point you have to ask yourself, does the client want for the software to be completed on time with certain edge-cases potentially looming in the software, or does the client want code that’s 100% perfect and time is not an issue?

I’ll tell you from experience that the client wants 100% perfect code and for it to be on time. It’s not a realistic expectation especially when the client doesn’t want to pay for the additional time and QA work. Even TDD, if you can get the client to pay for it, is not guaranteed to account for all the edge cases.

Quality QA

If your company takes the QA process seriously enough, you will have a few quality QA engineers that know how to not only smoke test the core functionality at the intended user level, but also how to seek out edge-cases. What happens if the user is visiting the web-application and decides to disable JavaScript. I know that nobody does this anymore (it’s just an example), but there are times when people try to get creative and disable JavaScript to disable paywalls on certain websites.

Quality QA engineers are there to help the developer out and to potentially make their life a living hell. QA engineers tend to go overboard on edge-cases to the point that it will frustrate the developers out of their job. Communicating with the QA engineers that specific edge-cases are okay to document, but not to demand their immediate fix, is something that should be done regularly.

Communication

Aside from speaking with the team about edge-cases, it’s important to communicate to your client about edge-cases from the beginning and set bug-tolerance expectations. There has to be some sort of understanding between the software development team and the client. Building software is a messy process. The more perfect you want it to become, the more resources it will take, and the more money it will cost.

Having a 30 to 90 day post launch testing period is also something that’s reasonable with most companies. Edge-cases that are found six months after the release of the product should require a new SOW. The client should have an understanding up front that there are other edge-cases lurking around the corner. The company cannot repair those indefinitely free-of-charge. If the edge-case was thought about during development, development time would have increased and the client would have paid more money to begin with. Just like in any area of the business, communication is key.

When is it okay to chase Edge Cases?

I think we can quit trash talking edge-case-chasers for now and focus on the when it’s actually appropriate to chase edge-cases. If you’re working for a company that has already successfully released a product, time can be divided between two ventures: bug/edge-case cleanup and new feature integration. It’s not an even 50/50 split, but more of an 80/20, with 80% of the time focused on new feature integration.

It’s not the time to hunt down edge cases during product development, especially if you’re trying to release it. It sounds counterintuitive to most people, since they think that the software must be perfect to be released into the wild, but the truth is that you will never release a product if you’re testing for perfection.

So, if you’re working for a big company with aim at product perfection (think Apple), finding edge-cases can be your biggest strength. Champaign will pour from the heavens and you will be regarded the best thing since sliced bread. In most other places, you’ll be told that you’re wasting time.

Finally

I hope that you’ve had a fun time reading through this. It’s definitely brought back PTSD from previous experiences for me. Every time a client mentions an obscure way to find something unintended, you just want to close your eyes, slowly exhale in exhaustion and whisper to them, “that’s an edge case.”