Page 50 - The Art of Designing Embedded Systems
P. 50
Stop Writing Big Programs 37
Similarly, cut programs into smaller units. Since a large part of the
problem stems from dependencies (global variables, data passed between
functions, shared hardware, etc.), find a way to partition the program to
eliminate-or minimize-the dependencies between units.
Traditional computer science would have us believe the solution is
top-down decomposition of the problem, perhaps then encapsulating each
element into an OOP object. In fact, “top-down design,” “structured pro-
gramming,” and “OOP’ are the holy words of the computer vocabulary;
like fairy dust, if we sprinkle enough of this magic on our software all of
the problems will disappear.
I think this model is one of the most outrageous scams ever per-
petrated on the embedded community. Top-down design and OOP are
wonderful concepts, but are nothing more than a subset of our arsenal of
tools.
I remember interviewing a new college graduate, a CS major. It was
eerie, really, rather like dealing with a programmed cult member unthink-
ingly chanting the persuasion’s mantra. In this case, though, it was the
tenets of structured programming mindlessly flowing from his lips.
It struck me that programming has evolved from a chaotic “make it
work no matter what” level of anarchy to a pseudo-science whose precepts
are practiced without question. Problem Analysis, Top-Down Decomposi-
tion, 00P-all of these and more are the commandments of structured de-
sign, commandments we’re instructed to follow lest we suffer the pain of
failure.
Surely there’s room for iconoclastic ideas. I fear we’ve accepted
structured design, and all it implies, as a bedrock of our civilization, one
buried so deep we never dare to wonder if it’s only a part of the solution.
Top-down decomposition and OOP design are merely screwdrivers
or hammers in the toolbox of partitioning concepts.
Partitioning
Our goal in firmware design is to cheat the exponential in the CO-
COMO model, the exponential that also shows up in every empirical study
of software productivity. We need to use every conceivable technique to
flatten the curve, to move the M factor close to unity.
Top-down decomposition is a useful weapon in cheating the
COCOMO exponential, as is OOP design. In embedded systems we
have other possibilities denied to many people building desktop ap-
plications.

