For novel ideas about building embedded systems (both hardware and firmware), join the 35,000 engineers who subscribe to The Embedded Muse, a free biweekly newsletter. The Muse has no hype and no vendor PR. Click here to subscribe.

By Jack Ganssle

Firmware without a Design

Published 5/14/2001

James Bond never had a plan, but through the miracle of fiction always managed to save the world. Never bumbling, yet never with a clear strategy, he somehow forged straight ahead to get the girl and put a smile on M's face.

Contrast that with building firmware. In the 50+ years of computer history we've learned to build code by first going through an excruciating design phase, and only afterwards creating piles of C. All of software engineering is predicated on the belief that code is very expensive, and change even more so. Craft a perfect design up-front to minimize modifications later.

Yet, if we're really honest, we do know that design doesn't quite work. How many projects end up with software implemented per the original design? Even with unchanging requirements, we're mostly unable to anticipate all of the problems that arise during development.

Worse, how often does the spec change during development? Specs are inherently fluid, changing as the marketing weenies constantly make revisions since, after all, "it's only software". A mid-project spec-change means a late scramble to adapt the code - not the design - to the new requirements.

Those who espouse eXtreme Programming (XP), a rather new approach to building software systems, see design as a source of problems, and suggest lowering it's importance. The four activities in an XP environment are coding, testing, listening and designing. in that order. One mantra sometimes heard from XP zealots is "the design will emerge from the code."

XP promotes the idea that we can write a lot of code very fast if we're not restrained by the normal front-end efforts. Crank it fast, but be willing to change it constantly. As issues become clearer, "refactor" (rewrite) constantly.

The ideas are fascinating, but the old fart in me trembles at the thought of forgoing or de-emphasizing design. I just can't imagine how structure can evolve from the chaos of the bits and pieces. Yet, deep in my heart, I can't think of any system I've worked on where changing requirements didn't mean a lot of late code changes, rarely annotated back into the design or design documents. All too often we crammed in major structural revisions very late in the project.

Perhaps XP is a tool best applied to smaller projects? Those devoid of complicated interactions or communications with many other processors, processes, or systems?

Or, perhaps it's best in an environment where the result is crystal clear, where the team members have built that kind of system before, and need less guidance from formal designs. Maybe if you build colorimeters all day long, and know everything there is to know about colorimeters, the design phase may inhibit rather than enable progress.

There's a lot more to XP than I've space to discuss. Programmers work in two person teams, intimately sharing a single workstation. Test code is as important as the product, and is written concurrently with every bit of software; as the code changes so do the tests. That's very cool.

XP projects always have a customer who lives with the development team. Not an occasional visitor auditing progress, but as an essential team member. The customer is the safety valve, insuring that the system we're building will indeed solve his problem. Adherents feel this compensates for the de-emphasized design process, which may make some sense.

But without a design, how do we anticipate hardware requirements? Is scheduling possible?

In talking to hundreds of embedded companies, I've come across only one that claims to practice XP, and in that case they employed but a subset of the process. Is XP viable for embedded designs?

What do you think? Is abdicating our up-front design suicide, or a healthy recognition of realistic practices?