Page 167 - The Art of Designing Embedded Systems

154 THE ART OF DESIGNING EMBEDDED SYSTEMS

You can’t pick up a trade magazine today without seeing the indus-
try’s mantra-Time To Market-gracing every article and ad. All sorts
of studies indicate that getting a product out first is the best way to gain
market share and profitability. Whether this is true or not makes little dif-
ference; the important point is that management has universally bought
into the concept, leaving it up to engineering to somehow “make it so.”
The time-to-market furor explains surveys that show development
time to be the number one priority of many engineering departments, with
cost usually running third after quality. Whether we agree with the goals or
not, it is at least a reasonable ranking of priorities.
Get it done fast. Do a good job. And then worry about costs. These
are the constraints we’re working under, in order.
But we can’t develop a realistic plan without considering all of the
facts. One is that salaries continue to rise, especially now, and especially
for highly trained and scarce engineers. None of us can control this.
Fast, gotta be fast. Cheap, too-somehow we have to save bucks
wherever we can. OK. . . now what?
Astonishingly, more and more companies are making decisions like:
no tools. Poor tools. Or, let’s pick a chip that has no tools, or for which de-
cent tools are a but a dream.
How on earth are we supposed to be fast with inadequate tools?
Won’t costs skyrocket as we spend more time struggling to find bugs-
bugs that are more evasive than ever as products get more complex-using
what amounts to toys?
In the face of increasing salaries, more complex products, and tem-
fying schedules, all too often the question “How are we going to get the
work done?’ never gets answered honestly.
Yet, as you read this today, hundreds of companies pursue develop-
ment strategies that are doomed to cost too much and take too long. Some
use custom microprocessors-for good reasons and bad-and build their
own compilers and debuggers. I’m not saying this is necessarily wrong;
it’s just costly. Some of these businesses understand and manage the is-
sues; others just yell louder at the developers to meet the schedule.
I’ve seen months spent gluing CPUs inaccessibly into the core of a
monster ASIC, without the least thought given to debugging . . . and then
the hardware guys present the firmware folks with this fait accompli and
only two months left in the schedule.
We must look at the technology challenges posed by the parts we
choose, and then at our options for building the system and then finding
bugs. We must find or invent ways of achieving our fast-quality+heap
goals before committing to a difficult or impossible technology.