Edge Cases Define the Shape of Your Product

By Nicholas Gracilla  ·   March 30, 2021  ·  3 minute read

Edge cases embody what a software system can and cannot do—and what it can't do well and for whom. Improve your business by exploring them well.

When I analyze software systems, I often hear, “well, that’s an edge case.” But edge cases define the shape of software. They embody what it can and cannot do—and what it can’t do well and for whom. Here’s a great example.

Throughout the pandemic, online courses and mixed live-recorded webinars have flourished. These educational platforms are often a combination of systems: a marketing and communications website, an e-commerce system to handle customer information and payment, and a conference platform to manage authorization, video streaming, and conference-specific features. What’s the interface between these systems? In many cases, a human administrator handles loading registrants to the conference system. At the outset, this seems like a satisfactory solution. At least until a late — but often highly motivated — customer signs up. Let’s take a look at the problem.

The problem

Sequence diagrams are a kind of chart perfectly suited to clarifying the interactions between complex systems.

I’ve begun to incorporate sequence diagrams into my work practice because everyone, from developer to customer service to management, can understand what’s happening here at a glance. Read sequence diagrams from top to bottom, much like a dialogue that shows the interactions between characters in a scene. And it’s going to be “Late customer,” in this scenario, who is anxiously pestering customer support over email for his credentials, or asking on Twitter why he can’t log in while everyone else is tweeting how great the speaker is. What a frustrating experience!

Solution 1: in software

Sequence diagrams help clarify edge cases to business owners, who can then decide whether that late customer’s poor experience is something they want to ignore. The diagram can highlight solutions, too, which don’t always have to be in the software system itself. Here’s an example of a software-driven solution:

In this case, we automate the communications between the website and the conference platform via APIs so that the admin can get on to more pressing matters, like preparing for the conference and welcoming attendees.

Solution 2: in business process

Not every solution requires more software, though. Here’s an example of a forcing function solution, where we fail one stage of the interaction to prevent failures at a later stage:

While arguably less ideal, it still handles the late customer case well and even provides the opportunity to sell him on the recorded materials. What’s most important to recognize, though, is that the edge case here — a late customer — is probably a reasonably likely one. Handling it well, either in software or through business practices, will only improve customer service and the sense of polish for the business.

Comments? Questions?

Feel free to send us a note; we'll get right back to you.