case study

Design Lesson:
Shovel Smart, Soon, and Often

Here in Northtemple Land, as in many parts of the United States, we’ve received slightly more than our fair share of precipitation in the last week. I have a long driveway to deal with and no snow blower (something I may need to remedy this year with Grandma’s Christmas check). The combination of heavy snow and a long driveway has resulted in an inordinate amount of time spent outside, with nothing to do but shovel and think.

What I’ve learned: Shovel smart, shovel soon, and shovel often. And what’s more, I think this applies to design as well as driveways, and maybe to any problem-solving effort.

First, let’s define some terms. When engaged in snow-shoveling, the stuff I’m trying to clear out is of course snow. What I’d rather be doing is building a snow fort or sitting inside under a warm blanket on the couch, reading that new book I’ve gotten for Christmas.

When I’m engaged in designing or building software, the stuff I’m trying to clear out is a messy combination of poorly understood requirements, technical problems to surmount, and depending on where I am in the product life-cycle, bugs. What I’d rather be doing is visual and interaction design of the “fun parts” of the system, not requirements gathering, trouble-shooting, or designing the more mundane stuff.

Lesson #1: Shovel soon—before anybody walks on the driveway or worse, drives down it. Often this is inconvenient. You or your spouse may have to stay in the car while the other clears an initial path. Your kids might have to clear the way before they head to the park, sleds in tow. But make sure you shovel before you travel; otherwise, you will have packed snow to deal with. And not just for today, but potentially for weeks and weeks, because once it’s packed, the results will be in your way until it melts or you buy a jackhammer. It’s uneven, slick, and hard to shovel. It also can also interfere with your ability to clear adjacent areas.

In design terms, make sure you uncover and understand the real needs before you design anything, and that you design those basics before anybody builds anything. Otherwise some less important or ill-understood requirement gets implemented first. Or you let loose a developer with a sense of aesthetics that doesn’t match the product vision or user needs, or any number of other problems intrude. Once code is laid down it is much harder to change the design—even if it is the wrong code. I’ve seen too many instances of “this is simple, it doesn’t need Design” turn into “oh, I hadn’t thought of that, but I guess we’ll just stick with what we’ve got, since it’s already built.”

Shovel first, travel second.

Lesson #2: Shovel smart—clear an initial, full-length path before attacking the full width of the problem. On my long driveway at least, I find it a good strategy to clear myself two long paths the full-length of the driveway, an axle-width apart. This gives me a clear path to drive on, even if I don’t accomplish anything else. If I decide to clear the rest of the driveway, it also gives me a clear place to stand without getting too wet, without slipping, and most importantly, without packing the snow under my feet.

In design terms, this means I should figure out what that initial path looks like. What is the bare minimum that can be delivered in the product and still have it meet the core requirements, even if there are other rough spots or missing bells and whistles? Figure out those requirements first, then design and build a bare-bones system to meet those requirements. You will probably have a good idea of other requirements and how they should be implemented, but don’t fully design or build it yet. Make sure you can just get the vehicle down the driveway before you worry about whether you can pop a wheely or perform other fancy maneuvers. (This one is so important that I’ll probably write up more specific design experiences with this later on. Thanks to Jeff Patton and UIE 13 for this one. And of course 37Signals and anybody else involved in actually agile development.)

Lesson #3: Shovel often—before problems get too thick to deal with. There are parts of my driveway where the snow can drift up to 3 or 4 feet unless I keep it cleared after each snowfall. If I get behind, maybe sidetracked by the fun stuff I’d rather be doing, I always pay for it in the long run when a 30 minute job takes 3 hours instead. The additional time is often longer than the sum of the time it would have taken had I just gotten to it earlier and more often. Why? Because the snow packs itself down, partially melts and re-freezes, and a single shovelful gets too heavy to lift, because of both increased volume and density.

So too in design. Combining Lessons 1 and 2, you have to keep the path clear—especially the essential path— not just once, but throughout the process. As design progresses to the important but not crucial features, it’s easy to forget that getting out of the driveway is paramount. As you clear the way for those secondary but still-important features, take care that you don’t accidentally make the main path harder to negotiate.

Also, as implementation begins, don’t allow bugs to accumulate for too long before getting them cleared out. This applies not just to the big important show-stoppers, but also the accumulation of lots of small issues. While each flake or bug might be inconsequential on its own, there comes a point when the whole product can bog down under the collective weight of a mediocre implementation of a great idea. The workarounds developers use to get around these problems end up breaking themselves when the bug is fixed; the developer leaves and the next guy can’t figure out the workaround; the user puts up with the problem long enough that they resist the fix, on the grounds that “it’s different.”

Some of this is just bound to happen on any project; bug-free code doesn’t exist, not at a reasonable cost on a reasonable-sized project anyway. But try to limit it to the non-essential periphery, and don’t allow it to clutter the key functions necessary for success.

* * *

Those reading only for design’s sake can stop here.

For those who want to carry this a step further into “real life”, I find that these principles apply to lots of other situations:

The End.

posted by Ted Boren on Friday, Dec 26, 2008
tagged with design, process, snow, shoveling, agile development