By Jack Ganssle

Clairvoyance

Published 11/20/2003

The boss wandered into my office, something obviously on his mind. We had just finished developing a rather complex instrument and my team was hoping for a few weeks to catch up with a mountain of other long-deferred problems.

That was in 1975, when the only recognized software development methodology was big-up-front design (BUFD): figure detailed requirements, spend months designing the system, and only then design the hardware and software. In the decade I spent at that company we never used BUFD. Management's needs to see something working now meant we were cranking code long before the nature of the machine was clear.

Frustrated with these and other issues I eventually left and started a consulting company with an old friend. We'd do it right! Figure out the customers' needs, create an awesome design, and finally pop out the perfect implementation. Ah, the naivet‚ of youth! Turns out our customers didn't want that. they wanted something to play with, now, ASAP. People came to us with merely the vaguest outlines of what they wanted. One outfit with many years experience in industrial controls gave us virtually no functional spec but supplied reams of wiring specifications and rules about how to use explosion-proof enclosures. Specs on features, performance, and user interaction were lame at best. Needless to say we took a financial bath on that project.

Things didn't get much better.

Two years later I was consulting on my own. My first customer had spent a lifetime in the kitchen cabinet business, and wanted a bit of software to automatically design kitchens. That seemed sort of interesting. Since Ralph was a noted industry expert all I had to do was suck his brain dry, create a spec, and crank some code. Yet the rules he gave were habitually wrong, conflicted in complex ways, or incomplete. Every new prototype invariably produced designs he denounced loudly. "It's not supposed to do that!" he'd scream. but he could never give a consistent framework for me to work from. Perhaps I wasn't smart enough; God knows I didn't have the patience for this sort of thing, and eventually quit.

Decades later the requirements battle hasn't improved. What's different now is that BUFD is the strawman against which all alternative design approaches gets measured. Agile methods like eXtreme Programming are predicated on the impossibility of knowing detailed requirements. They advocate starting the software immediately, before anyone really understands what the system should do. To quote advocate Ron Jeffries "Get a few people together and spend a few minutes sketching out the design. Ten minutes is ideal - half an hour should be the most time you spend to do this."

As an old hand in this industry, I have to acknowledge that the truth behind this statement is that it mirrors the reality of the world. This is much like what too many of us do. XP and other methods simply codify an approach we've used furtively for many years.

But in the firmware industry, where our products might be either safety critical or at least very important to our customers, such a casual technique has to lead to lousy products.

Though BUFD is flawed in many ways, I think the alternatives are, for most embedded systems at least, even more dysfunctional. We need to know what the system will do before cranking code. Design by clairvoyance, waiting for the spirit to enlighten us, or hoping a design will emerge from the code are all routes to disaster.

What do you think? How do you determine your system's requirements?

Free Embedded Muse newsletter - twice/monthly, hard-hitting technical info that goes to 48,000+ engineers. Click here to sign up or enter your email here: