This whole situation (ie. Death Marches, overtime, programmer burnout) reminds me of a Zen parable:

The Faster the Slower

An Eager student ascended the mountains to study the art of swordfighting under a great master. The student asked the master: "Master, if I study diligently, how long will it take me to learn the skills of sword-fighting?" The Master replied, "Ten years, perhaps."

Unsatisfied, the student continued. "My father is an old man and I must return to look after him. What if I work exceptionally hard, then how long will it take me?" The Master replied. "In that case, it will probably take thirty years."

Out of confusion the student said further. "First you said ten years, and now you say thirty. Look, I'm willing to suffer any kind of hardship and sacrifice. I just want to learn it in the shortest time possible." "In that case," the Master explained, "You will have to study with me for seventy

-- Typhon Blue (typhonblue@hotmail.com), July 23, 1999

Answers

Typhon:

As your parable makes clear, there is a way to minimize the time required, though it isn't always the most obvious. Good management is essential, and that management must understand what *not* to do. For example, a programmer's ability to focus degrades seriously after a certain number of hours (varying with programmer). Don't push people beyond diminishing returns. Another example: parts of remediation projects lend themselves to concurrent efforts, and other parts require the efforts of a single person, and any more will just cause confusion and delays (and more bugs). Another example: There is a natural order in which things must be done. Doing things out of this order (giving the illusion of concurrency) only means either going back and doing them right, or having a long long debug/retest cycle.

There is also a theoretical best minimum time required (like the 9 months to make a baby). Attempts to shorten the project below this irreducible minimum will only make things worse. A well-managed project that started too late to finish on time will probably be in better shape at rollover than a poorly managed project that started much earlier, all else being equal.

-- Flint (flintc@mindspring.com), July 23, 1999.

There's a book called "The Mythical Man-month" that addresses this exact phenomenon within the software development industry.

Sadly, in a panic, management has a tendency to do exactly the wrong thing to finish a project - add more bodies.

Jolly

-- Jollyprez (jolly@prez.com), July 23, 1999.

When I first read The Mythical Man-Month a few years ago, the statement that stuck with me was, "More software projects have gone awry for lack of calendar time than for all other causes combined". In fact, geek that I am, I actually made an image of that sentence and used it as my wallpaper for a while.

When I first became "aware" of Y2K last summer, I realized that many of Brooks' insights are critical to understanding how organizations are responding to Y2K. So, I ordered a copy of the book (the one I had read was my project leader's copy), and culled from it the parts of the discussion that I thought most directly relate to Y2K projects.

-- Lane Core Jr. (elcore@sgi.net), July 24, 1999.

Typhon Blue, everyone :

(1) Remediation time is over, up, expired, finito. Many people in this forum don't understand that. In the outside world most people don't even know what we are talking about or what you are asking. This includes remediation of the EMBEDDED CHIPS, subject matter which is conspicuously absent from remediation analysis. I wonder why...

(2) The likelihood of successfull remediation always depended upon testing. Remediation should have finished by December 1998, with a 'full year for testing' (1999). Which would find unremediated bugs which would mean further remediation, with further testing... Thorough, intensive testing (unit testing, interphases, systems testing, supply lines, EDI, you name it and please don't forget the "oohhh, sh*ts!"), simply because the very nature of y2k remediation so requires it.

(3) Many 'remediations' won't be tested though, or not tested thoroughly enough, because of lack of time, budget, people, or willingness, or all of the above.

(4) We are now running out of testing time itself. Actually we have only 100 (theoretical) working days left, simply because as soon as any major y2k-negative event is triggered off the available testing days could be reduced down to far less, including zero. Premature bank runs could cause programmers to "head for the hills" for example. There are other possibilities too... military accidents, faulty GPS induced accidents, etc.

Take care

-- George (jvilches@sminter.com.ar), July 24, 1999.

the parable ends with the master explaining..."concentrating only on your destination,you have no eyes left to find tao(the way)

-- zoobie (zoobiezoob@yahoo.com), July 25, 1999.

Folks, please remember that ALL of the systems will be tested....

Starting 01/01/2000. Real time testing, full networks, supply lines, embeddeds, the whole nine yards.

What has really happened is that, by seriously underestimating the amount of time needed for this "simple" project, almost everyone has chosen this real time testing, also known as Fix-On-Failure.]

-- Jon Williamson (pssomerville@sprintmail.com), July 25, 1999.

Dof hat to that approach: Die On Failure.

-- h (h@h.h), July 25, 1999.