Suppose you’re on a game show, and you’re given the choice of three doors: Behind one door is a car; behind the others, goats. You pick a door, say No. 1, and the host, who knows what’s behind the doors, opens another door, say No. 3, which has a goat. He then says to you, “Do you want to pick door No. 2?” Is it to your advantage to switch your choice?

So I wrote the below simulator to find out. It uses the Monte Carlo Technique, which is a nice way of solving math problems numerically.
The results from my run are pretty conclusive:

Twitchy winners : 653
Twitchy losers : 347
Stubborn winners : 318
Stubborn losers : 682

So it really does pay to switch doors when the host gives you the choice. Which is not what I had expected – and means it’s time for me to go eat some humble pie .

Code listing below:

#!/bin/ksh
#######################################################
# monty_hall.sh
# Andrew Fraser ( http://andrewfraserdba.com )
# January 2007
# Simulator for the Monty Hall 'paradox'. See http://en.wikipedia.org/wiki/Monty_Hall_problem for background info
# Usage:
#  monty_hall.sh <no_iterations> <twitchy|stubborn>
#  e.g.: monty_hall.sh 1000 twitchy
# Parameters:
#   1 - NO_ITERATIONS - number of times to run simulation (a few hundred is reasonably fast on most machines)
#   2 - CONTESTANT_TYPE - twitchty = moves doors when given chance to move : stubborn = stays put when given chance to move
# Notes:
#   ksh RANDOM built in function is not the best random function in existence, although there are patches that resolve that.
#   RANDOM returns a number between 0 and 32768. The three doors here are named "0", "1", and "2", achieved by dividing by 10924
#
#   A good idea is to redirect the output for larger runs, and grep out the results. E.g.:
#     monty_hall.sh 1000 twitchy > twitchy.out
#     monty_hall.sh 1000 stubborn > stubborn.out
#     echo Twitchy winners : `grep Congratulations twitchy.out|wc -l`
#     echo Twitchy losers : `grep dear twitchy.out|wc -l`
#     echo Stubborn winners : `grep Congratulations stubborn.out|wc -l`
#     echo Stubborn losers : `grep dear stubborn.out|wc -l`
#######################################################

i=0

NO_ITERATIONS=$1
CONTESTANT_TYPE=$2

while [ $i -lt $NO_ITERATIONS ]
do

CONTESTANT_DOOR1=`echo $(( RANDOM / 10924 ))`
echo CONTESTANT_DOOR1 is $CONTESTANT_DOOR1
PORSCHE_DOOR=`echo $(( RANDOM / 10924 ))`
echo PORSCHE_DOOR is $PORSCHE_DOOR

if [ $CONTESTANT_DOOR1 -eq $PORSCHE_DOOR ]
then
RIGHT_FIRST_TIME=yes
#host now uncovers one (at random) of the two remaining doors to show a goat...
ZERO_OR_ONE=`echo $(( RANDOM / 16384 ))`
if [ $PORSCHE_DOOR = 0 ]
then
let UNCOVERED_GOAT_DOOR=1+ZERO_OR_ONE
elif [ $PORSCHE_DOOR = 1 ]
then
if [ $ZERO_OR_ONE = 0 ]
then
UNCOVERED_GOAT_DOOR=0
else
UNCOVERED_GOAT_DOOR=2
fi
elif [ $PORSCHE_DOOR = 2 ]
then
UNCOVERED_GOAT_DOOR=$ZERO_OR_ONE
fi
echo UNCOVERED_GOAT_DOOR is $UNCOVERED_GOAT_DOOR
else
RIGHT_FIRST_TIME=no
#host now uncovers the only other goat door to show a goat...
let UNCOVERED_GOAT_DOOR=3-CONTESTANT_DOOR1-PORSCHE_DOOR
echo UNCOVERED_GOAT_DOOR is $UNCOVERED_GOAT_DOOR
fi

if [ $CONTESTANT_TYPE = twitchy ]
then
# contestant moves to the other uncovered door, maybe cos she read something about that being good strategy on wikipedia...
if [ $RIGHT_FIRST_TIME = yes ]
then
echo ":( Oh dear, you won a goat, what a shame, you were right first time, if only you had stayed where you were!  "
else
echo ":) Congratulations! You've won a porsche  "
fi
else
# contestant stubbornly stays where she is...
if [ $RIGHT_FIRST_TIME = yes ]
then
echo ":) Congratulations! You've won a porsche  "
else
echo ":( Oh dear, you won a goat, what a shame, you should have moved door.  "
fi
fi

echo

let i=i+1

done

For the actual run I did, with results pasted above, I ran:

monty_hall.sh 1000 twitchy > twitchy.out
monty_hall.sh 1000 stubborn > stubborn.out
echo Twitchy winners : `grep Congratulations twitchy.out|wc -l`
echo Twitchy losers : `grep dear twitchy.out|wc -l`
echo Stubborn winners : `grep Congratulations stubborn.out|wc -l`
echo Stubborn losers : `grep dear stubborn.out|wc -l`

Mind-boggling projects— the project has an army of 1,000–2,000 or more (including, in many cases, consultants and subcontractors), and the project is expected to last seven to ten years.

As for the “mind-boggling” death march projects: One wonders why they exist at all. Perhaps the systems development efforts associated with the NASA project that landed a man on the moon in 1969 could be considered a successful example of a death march project; but the vast majority of such projects are doomed from the beginning. Fortunately, most senior managers have figured this out, and most large organizations (which are the only ones that could afford them in the first place!) have banned all such projects. Government organizations, alas, still embark upon them from time to time; along with potentially unlimited budgets with which to tackle truly mind-boggling projects, appeals to patriotic notions (e.g., “national security” in the post-9/11 era) may be sufficient to blind senior management to the futility of the task they’ve been given.

This still leaves unanswered the questions of why a rational organization would embark upon such a project and why a rational project manager or technical person would agree to participate in such a project.

The “Marine Corps” mentality: Real programmers don’t need sleep

Startup companies are sometimes vulnerable to the “Marine Corps” syndrome, but I’ve seen it most often in the consulting organizations like EDS and the Big-X accounting firms. It may reflect the personality of the corporate founder(s), and it may reflect the corporate culture in its earlier days—the corporate behavior at Microsoft, for example, has often been attributed to these factors. In essence, you’ll be told by the appropriate manager, “Every project is like this, because that’s how we do things around here. It works, we’re successful, and we’re damn proud of it. If you can’t handle it, then you don’t belong here.”

Whether an attitude like this is civilized, humane, or right is a topic for a separate discussion. Indeed, the question of whether it’s even successful is something to be discussed elsewhere; the important thing is to realize that it’s deliberate, not accidental. If you’re a martyr or a revolutionary, you might decide to attack the corporate culture, but the chances are that you won’t succeed. It’s quite possible that there will be some negative long-term consequences of the overall death march culture, for example, the best people may slowly drift away and the company may fail. But when it comes to this death march project, there’s no point questioning why it has been set up with a nearly impossible schedule and budget. As the prototypical manager of such companies says, “If you can’t handle it, then you don’t belong here.”

Sometimes there’s an official rationale for such corporate behavior—for example, “We compete in a tough marketplace, and all of our competitors are just as smart as we are. The only way we succeed is to work twice as hard.” And sometimes the death march projects are set up to weed out the younger (weaker) junior employees, so that only the survivors of the death march projects will reach the exalted status of “partner” or “vice president.” Whatever the rationale, it’s usually fairly consistent; there’s not much point complaining about it for the sake of a single project.

That doesn’t necessarily mean that you should accept an assignment on such a project; after all, just because every other project within the organization is a death march doesn’t necessarily mean that yours will succeed, or that you will survive. It simply means that the decision to create such a project has an understandable origin.

Why Do People Participate in Death March Projects?

The theme of the discussion in the previous project is that organizations create and/or tolerate death march projects for a number of reasons. We may agree or disagree with those reasons, and we may sympathize with the ones caused by truly unexpected crises—but ultimately, as individuals, we have to accept them as a fact of life.

But that doesn’t mean we have to participate in them. Most of this book presumes that you will participate in a death march project, though I will specifically suggest that you resign under certain circumstances. But the best time to do so, in most cases, is at the beginning. When told that you have been assigned to such a project (either as a leader or a technical staff member), you should consider saying, “No, thanks! I’ll pass on this one.” If that’s not an acceptable response within your corporate culture, you almost always have the option of saying, “No, thanks! I quit!”

Obviously, some developers—and probably a larger number of managers—will argue that this is not a practical choice for them. I’ll discuss this in more detail below, but for now it’s sufficient to note that it’s one of several possible “negative” reasons for participating in a death march project; it may not be fun, but perhaps it’s not as bad as the alternatives. On the other hand, some developers (and some managers) gladly sign up for such projects; aside from the issue of naive optimism discussed above, why would any rational person volunteer to participate in a project that’s likely to require 14-hour days, seven-day weeks, and a year or two of postponed vacations?
And as Paul Neuhardt put it,

For me, it was ego, pure and simple. They told me that they just knew I could help prevent the project from becoming a death march. I was made the “technical project manager,” given ego boosts on a regular basis, then hung out to dry along with the rest of the team. Left, right, left, right, left, plop!

The “Mt. Everest” syndrome

Why do people climb dangerous peaks like Mt. Everest, despite the pain and the risk? Because it’s there. Why do people run a marathon and drive themselves to the point of physical collapse in triathlons? Because of the challenge. It’s all the more exciting if the challenge is one that has never yet been successfully accomplished; of the six billion people on the planet, for example, only one can stand before us and say, “I was the first to walk on the moon.” Some may think it’s crazy, egotistical, and selfish to even try; but others are willing to brave the odds and deal with horrendous obstacles for the private thrill and the public glory of succeeding. As consultant Al Christians remarked to me in a recent e-mail note,

I am somehow prompted to reply “testosterone,” which is about the same as “because it’s there.” There are plenty of jobs that raise the ‘why?’ question. Underground mining, cowboying, logging, smoke jumping, jet fighting, submarining, even high-rise window washing all have serious drawbacks far beyond what you describe for software projects, and yet all these have practitioners whose sense of self is linked to their profession.

And so it is with death march software projects. I had the chance to visit the original Macintosh project in the fall of 1983, a few months before the product was officially unveiled, and was humbled by the intensity of the team’s commitment to its challenge. In addition to whatever other reasons the members might have had for working long hours and dealing with Steve Jobs’ megalomaniacal ego, the team was utterly convinced (partly as a result of Jobs’ charisma) that the Macintosh would revolutionize personal computing. They were lucky—they turned out to be right.

From this perspective, even the death march projects that fail can be noble failures. Countless projects in Silicon Valley have fallen into this category, often after burning tens of millions of dollars of venture capital; while most of the dot-com startups had no substance at all, some of them really did seem awe-inspiring and revolutionary until they went into bankruptcy. But even though they failed so badly that entire companies went bankrupt, and though they caused divorces, ulcers, and nervous breakdowns—even though they did all of this and more—the people who worked on those projects still speak of their experiences in hushed tones. “I worked on the Toys.com system,” a grizzled veteran will tell her awe-struck apprentice. “Now that was a revolutionary piece of software!”

Though it may never reach the front pages of Computerworld, there are also numerous death march projects with lofty ambitions buried within large organizations—with application developers signing up gladly because the “corporate Mt. Everest” seems such a worthy challenge. Sometimes these projects fail because the marketplace or the corporate end-users don’t want and don’t need the glorious, revolutionary systems being developed; and sometimes they fail because the project team bit off more than it could chew and promised more than it could deliver.

There are two things to watch for if you find yourself being swept up in the hysteria of a Mt. Everest-style death march project. First, watch out for the projects that are predetermined failures. Suppose, for example, that someone told you that you could be on the first manned mission to Mars, and that you would even have the honor to be the first person to plant a foot on Martian soil. “Of course,” your project manager goes on to say, “you won’t have any oxygen tanks, because we won’t have enough room on the space craft for all that extra weight. So it’s a guaranteed fact that you’re going to die—but think of the honor and the glory!” I’ll discuss these projects in more detail in Chapter 3, under the heading of “kamikaze” projects; for now, the scenario speaks for itself.

The second thing to watch out for is that the challenge being described by your corporate management (or by the entrepreneurial founder of your software company) may not turn out to be such a big deal after all. This is a particularly insidious danger if the challenge is technical in nature, for example, “We’ll be the first people on earth to put an operating system with the functionality of Windows XP into 128K of ROM!” Granted, that would be an amazing technical accomplishment—but so what?

It’s a good idea to ask the “So what?” question two or three times—in other words, continue asking the question in response to each successive answer you get from your corporate management. If the response to the Windows XP scenario posed above is, “Well, that means we could put all of Windows XP onto your wrist watch!”, then ask, “So what?” again. In some cases, the answers will eventually become silly and you’ll be jerked back into the real world. For example, suppose your boss answers the second “So what?” question above with the explanation, “Well, if we can also squeeze in a full voice-recognition system, that means you’ll be able to write Visual C++ programs while you’re walking down the street, by talking to your wrist-watch!”

No doubt there are a few dozen programmers who would say, “Cool!” and volunteer to spend the next three years of their lives on such a project. The fact that nobody in his right mind would ever use such a project is irrelevant to them; the technical challenge is a sufficient justification. Putting Windows XP, full voice recognition, and Visual C++ into 128K of ROM would give you supreme bragging rights at any convention of hackers and programmers; if that’s what you live for, then by all means go ahead and sign up for the project.

It’s also a good idea to explain the project in simplified non-technical terms to your spouse, or your “significant other,” or your parents—or, even better, your children. They will ask the “So what?” question, without the burden of being tempted by the technical challenge. “You’re going to give up your nights and your weekends and your vacations for the next two years in order to put Windows XP on a wrist-watch?” your spouse will ask incredulously. And your children will ask, “Yeah, but Mom/Dad, why would anyone do that?” If you can answer those questions without feeling utterly foolish, then you can sign up for the project with a clear conscience.

A worse form of Mt. Everest project is the one where the challenge matters enormously to corporate management, but not at all to anyone who stops and thinks about the situation for a second. “Why are we signing up for this death march project, boss?” the young programmer asks innocently. “Because,” the boss thunders righteously, “it will increase our corporate earnings per share by a full 3.14159 cents!!” This means that if the programmer was lucky enough to have options on a hundred shares of the company’s stock, and if every penny of increased earnings was paid out in dividends, the programmer would get a whopping $3.14; and if Wall Street traders got so excited by all of this that they boosted the price of the stock by a dollar, the programmer’s net worth would increase by another hundred dollars. “And what else would I have to show for the thousands of hours of overtime you’re asking me to sign up for, boss?” the young programmer asks. The boss is silent, for he knows that the honest answer is: nothing. The project is intrinsically boring, involves no interesting technology, and has a 75-percent chance of failing anyway.

But the very worst death march projects, in my opinion, are the ones where the boss deliberately manipulates the innocent project team into believing that a Mt. Everest-style challenge is involved, when the boss knows full well that it’s not. Imagine the project team member who asks, “Why are we trying to build this batch, mainframe, COBOL airline reservation system in six months, boss?” The boss is likely to respond, “Because nobody in the entire airline industry has ever tried to do it in less than three years before!” I suppose that one could argue that there is a technical challenge involved in creating a batch-mode airline reservation system, but it’s not the kind of technology that I would want on my resumé in the 21st century. In any case, what makes this scenario a death march project is not the technical challenge, but the ridiculous schedule imposed on the project. Why is the project manager doing it? Who knows—but it’s not likely to be the sort of thing you’ll want to brag about to your friends a year from now.