Page 207 - The Art of Designing Embedded Systems

194 THE ART OF DESIGNING EMBEDDED SYSTEMS

Engineering management is about removing obstacles to success.
Mentoring the developers. Acquiring needed resources.
It’s also about closing feedback loops. Finding and removing dys-
functional patterns of operation. Discovering new, better ways to get the
work done.
Doing things the same old way is a prescription for getting the same
old results.
It’s infuriating that typical projects fizzle out in a last-minute crunch
of bug fixes, followed by the immediate startup of a new development
effort. Nothing could be dumber.
Did you learn anything doing the project? Did your co-workers? Is
there any chance some bit of wisdom could be extracted from its successes
and failures-a bit of wisdom that may save your butt in the future? Why
do we careen right into the next project, hoping to avoid disaster by sheer
hard work, instead of taking a moment to take a deep breath, gather our
wits, and understand what we’ve learned?
Engineering managers simply must allocate time for a careful post-
mortem analysis of each and every project. Once the pressure of the ship
date is gone, all of the team members should work toward extracting every
bit of learning from the development effort.
Usually we casually pick up some wisdom even without a formal
postmortem. This is the basis for “experience,” a virtue acquired by mak-
ing mistakes. I’ll never forget shoehorning an RTOS into an almost com-
plete system more than a decade ago. Putting it in after 20,000 lines of
code were written hurt so badly I swore I’d never start a system like that
again without installing an RTOS as the first software component. This bit
of wisdom came in exactly the same way kids learn not to touch a hot
stove: pain. I believe we can do better than learning by acquiring scars.
A formal postmortem analysis has one goal: squeeze every bit of
learning from the just-completed project. Wring it dry, extracting infor-
mation to compress the acquisition of “experience” as much as possible.
The postmortem is not a forum for assigning blame. When I started
conducting these at my last company, the engineers immediately became
paranoid, thinking that this was the chance for management to “get” them,
in writing, in a venue visible to all employees.
If blame must be given, then do it privately and constructively. Non-
constructive criticism is a waste of time, to be used only when firing the
offending employee (if then).
Similarly, the postmortem shouldn’t be used as a staging area for the
engineers’ complaints against management. When there are valid concerns