No More Mr. Nice Guy!

On Death Marches and Dying: a programmer's guide to surviving project grief

[Update: Yikes! Ed Yourdon himself has taken note of my silly scribbling and linked to it from his website. Welcome to anyone who surfed here from there, and many thanks to Prof. Yourdon for the link. This is mainly a blog about politics and church-state separation, but here is another geek-oriented post that may be of interest: I ain't your code monkey!]

Okay, here's another of those posts which will only be of interest to a handful of geeks. I work for a large engineering company which is a subsystem prime contractor on a high-profile project. For obvious reasons I will not name names just yet. Suffice it to say that I've been in this game long enough to recognize a death march project, and to know that when you find yourself in such a project, the sooner you can get out of it, the better.

In this particular case, management has suddenly realized it needs to come up with 27 bazillion engineer-hours of software development effort in the next four weeks. I can't imagine why they didn't see this coming and plan to ramp up for it, instead of being taken by surprise in the closing months of the project. Anyway, every time I come in to work or get up for a cup of what passes for coffee here, I now have to dodge frantic managers running down the corridors with their hair on fire. It's all so familiar and predictable, I thought I would write down the five stages of a death march project, for those who have to deal with the grief that management piles on them.

Denial

Management sees that the project is in danger of slipping a crucial milestone, but doesn't want to do anything meaningful in case the customer finds out about the situation and loses confidence in the company. It feels sure that a few well-timed pep talks will be enough to fire the coolies up with zeal to work late nights and weekends, and get the schedule back on track. Developers have to spend valuable time listening to some pointy-haired boss telling them how important the project is.

Result: the project falls further behind schedule.

Anger

The schedule problem becomes too great to ignore. Management berates the developers for not working hard enough. It brings in an army of contractors with the idea of throwing manpower at the project and beating it into submission. Productivity plummets as the old hands have to spend time bringing the new people up to speed.

Result: the project falls further behind schedule.

Bargaining

Management cancels all vacations and introduces mandatory overtime and shift work. "It's just for the next few weeks," the managers promise. "And those working after midnight get all the Mountain Dew they can drink."

Result: the project falls further behind schedule.

Depression

The death march drags on with no end in sight. People forget what their spouses and children look like, and haven't seen daylight in a month. Managers continue to run around like headless chickens, and demand detailed and time-consuming status reports every day. Productivity falls even lower as programmers burn out and introduce bugs faster than they fix them.

Result: the project falls further behind schedule.

Acceptance

The brightest and most experienced developers go to a better place - a new job which isn't yet in death march mode. Those left behind have to take on the duties of the dear departed as well as their own.

Result: death. The project is finally cancelled and many engineers are laid off. Management drowns its sorrows in its year-end bonus, while vowing to learn its lessons and handle the next project better.

Go to Step 1 and repeat.