When a plane crashes, the National Transportation Safety Board (NTSB) rushes to the scene, recovers the black boxes, and figures out what went wrong. They then issue recommendations that change pilot training, maintenance procedures, or the design of the aircraft so that sort of accident never happens again. The result: except for walking, air travel is the safest form of transportation known.

At the end of a disastrous, late, buggy firmware project, we simply start work on the next one. There's no analysis of what went wrong or right. Future projects thus benefit little from what is essentially a casual, undirected, and largely ineffective building of an experience base.

Why not stop for a couple of days before starting another project and conduct a postmortem? Emulate the NTSB. Fix a few things that will grease the next project. A properly run postmortem is the scientific acquisition of experience.

Project Retrospectives, A Handbook For Team Reviews by Norman Kerth is a small and very readable introduction to conducting postmortems in a software engineering environment. The book's target reader seems to be a professional postmortem facilitator, suggesting that its audience is nearly non-existent. In fact, Kerth devotes an entire chapter to selling postmortems to prospective clients. Yet there's value even there, since we often must sell the idea to upper management who usually just wants to see people coding.

Each chapter annoyingly starts with a story about ants, owls, and wolves that tries unsuccessfully to impart some bit of Zen-like wisdom. Winnie the Pooh does better. Skip the leading page or so of nonsense and just read the meat of the chapters. Suspend your natural engineer's cynicism that kicks into high gear whenever some touchy-feely words leave you screaming for cold, hard facts. You'll hate some of the group exercises that sound dredged from a bright-eyed McKinsey management consultant who just finished an Outward Bound class. Though this is exactly the sort of book that engineers tend to hate, there's much valuable information buried in the author's rambling style.

The book's greatest failing is the lack of statistical data. Since the author conducts postmortems for a living one would think he'd spew numbers throughout that show the value of postmortems. There are none, which is a shame. Other sources, such as Gloria Congdon's masters thesis Techniques and Recommendations for Implementing Valuable Postmortems in Software Development Projects (University of Minnesota, May 1999), do better.

Despite the problems the book lays out a reasonable procedure that will work to improve your software-development process. It has good guidelines that any team leader can use to run his or her own retrospective and has valuable insight for every member of a team who will be part of such a process.

The book shows quite specifically how to acquire and analyze data from the project. I would have liked to see the questions tied to tools to show how, for instance, Bugzilla can be used to more or less automatically collect data throughout the project.

Though the useful meat of the book's 261 pages could have been condensed to 50, this is one of the few books dealing with postmortems. It's a quick and easy read that I think is important to any team striving to evolve to a higher standard.