C/C++ Users Journal September, 2004
Death March, Second Edition
Edward Yourdon
Prentice-Hall PTR, 2003
304 pp., $29.99
ISBN 01314363X
Edward Yourdon's Death March is a good book, but not a fun read unless you have descended into terminal cynicism. Yourdon defines a "death march" as a project overcommitted by at least 50 percent—too much performance or features promised, too few people, or too little time allowed. While software estimating is not an exact science, it currently is good enough to see big problems coming. So why do they still happen? Politics, usually. And why do people sign on to them? Naive bravado or a perceived lack of alternatives. Notice that these are people problems. Yourdon's solutions for surviving a death march are largely people solutions. It isn't better design or coding tools, it is better communication and management.
The first half of Death March lays out the terrain and the vocabulary. The terrain is familiar, but the perspective is one of people, relationships, and communication. The vocabulary is mostly standard management stuff with a few updates for the early 21st century; for instance, "the changing employee/ employer social contract." You may be loyal to them and they may ship your job to the third world for better quarterly figures on Wall Street. In nearly every chapter, he reminds you to ask yourself why you are here, and are you sure you can't quit?
The second half of the book looks at successful tactics and strategies—some conventional, some radical. Sometimes this requires pointing out the state of the emperor's apparel (Yourdon quoting Tom DeMarco and Tim Lister):
Police-mentality planners design workspaces the way they would design prisons: optimized for containment at minimal cost. We have unthinkingly yielded to them on the subject of workplace design, yet for most organizations with productivity problems, there is no more fruitful area for improvement than the workplace.
As long as workers are crowded into noisy, sterile, disruptive space, it's not worth improving anything but the workplace.
Solutions include relocating the entire project to an unused warehouse (aka the skunk works), moving the project to cyberspace (telecommuting and virtual offices), or moving to the graveyard shift to escape the methodology and cubicle police.
For any project, triage early and often is in order—sort features into must-have, should-have, and could-have (Yourdon thinks three categories are enough). Quality levels are also looked at; good enough and soon is often more desirable than perfect and late.
Yourdon digs out the best and worst practices from the currently fashionable methodologies. Best practices frequently require high discipline, low ceremony, and appropriate formalism. Worst practices are often those same practices with the spirit ripped out, leaving only dead-letter drudgery enforced by literalist methodology police.
For scheduling, he advocates moving the overrun room out of individual tasks and into a project-wide budget. This requires a level of trust that can be hard to achieve while under the gun (more on this in the last chapter). He also advocates assigning only one task at a time. Team members may occasionally be idle, but the increased efficiency makes up for it.
The time and risk-management chapters discuss how projects get into deadline trouble. Time slips away in meetings that start late and run on without a clear stopping point. Political infighting may block necessary decisions. Before you sign on to a project, ask for a small but nontrivial decision from the stakeholders. If a decision takes more than a day, run!
For Yourdon, tools are to help team members communicate, not magic bullets to solve design problems. E-mail, groupware, and other collaboration tools are at the top of his list.
The last chapter is "Simulators and War Games." Simulators are so that you have experience handling extreme situations before they happen for real. The midst of a death march is a poor time to learn new practices and build trust. He gives URLs for several simulations, from ones a team can do in an afternoon to week-long courses with four-figure costs.
Death March is a book for working software developers, their managers, and people about to enter those roles. I found no typos, a rarity in a book this technical. Some of the URLs are already out of date before publication (I read a draft manuscript). The quoted e-mails are often in a large typewriter font, visually jarring, but often fascinating content. Yourdon's predictions in the Decline and Fall of the American Programmer may have been ahead of their time, but with the advice in Death March, maybe we can look forward to the Rise and Resurrection of the American Programmer.