Ed Yourdon has advice for surviving "death march" projects.
"Out of life's school of war.What does not destroy me, makes
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).
|Table 1. Types
of death march projects
Again, even though there aren't formal definitions of the project types,
project participants typically know what type of project they're involved
- A Kamikaze project that is almost certainly doomed, but technically
sexy or politically important enough that team members don't care about
- 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.
| Want to read more of Mike's work? Sign
up for the monthly Developer Central e-newsletter,
including product reviews, links to web content, and more,
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
"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