Page 206 - The Art of Designing Embedded Systems

People Musings 193

Does this scenario sound familiar? A small team starts a project with
great hopes and enthusiasm. Along the way problems crop up. Sales
changes the features. Management reduces the product’s cost. Schedules
slip when compiler bugs appear. Code grows bigger than expected. Real-
time response isn’t adequate, so the engineers start burning the midnight
oil, making heroic changes to get the system out, but schedules slip more,
tempers flare, and when the product finally ships no one is speaking to
each other.
A week later the developers are embroiled in another product, again
starting with high hopes, and again doomed to encounter the same rather
small yet common set of problems that cause late delivery.
Sliding into middle age one has the chance to observe patterns in
one’s life, patterns we seem to repeat over and over. Einstein said, “Doing
the same things over and over, and expecting different results each time, is
clearly insane.”
Yet most engineering efforts exhibit this insanity. Careening from
project to project, perhaps learning a little along the way but repeating the
same tired old patterns, is clearly dysfunctional.
In most organizations the engineering managers are held accountable
for getting the products out in the scheduled time, at a budgeted cost, with
a minimal number of bugs. These are noble, important goals.
How often, though, are the managers encouraged-no, required-to
improve the process of designing products?
The Total Quality movement in many companies seems to have by-
passed engineering altogether. Every other department is held to the cold
light of scrutiny, its processes tuned to minimize wasted effort. Engineer-
ing has a mystique of dealing with unpredictable technologies and work-
ers immune to normal management controls. Why can’t R&D be improved
just like production and accounting?
Now, new technologies are a constant in this business. These tech-
nologies bring risks, risks that are tough to identify, let alone quantify.
We’ll always be victims of unpredictable problems.
Worse, software is very difficult to estimate. Few of us have the lux-
ury of completely and clearly specifying a project before we start. Even
fewer don’t suffer from creeping featurism as the project crawls toward
completion.
Unfortunately, most engineering departments use these problems as
excuses for continually missing goals and deadlines. The mantra “Engi-
neering is an art, not a science” weaves a spell that the process of devel-
opment doesn’t lend itself to improvement.
Phooey.