Page 21 - The Art of Designing Embedded Systems

8 THE ART OF DESIGNING EMBEDDED SYSTEMS

Happy customers make for successful products and businesses. The
customer’s delight with our product is the ultimate and only important
measure of quality.
Thus: the quality of a product is exactly what the customer says it is.
Obvious software bugs surely mean poor quality. A lousy user inter-
face equates to poor quality. If the product doesn’t quite serve the buyer’s
needs, the product is defective.
It matters little whether our code is flaky or marketing overpromised
or the product’s spec missed the mark. The company is at risk because of
a quality problem, so we’ve all got to take action to cure the problem.
No-fault divorce and no-fault insurance acknowledge the harsh real-
ities of trans-millennium life. We need a no-fault approach to quality as
well, to recognize that no matter where the problem came from, we’ve all
got to take action to cure the defects and delight the customer.
This means that when marketing comes in a week before delivery
with new requirements, a mature response from engineering is not a stream
of obscenities. Maybe . . .just maybe . . . marketing has a point. We make
mistakes (and spend heavily on debugging tools to fix them). So does mar-
keting and sales.
Substitute an assessment of the proposed change for curses. Quality
is not free. If the product will not satisfy the customer as designed, if it’s
not till a week before shipment that these truths become evident, then let
marketing et al. know the impact on the cost and the schedule.
Funny as the “Dilbert” comic strip is, it does a horrible disservice to
the engineering community by reinforcing the hostility between engineers
and the rest of the company. The last thing we need is more confrontation,
cynicism, and lack of cooperation between departments. We’re on a mis-
sion: make the customer happy! That’s the only way to consistently drive
up our stock options, bonuses, and job security.
Unhappily, “Dilbert” does portray too many companies all too accu-
rately. If your outfit requires heroics all the time, if there’s no (polite)
communication between departments, then something is broken. Fix it or
leave.

The CMM

Few would deny that firmware is a disaster area, with poor-quality
products getting to market late and over budget. Don’t become resigned to
the status quo. As engineers we’re paid to solve problems. No problem is
greater, no problem is more important, than finding or inventing faster,
better ways to create code.