Page 60 - The Art of Designing Embedded Systems

Stop Writing Big Programs 47

and you can neglect the hard problems. Extend the schedule to infinity and
the product can be perfect and complete.
Too many computer-based products are junk. Companies die or lose
megabucks as a result of prematurely shipping something that just does not
work. Consumers are frustrated by the constant need to reset their gadgets
and by products that suffer the baffling maladies of the binary age.
We’re also amused by the constant stream of announced-but-
unavailable products. Firms do quite exquisite PR dances to explain away
the latest delay; Microsoft’s renaming of a late Windows upgrade to “95”
bought them an extra year and the jeers of the world. Studies show that get-
ting to market early reaps huge benefits; couple this with the extreme costs
of engineering and it’s clear that “ship the damn thing” is a cry we’ll never
cease to hear.
Long-term success will surely result from shipping a qualify product
on rime. That means there’s only one leg of the twisted tradeoff left to fid-
dle. Cut a few of the less important features to get a first-class device to
market fast.
The computer age has brought the advent of the feature-rich product
that no one understands or uses. My cell phone’s “Function” key takes a
two-digit argument-one hundred user-selectable functions/features built
into this little marvel. Never use them, of course. I wish the silly thing
could reliably establish a connection! The design team’s vision was clearly
skewed in term of features over quality, to consumers’ loss.
If we’re unwilling to partition the product by features, and to build
the firmware in a clear, high-priority features-first hierarchy, we’ll be for-
ever trapped in an impossible balance that will yield either low quality or
late shipment. Probably both.
Use a feature matrix, implementing each in a logical order, and make
each one perfect before you move on. Then at any time management can
make a reasonable decision: ship a quality product now, with this feature
mix, or extend the schedule until more features are complete.
This means you must break down the code by feature, and only then
apply top-down decomposition to the components of each feature. It means
you’ll manage by feature, getting each done before moving on, to keep the
project’s status crystal clear and shipping options always open.
Management may complain that this approach to development is, in a
sense, planning for failure. They want it all: schedule, quality, and features.
This is an impossible dream! Good software practices will certainly help hit
all elements of the triad, but we’ve got to be prepared for problems.
Management uses the same strategy in making their projections. No
wise CEO creates a cash flow plan that the company must hit to survive: