|


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?
|
|


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
|