Death March

What is a rule-of-thumb for determining if a project is a Death March?

In time of war

The infamous Bataan death march of world war 2:

http://history.acusd.edu/gen/st/~ehimchak/death_march.html

From the day of surrender on, the POWs would be harshly beaten and killed for the slightest or no reason at all... The Bataan Death March began at Mariveles on April 10, 1942. Any troops who fell behind were executed. Japanese troops beat soldiers randomly, and denied the POWs food and water for many days.

One of their tortures was known as the sun treatment. The Philippines in April is very hot. Therefore, the POWs were forced to sit in the sun without any shade, helmets, or water. Anyone who dared ask for water was executed. On the rare occasion they were given any food, it was only a handful of contaminated rice.

When the prisoners were allowed to sleep for a few hours at night, they were packed into enclosures so tight that they could barely move. Those who lived collapsed on the dead bodies of their comrades. For only a brief part of the march would POWs be packed into railroad cars and allowed to ride. Those who did not die in the suffocating boxcars were forced to march about seven more miles until they reached their camp.

It took the POWs over a week to reach their destination. (49) Those on Corregidor would suffer the same fate as their fellow soldiers on Bataan did as they too were transferred to Bataan.

The book

Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects by EdwardYourdon, Prentice Hall, 1997,

ISBN 0137483104 Reading this book is one of those "AhHa!" experiences; I kept thinking "I thought I was the only one who felt like that." Yourdon is considering the project we've all worked on, the one with impossible deadlines, no budget, conflicting goals, and constant overtime.

Chapter 1 gives painfully accurate diagnoses: what is a death march, what forces bring them into existence, and what motivates developers to join them. My favorite paragraph comes from Chapter 1's closing pages:

"The key point is to recognize and understand your own motivations at the beginning of a death march project, so that you can make a rational decision to join the team or look elsewhere for your next job. Since many of these projects are initiated during periods of great corporate stress and emotion, rational decisions are not as easy to make as you might think; it's all too easy to be swept away by the emotions of your fellow colleagues or your manager."

Yourdon repeatedly reminds the reader that one alternative is to quit, and that in many cases the consequences of quitting, even without another job, are no worse than the consequences of staying.

Reading this book will help you to make sensible decisions when you are next confronted with a DeathMarch.

My major complaint? The citations are poorly handled. Many of the examples come from E-mail, and you have to flip back and forth between citation and end-of-chapter to see who sent the E-mail and what they said.

-- BetsyHanesPerry

Well, I love this book too, as a large majority of projects I have been on have been death marches, and the analysis is pretty good. My major complaint is not that the citations are poorly handled, but that the political aspects, which drive DeathMarch projects, are not as openly discussed as they could be.

Ed Yourdon is an emeritus guy who has nothing to lose; he could as well have said explicitly that the major driver of DeathMarch projects is malicious politics, and that very few DeathMarch projects are started in good faith, instead of (heavily) hinting at this repeatedly. Because technical or even organizational solutions to DeathMarch projects are usually futile, the best that can be done is damage limitation.

Yes, quitting is always an option, but an increasingly painful one in post-bubble downsizing times, and for older employees likely to suffer from SoftwareAgeism when looking for a new job.

After a certain number of hours of work in a week, your productivity becomes negative - you make mistakes that take too much time to correct or make mistakes that undo work that's already been done. Most people reach this point by 60 hours per week (although a few people have an incredible capacity for working long hours productively). Of course, your productivity starts dropping long before it goes negative. A Death March project is a good sign of project mismanagement and impending project failure. It is unlikely that the underlying causes will be fixed by working harder at the same tasks.

You can also use this book as a not-so-subtle hint to your boss and co-workers: Be sure to be seen while reading it in the office during your lunch break ;-)

-- ToddCoram

I enjoyed the book - the part on negotiations was very comforting, especially when in the middle of such a 'Mission impossible'.

The book reminds - again - of the huge difference in culture between Europe and the States. -- MartineDevos

Martine, would you (or anyone else) care to describe what they see as the differences EuropeVsAmerica?? -- BenAveling

CultureDifferences are an interesting topic in and of themselves, and worthy of investigation. -- KyleBrown

I honestly believe that DeathMarch doesn't work. I've done it a million times. Every time I finally raised my head, I realized how stupid I had been being ... not just in destroying my life, but in the actual work. Rest is important - things rise from the subconscious and help with the work.

We know of lots of "successful" death march projects, which we use to justify them. It worked, therefore it was good. Some kind of macho thing, almost.

Is anyone aware of a "scientific" comparison of people's ability to do long periods of hard technical work while half dead, compared to alive?

-- RonJeffries

Does it mean anything that the "successful" projects were always documented by people who had something to lose if it were revealed that the project was a disaster?

See DoctorInternDeathMarch

Not quite, but TheSundayTimes of London (database currently not searchable) ran an article about a month ago about loss of sleep and IQ (for what that's worth). The research reported there suggests that for every hour of sleep lost from your normal sleeping time you lose about an IQ point. The effect is cumulative and it takes a long time to recover.

So *that's* what's been causing it! I had wondered.

UK industry guidelines suggest (something like) that overtime should not be worked for more then two weeks, with at least a two week period of normal working between overtime sessions. This recommendation is not widely publicized.

-- KeithBraithwaite

XP industry guidelines suggest (something like) that overtime should not be worked for more then one week, with at least a two week period of normal working between overtime sessions. This recommendation is widely publicized. -- AmirKolsky

I remember two key points from DeathMarch. The first was, as Betsy mentions, you can always quit (and I recently did exactly that). The second is that one way get a a death march project back under control is to resort to triage - cutting functionality drastically in order to return the project to tractability.

-- CurtisBartley

Although not programming, ABC (I think) recently did a piece on sleep deprivation, drinking and driving. Two groups of people. The first got plenty of sleep. The second only slept 4 hours per night for a five days.

When it came time to drive, two things were evident. The people who were given drinks were bad drivers. The people who were slightly sleep deprived were worse drivers.

Also, the people who had drinks were easily convinced they were bad drivers. The people who didn't sleep could not be convinced that it was affecting their driving.

This came with footage from inside the car. The non-sleepers ran over dogs, children and into obstacles and didn't even register it.

-- HergerThomann

4 hours per night for five nights running doesn't sound like slightly sleep-deprived to me. Sounds like moderately to severely. -- PeteHardie

And that's on a straight day. I've had several thrilling all-nighters, abused by unhealthy doses of Ritalin, followed by missing the next few days and still returning victorious. But it's really stupid, it only catalyzes your inevitable burnout. Save it for things that matter, kids :) -- JoshKnight?

Also, aren't you exaggerating a bit? Although I agree with your conclusion that cumulative sleep deprivation is bad for drivers and programmers, I doubt that ABC had footage of drivers running over children. Anyway, I do better when I get into bed early enough that I wake up before my alarm goes off, and I always allot myself 8 hours sleep before going to work. -- A bright-eyed and bushy tailed EdPoor

Real children and dogs and such weren't run over. It was an obstacle course with pop-up cardboard children, dogs, etc. Pete's story is accurate. - Someone It's Herger's story... I was just commenting on their definition of slightly sleep-deprived. -- PeteHardie

Ok, so I'll just work 16 hour days, 7 days a week, from here on. Maximum productivity! Seriously, though - you shouldn't need to tell people to get enough sleep, but sometimes you do. On one project, my boss slept about four hours a night. I tried not to speak to him before noon, because he was barely coherent. Project came in six months late anyhow. Still, he's a multi-millionaire now, so I guess it was worth it. -- JamieFristrom

Right. The brass saw a man killing himself to get it done, even if it was 6 months late, and even if the long hours may have hurt more than they helped. On the shoulders of the well-rested and productive he rode to prosperity...

Some who do not work so hard also ride on the shoulders of others, well-rested and productive or not. How do you get such a job? Become a signal/controller bee in the socialist hive. That is, politics.

I heard something that I think sums up the DeathMarch experience well: The next twelve months will be the longest five years of your life.

Alternatives: DoWhatYouKnow

CategoryBook