because edge cases

Part of a series of posts that discuss justifications for spending more time on a specific piece of code, rather than continuing onward.

The edge case justification for polishing code goes something like this:

I can’t just write code that accomplishes the goal — there are all sorts of things that could go wrong, so I must account for all of them. I’m writing some data to disk so I must correct for a fault in the disk? How will I recover from a catastrophic failure?

When do edge cases mislead us?

Edge cases are a tempting trap to fall into, because programmers are clever people, and because we can imagine innumerable catastrophes that we must protect against. Our code must be stable, reliable, and unbreakable — right?

Well, your code should be stable and reliable, but the trap of worrying about edge cases is all about building supposed robustness into a system to cover situations that are not the responsibility of our applications — from faults in other parts of the system, to faulty input from users of our systems.

We must be aware of who is responsible for the reliability of the various parts of our system, take it upon ourselves to fix the parts that are our responsibility, and delegate and collaborate with those who support us with contributed components.

Rather than trying to be perfect in the face of imperfect parts, we should do basic things like backup our systems in order to make recovery easier, or use abstraction layers such as virtual machines and containers to decouple our software from the hardware and operating system on which it runs.

When are edge cases helpful to think about?

Don’t build software to cover edge cases that you can imagine. Only cover cases that actually happen, and only those where the responsibility to recover from those cases actually falls onto your application.

Useful edge cases are those that teach us about the problem domain in which we are working, to give us a more nuanced understanding of how the world works, and what sorts of things might actually go wrong instead of the things that only we imagine might go wrong.