________________________Articles

 

 

 

Certification of Software Engineers

Early Start to Testing

Funktionen im Objektmodell?

Growing Internal Consultants

Litigation of Software-Intensive Projects

Measurable Requirements

On Death March Projects

O-O-Design: ganz einfach oder sehr kompliziert?

Performance in Organizations

Professionalism in Software Engineering

Requirements Patterns

Reusing the Products of Analysis

Setting the Context

Systems Architecture

UML: A Curse or Blessing? (pdf file)

Wer verträgt wieviel Abstraktion?

Wohin mit den Funktionen im Objektmodell?

 

 

An American Programmer Electronic Reprint

letters

LETTER TO THE EDITOR
No Means No!

Imagine, if you can, an article that tries to put a better light on the much maligned subject of rape. It might argue that rapists are people too, and they seem to like what they do; that it keeps them off the street (however briefly), and that it gives some focus to what otherwise would be their empty lives. You would be less than patient with such a perspective, as would I. You'd want to reach out and shake the author and shout "This is RAPE you're talking about, you moron! It is not a subject for non-judgmental treatment."
     That is exactly how I felt reading the AP issue on Death March Projects. Most of the articles tried to be non-judgmental about projects that involved huge ethical lapses, offensive abuses of the contract between worker and employer, and willful, stupid damage done to the fragile ecology of people's lives. Most of the authors offered cheerful advice about how to cope with such projects: the equivalent of 'relax and enjoy it.' I was not amused.
     Death March projects, in my experience, always have three characteristics:
               o a culture of fear,
               o an absense of justification, and
               o a virtual certainty of failure
Projects that don't have these three characteristics are just not Death March projects. They don't justify the analogy to the plight of poor soldiers who lost their lives in the historical death marches in Burma and Bataan. Unfortunately there are many projects that do justify that analogy.

CULTURE OF FEAR:
     Why do you suppose that the workers on the Burma railway allowed themselves to be marched out to their almost certain deaths in order to build the railway? That's an easy one: they would have been murdered or tortured if they had refused. So too with Death March projects. People don't take part of their own free will. They take part because management has instilled a culture of fear that assures them they will be fired or demeaned for not marching to orders. Death March projects typically take place during recessions and pullbacks of the employment market; otherwise workers would tell their managers to shove it. This kind exploitation of market dips is unconsciencable.

ABSENSE OF JUSTIFICATION:
     You might think that a Death March project would have some kind of overarching rationale, that it would be conducted as a death march because, in Sharon Marsh Roberts' terms, it "offers a chance for unexpected and acclaimed success." While you can conceive of such a situation in the abstract, in the specific it is never there. Instead, Death March projects are typically endeavors to produce products of monumental insignificance.
     It took me a while to understand why this was. I remember being instructed by a potential client at MasterCard that the project he was trying to get us to bid on was going to be "12-hour days, gentlemen, and not just at the end but from the beginning." I waited for him to explain why that was. The product he then described was almost totally useless. It offered so little benefit to the organization that no other manager had been willing to touch it. If it were built in a normal way, its Cost:Benefit ratio would have been about four-to-one. Since that made no sense, the manager in question had decided to build the project for a fraction of its normal cost by extracting labor under duress. He hoped to make his reputation on the backs of his workers.

CERTAINTY OF FAILURE:
     Of course, such projects always fail. Screwing the managers who are trying so hard to screw you becomes the project's only real goal. It is always achieved in the end.

     The one article in the issue that was different was "Reliable work on a death march schedule" by Gorton et al. I would argue that this wasn't a Death March project at all, but a "life march." The work was worth doing, it was drawn along by willing workers (no culture of fear), and it was given every chance of success. I think the article was included in the issue more for reasons of magazine scheduling than for its similarities to the others.
     Death March projects are unethical, stupid, and always hell-bent for failure. People who run them get what they deserve in the end. That is the only bright side I can see to this dismal subject.

 

Tom DeMarco                    
The Atlantic Systems Guild
Camden, Maine
    

 


AMERICAN PROGRAMMER
EDITOR:
Ed Yourdon
EDITORIAL BOARD: Larry L. Constantine, Bill Curtis, Tom DeMarco, Capers Jones, Tomoo Matsubara, Roger Pressman, Paul A. Strassmann, Rob Thomsett

Reprinted from Vol. 10, no. 4 of AMERICAN PROGRAMMER. © Copyright 1997 by Cutter Information Corp., 37 Broadway, Arlington, MA 02174, USA. Phone: (617) 648-8702 or (800) 964-8702, Fax: (617) 648-1950, E-mail: info@cutter.com. All rights reserved.

top of page