A thought about edge cases

In programming (and probably other engineering disciplines as well), there's something called an "edge case," which more or less equates to a statistically unlikely--but still possible--scenario in which your users may find themselves. This, friends and bretheren, is where the build-a-better-mousetrap mantra runs up against The Brain. It's not just the arms-race between you trying to idiot-proof your application and nature evolving cleverer idiots. It's also about the fact that the writers of a particular bit of software--your humble blogger as guilty as any of them--tend to think linearly; The Real World maybe not always so much.

So it befell that today I caught a bit of...let's call it "heck" over an emergency code reversion that I had to do in Subversion back in June. I had (successfully) unit-tested my changes in the lowest common denominator of Internet Explorer 6 and pushed code into the integration and QA servers where it caused all manner of mayhem for those running IE7 and higher. By which I mean most of the office. So there was a bit of a fire under my proverbial toes to undo my damage. (For non-developers: It's the equivalent of putting the car in reverse and putting the pedal to the medal.)

My gentle readers of earlier posts will, doubtless, be shocked to learn that it didn't go so well. But I didn't learn that until this, the eve of September, when one of my co-workers ran into file conflicts (not 100% my fault, I might add; there were other factors involved, which of course resulted in Subversion having one of its typical drama queen fits). But the central point is that, in June, I thought I had committed a successful reverse-merge to the repository (a.k.a. the code mother-ship) when I hadn't.

Now, well over 90% of the time, I'm going to be using this software (and the process cobbled together around it) to slap a herd of revisions on its collective backside and send it up the line: Boring stuff. Yet when a change has to be undone, there's typically more than a bit of adrenaline involved, because that means that something's broken or we didn't actually want it public yet. Thus, given the stakes, I would posit that that traveling back in time (code-wise) should be a one button process--and an absolutely bullet-proof one at that.

As much as it may seem like this is merely another chance to bash my least favorite software package--quite possibly of all time--I'm taking away something from today's blowup as well. And that is that un-using (yes, I'm making that word up, but you know what I mean) software may well be more critical than using it. This isn't an original thought on my part--at least from the advice that "Mistakes should be easy to undo." Rather, what I'm adding to that is the consideration that gracefully handling edge-cases is a yardstick for both design and implementation. Because making users rock and making them feel Not Stupid are really two sides of the same proverbial coin.