sean's place

The Exceptional Case

As I’m getting my townhome ready to sell and gearing up for a big move, I’m struck by one thing: Americans, as a culture, prepare for, no, we expect the exceptional case.

You see it all over the place. We choose larger homes, just in case we have kids or get a bigger TV. We buy large cars to cart the kids around or to ensure against the grisly in case of a catastrophic accident. We opt for trucks instead of cars in case we we need to haul a load from Home Depot, or purchase the tow package in case a boat should happen to come into our possession.

We regularly trade cost for the convenience of something we don’t regularly or often have a need for. This is all well and good — we like things bigger, better, and more featureful to make our lives easier.

The thing is, this isn’t true in software development. We regularly plan and develop for the average case — the typical use case — and eschew the exceptional. And I think this is a shame.

Not all organizations do this to the same extreme. However, the desire to get something out to market and the 80/20 rule (or whatever variation you use) often trumps the one feature or slight tweak that could make someone’s day. In software development (and this is probably true of product development in general), we trade box specs for time. We get as much done of a feature as we need to say that we have “it,” then we call “it” done.

This is discouraging.

I think some of this mentality is related to agile development practices. Agile teams, combined with aggressive product owners, move the development team from feature to feature with an ever-increasing myopia towards the requirements of the person yelling the loudest. They’ll tell you that they give as much as the market demands, but in the software world, it’s often (the so-called) business leaders dictating the the “requirements.” I’ve noticed this forgets the people charged with actually using the software, whose own ideas for improvement get drowned out in the “process.”

The end result is a product that can do the typical, a product that can do the average. Certainly not a product that expects the exceptional.

Is this a problem? No, not necessarily.

An average product serves the need of 80% (or more) of the people who use it. That’s a pretty good watermark. What troubles me is how we often overlook the one or two things we could do to make it more like 90 or 95% of the cases.

We don’t plan for the exceptional in software; and I think this manifests itself in a product that doesn’t feel “fully baked” when you use it.

In my rack room, I have a HP ProCurve Gigabit switch powering my network. I love this switch; it’s fast, it has an easy-to-use interface, it has enough ports for all the jacks throughout my house, and most of all: it rarely requires any management time from me. There’s one thing though that irritates me to no end about this switch: you can’t name the ports! This thing has 24 ports on it, but I’m expected to remember that port 13 is my cable modem and port 21 is the file server. To me, adding the ability to name the ports, is low-hanging fruit that would make my life substantially easier. This is the exceptional case; I’m using this switch as the core of my small network, rather than at the edge like HP intended.

Serving an exceptional case doesn’t always have to add a lot of work. In the case of my switch (and I’m going out on a limb here), I can’t imagine adding port naming would’ve been a schedule-blowing feature but it would have made life a lot easier for my case.

I think one of the nice features of Waterfall as a development methodology is that it specifies the whole solution. Agile development is the current industry best practice (for good reason), but it would be nice if we could bring some of the “whole solution” mentality to the process.