How (not just what) do we learn from Y2K? : LUSENET : TimeBomb 2000 (Y2000) : One Thread

And, I'll admit, I don't mean "we" in the broadest sense. I mean "we" in terms of those of us who have made a career out of technology. First, some "what" questions.

For technical project managers: What do Y2K projects tell us about technical project management that other projects might not have? How did so many projects get completed in time when historical data shows that the industry hardly ever gets such things done on time? Were there cases where Brooks' Law didn't apply, and adding more people to a late project sped it up rather than made it later? Did we get an accurate cost of Y2K, and if so how did it compare to our estimates? What remains to be done, and why hasn't it been done yet?

For technicians (the ones really doing the work): What design lessons can we learn from Y2K problems and fixes? Have we finally reached a point where adequate resources are not a consideration in a systems' design but instead can be taken for granted? How hard was it to find all those date references and how did we do it? Were more or fewer bugs than normal still present when we tested? What percentage of new code added new bugs in areas that were already working?

For business management? Did system replacement projects go off as planned, and did they solve the problems? Moreover, did they introduce problems bigger than the ones they solved? Is there going to be a corporate mandate to design long-term software from now on and not just something to suit our current needs? Do you have a realistic estimate of the costs of Y2K, both in terms of what you spent and what the damage could have been if you didn't spend the money?

Now, for the harder part. How do we answer those (and many, many other) questions in a reliable manner? Ask around, and I'm sure you will find that most everybody has an opinion as to the answers, but how can we approach the questions in a systematic way such that the answers will be based on more than "I think that..."

-- Paul Neuhardt (, January 04, 2000


Thoughtful questions require thoughtful answers. So, understandably, no answers yet, but I will keep checking.

Meanwhile, as a pedestrian, I have a few questions. (Bear with me, and I'm sorry if these are ignorant ones, but I'm quite curious.)

Brook's Law: What percentage of the projects that moreless comprise the generally accepted Brook's Law are projects with moveable deadlines? Deadlines that are really sink-or-swim with do-or-die consequences? Any guesstimates?

For example, are software projects with moveable deadlines calculated in this law? Where can I find this information, if it exists?

Although technology project methodology is still in its relatively nascent stages, does this y2k success (or seeming success, so far) suggest that the project methodology has been somewhat solved?

(By the way. Thanks for one spectacular fix you guys pulled off.)

-- (resolved@this.point), January 04, 2000.

resolved, you asked:

"Brook's Law: What percentage of the projects that moreless comprise the generally accepted Brook's Law are projects with moveable deadlines? Deadlines that are really sink-or-swim with do-or-die consequences? Any guesstimates?"

In my experience (16 years) this is the first project that didn't have a moveable deadline. Oh sure, senior managers railed at me in times past that "this schedule cannot slip," but the fact of the matter is that nothing terrible happened when the deadlines were not met. Nobody I worked with ever lost their job over it, and no serious finaincial loss ever ensued. Yes, these things do happen, but not all that often. And while I have never worked on systems that could have directly caused injury or death had they failed, if those systems are not right they are not deployed until it is believed that they are, deadlines or no.

Now, with Y2K, terrible things could indeed have happened if deadlines were not met and the deadline could not be postponed. Furthermore, contrary to popular wisdom, the deadline was not necessarily 1/1/2000 but was often earlier.

One of the great opportunities we have here is a common bond among those of us who worked as project managers during this time. Remediation projects all had the same basic goal and the same basic parameters: Keep existing systems working at least as well as they have in the past while properly handling the century date change problem. and, most of these projects would appear to have had a high degree of success in meeting their goals. The trick will be sharing information on how this was accomplished, disseminating the knowledge gained and then applying that knowledge to future technology projects.

If we can do that, we in software engineering may actually begin to have a legitimate claim to being an engineering discipline. As it stnads now, we are engineers in name only. (And we gave ourselves the name!)

-- Paul Neuhardt (, January 05, 2000.

Moderation questions? read the FAQ