Page 62 - The Art of Designing Embedded Systems

Stop Writing Big Programs 49

one-perhaps in a panicked late-night debugging session moments before
shipping, or for diagnosing problems that creep up in the field.
In a matter of days or a week or two you’ll have a skeleton assem-
bled, a skeleton that actually operates in some very limited manner. Per-
haps it runs a null loop. Using your development tools, test this small scale
chunk of the application.
Start adding the lowest-level code, testing as you go. Soon your sys-
tem will have all of the device drivers in place (tested), ISRs (tested), the
startup code (tested), and the major support items such as comm packages
and the RTOS (again tested). Integration of your own applications code
can then proceed in a reasonably orderly manner, plopping modules into a
known-good code framework, facilitating testing at each step.
The point is to immediately build a framework that operates, and
then drop features in one at a time, testing each as it becomes available.
You’re testing the entire system, such as it is, and expanding those tests as
more of it comes together. Test and integration are no longer individual
milestones; they are part of the very fabric of development.
Success requires a determination to constantly test. Every day, or at
least every week, build the entire system (using all of the parts then avail-
able) and ensure that things work correctly. Test constantly. Fix bugs
immediately.
The daily or weekly testing is the project’s heartbeat. It ensures
that the system really can be built and linked. It gives a constant view
of the system’s code quality, and encourages early feature feedback
(a mixed blessing, admittedly-but our goal is to satisfy the customer,
even at the cost of accepting slips due to reengineering poor feature im-
plementation).
At the risk of sounding like a new-age romantic, someone working in
aromatherapy rather than pushing bits around, we’ve got to learn to deal
with human nature in the design process. Most managers would trade their
firstborn for an army of Vulcan programmers, but until the Vulcan econ-
omy collapses (“emotionless programmer, will work for peanuts and log-
ical discourse”), we’ll have to find ways to efficiently use humans, with all
of their limitations.
We people need a continuous feeling of accomplishment to feel e€-
fective and to be effective. Engineering is all about making things work;
it’s important to recognize this and create a development strategy that sat-
isfies this need. Having lots of little progress points, where we see our sys-
tem doing something, is tons more satisfying than coding for a year before
hitting the ON switch.