Dead End

Ed Yourdon has advice for surviving "death march" projects.

• By Mike Gunderloy
• 03/01/2004

Nietzsche may have been a heck of a philosopher, but with an attitude like that, I expect he was a lousy boss. Then again, many of us who've survived the dot-com boom and bust cycle (or just about any other three years in the software industry) have plenty of experience with jobs that seem destined to destroy us. Colloquially, many of us refer to such a job as a "Death March," and, not coincidentally, that's the title of the Ed Yourdon book that I want to talk in this column. Recently reissued in a revised and expanded second edition (Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects, Prentice Hall, 2003), the goal of this book is to help you identify, and if possible survive, the death march projects that you might get sucked into.

A Taxonomy of Suffering
Yourdon doesn't bother to offer a formal definition of death march projects, pointing out (rightly, in my experience) that project participants know darned well when they're involved in a death match. But he does offer a simple way to classify death march projects into one of four basic types, based on the chance that the project will succeed and the happiness level of the participants (see Table 1).

Again, even though there aren't formal definitions of the project types, project participants typically know what type of project they're involved in:

• A Kamikaze project that is almost certainly doomed, but technically sexy or politically important enough that team members don't care about their fate.
• A Mission Impossible project where the team is motivated to succeed despite long odds and hideous working hours, and esprit de corps keeps them working hard.
• A Suicide project where everyone is both doomed and miserable, but they slog along because they have no choice in today's economic climate.
• An Ugly project that might well succeed, but only because the slavedriving manager is perfectly willing to sacrifice team members in the effort.

If you're asked (or told) to commit to a death march project, it's in your best interest to figure out which type of project it is early on. If the project might just succeed, you can offer your all (or at least everything short of your health and sanity); if it's destined to fail, perhaps your effort would be better spent on spreading your resume around and making phone calls to other companies that need your skill set.

Handling the Soft Stuff
Yourdon devotes a few chapters to the softer issues of death march projects, as seen from the manager's point of view (indeed, since the book is about surviving such projects, its advice is more often aimed at line managers than directly at developers). From politics to negotiations to "peopleware" issues, these chapters set up a framework for thinking about death march projects that positions the technical issues inside of a much larger framework. The overall theme to this section is that death marches are usually the result of political rather than technical issues, and the naïve manager who doesn't realize this is likely to end up being taken advantage of.

There's a lot of good advice in these chapters, but one key point stands out:

"Nevertheless, there is one aspect that I believe the manager should insist on, as an absolute right: the right to veto an attempt by other managers to stick an unacceptable person onto the team. To do otherwise is to add an unacceptable level of risk to a project that's probably already overburdened with other risks."

One of the nice things about the book, though, is that even such simple rules aren't treated as absolute pronouncements. Yourdon goes on to relate an alternative strategy (courtesy of Doug Scott) that involves taking all the people they want to stick you with, and winnowing out the ones who can actually help. Like a lot of other tidbits in the book, this one is backed up in the footnotes with Scott's original e-mail; the footnotes act as a sort of round-table discussion at the end of each chapter.

Tools and Processes
Yourdon also has some suggestions for choosing tools and processes for a death march project. These aren't at the level of "WhizBang Scheduler 4.0 will save you" or even "make sure you document everything." Rather, his attitude is that the project has to find its own level of processes and its own tools that maximize the chance of succeeding, even at the expense of offending the corporate Methodology Police. One way in which the book shines is in providing strategies that the concerned death march manager can use to protect his people from the bureaucracy and rule-making that infests many corporate IT shops.

A key here is the notion of triage, both for identifying the parts of the system that can actually be built in the time available and with the resources allocated, and for deciding which bits of process it actually makes sense to use to build them. The second edition revisions include a profitable discussion of extreme programming (XP) practices in this connection; although Yourdon doesn't endorse XP (or anything else, including his own gut feelings) across the board, he does find that its informal nature provides a useful starting point.

Time and Progress
Managing time and progress also come in for some attention here. On the time side of the equation, Yourdon discusses critical-constraint scheduling and helping team members manage their time to work on the truly important issues. On the progress side, he's a strong advocate of a daily build process and an advocate of risk management. I happen to agree on all of those points (and not just for death march projects) so it's no surprise that I enjoyed this portion of the book. You've probably already run across some of the concepts here in other books (or, if you're lucky, on the job), but it's nice to have them all pulled together in one spot. After all, if you're embarking on a death march, either by choice or otherwise, you probably don't have time to undertake a wide survey of the literature.

Business as Usual
Yourdon opens the book with a simple observation and ties it together at the end by repeating the same observation: that the nature of the competitive market and the pressures on software developers (as exemplified by the term "Internet time") have made death march projects the norm rather than the exception.

Depressing though that thought may be, a little reflection shows that it's probably true. Software has become so key to modern business that getting your software built before the other guy can finish confers almost insurmountable competitive advantage. That's true whether you're coding for shrinkwrap sales or writing an internal accounting system. If you get there first, your company gets to take business away from the competition. If you're lagging, you might watch your stock options quickly sink underwater. Faced with these realities, if anyone in your industry is willing to embark on a death march, they can drag everyone else along with them.

Some authors might view this as a situation to decry, or one to offer optimistic prescriptions for solving. While I'd certainly like to see the rise of a 40-hour work week in software development (and indeed, that's one of the key selling points that XP offers to developers), I'm not quite ready to believe that it's going to happen. And that's what makes this book valuable. While you're waiting for things to become all peachy come the revolution, Yourdon's advice will help you survive the present. At the very least, leaving a copy laying around your cubicle might tell your manager that you're on to them, and get you a tiny bit of extra consideration lest you refuse to march with the rest of the lemmings.

Are you a software death march survivor? Or do you have too much good sense to get involved in such projects? You can get hold of me at [email protected]. I'll use the most interesting comments in a future issue of Developer Central.