Page 15 - The Art of Designing Embedded Systems

2 THE ART OF DESIGNING EMBEDDED SYSTEMS

All in all, as Rodney Dangerfield says, “We just can’t get no
respect.”
It’s my belief that this attitude stems from a fundamental misunder-
standing of what an engineer is. We’re not scientists, trying to gain a new
understanding of the nature of the universe. Engineers are the world’s
problem solvers. We convert dreams to reality. We bridge the gap between
pure researchers and consumers.
Problem solving is surely a noble profession, something of impor-
tance and fundamental to the future viability of a complex society. Sup-
pose our leaders were as single-mindedly dedicated to problem solving as
is any engineer: we’d have effective schools, low taxation, and cities of
light and growth rather than decay. Perhaps too many of us engineers lack
the social nuances to effectively orchestrate political change, but there’s no
doubt that our training in problem solving is ultimately the only hope for
dealing with the ecological, financial, and political crises coming in the
next generation.
My background is in the embedded tool business. For two decades I
designed, built, sold, and supported development tools, working with thou-
sands of companies, all of whom were struggling to get an embedded prod-
uct out the door, on time and on budget. Few succeed. In almost all cases,
when the widget was finally complete (more or less; maintenance seems to
go on forever because of poor quality), months or even years late, the en-
gineers took maybe five seconds to catch their breath and then started on
yet another project. Rare was the individual who, after a year on a project,
sat and thought about what went right and wrong on the project. Even
rarer were the people who engaged in any sort of process improvement, of
learning new engineering techniques and applying them to their efforts.
Sure, everyone learns new tools (say, for ASIC and FPGA design), but few
understood that it’s just as important to build an effective way to design
products, as it is to build the product. We’re not applying our problem-
solving skills to the way we work.
In the tool business I discovered a surprising fact: most embedded de-
velopers work more or less in isolation. They may be loners designing all
of the products for a company, or members of a company’s design team.
The loner and the team are removed from others in the industry, so they de-
velop their own generally dysfunctional habits that go forever uncorrected.
Few developers or teams ever participate in industry-wide events or com-
municate with the rest of the industry. We, who invented the communica-
tions age, seem to be incapable of using it!
One effect of this isolation is a hardening of the development arter-
ies: we are unable to benefit from others’ experiences, so we work ever