Hoff --

I'm not sure whether I will have the time to weigh in on the doomer side of the debate (and I don't give a fig how that is interpreted or not), but should I, I want to be sure I fully understand your core points. This is not in any way intended as a trap. I have zero stake in a bad Y2K outcome and would gladly applaud your being correct four or five months from now. That said, I remain a doomer at this time. But I understood your points to be:

1. Systems both replaced and remediated have been introduced at least since the beginning of 1998.

2. Using Gartner's estimates for failures during rollover and a range of other statistics (cf Jones), you estimate the percentage of function points that will fail over that twenty-four month period. I won't repeat the numbers here.

3. Taking into account that system implementations being introduced throughout 1999 are more prone to serious problems than applications remediated for simple date errors, you conclude from 1. and 2. that we are already seeing more problems from Y2K than we will see during rollover and, certainly beyond, say, February 2000.

4. To the challenge that only mission-critical systems are being remediated, you reply that this is effectively the only universe that matters (ie, mission-critical = active applications). The bulk of non-mission critical systems are inactive and/or compliant.

5. To the challenge that 1999 errors are only of the harmless "JoAnne" variety, you assert that time machine testing is adequately simulating 2000.

6. The MCI frame relay issue is, in your mind, an example of a system implementation problem, not a paradigm for remediation problems.

7. In your judgment, you chose remediation percentages that should, if anything, favor doomers.

8. To the challenge that Gartner's figures are all wet and/or that organizations are lying or in error on their progress, you declare that this wouldn't matter on a per organization basis. The key is the validity of the (in your mind, unchallenged) pessimistic assumptions that you began with and the analysis of the function points that are failing over 1998 and 1999 (ie, even if Gartner is too optimistic about rollover, the basic analysis holds).

What have I missed? What, if anything, would you want to articulate better than I have so I can go back and reflect on Heller, George, ng preparatory to statements I might want to make?

-- BigDog (BigDog@duffer.com), August 22, 1999

Answers

In general, Bigdog, I'd refer you to the threads for answers.

At the risk of supplying off the cuff answers, though:

1. Systems both replaced and remediated have been introduced at least since the beginning of 1998.

At least. The more important systems are those that have been replaced, and implemented as new systems or development.

2. Using Gartner's estimates for failures during rollover and a range of other statistics (cf Jones), you estimate the percentage of function points that will fail over that twenty-four month period. I won't repeat the numbers here.

Yes.

3. Taking into account that system implementations being introduced throughout 1999 are more prone to serious problems than applications remediated for simple date errors, you conclude from 1. and 2. that we are already seeing more problems from Y2K than we will see during rollover and, certainly beyond, say, February 2000.

I took implementations through 1998 and 1999. But again, you have the essential part of the analysis correct.

4. To the challenge that only mission-critical systems are being remediated, you reply that this is effectively the only universe that matters (ie, mission-critical = active applications). The bulk of non-mission critical systems are inactive and/or compliant.

No. I don't believe only "mission-critical" applications are being remediated. In fact, even a review of the Fed Gov effort shows this.

Yes, a large portion of non-"mission-critical" systems are dormant. But the main problem is the available surveys, and determining just what surveys are asking.

5. To the challenge that 1999 errors are only of the harmless "JoAnne" variety, you assert that time machine testing is adequately simulating 2000.

No. In fact, Gartner estimates that 1999 errors, and in general "forward-looking" errors, will have more impact than "backwards-looking" errors.

6. The MCI frame relay issue is, in your mind, an example of a system implementation problem, not a paradigm for remediation problems.

Basically correct. The thread goes into more detail.

7. In your judgment, you chose remediation percentages that should, if anything, favor doomers.

The remediation percentage was somewhat middle of the road. In other cases, such as the GartnerGroup estimate of rollover errors, I doubled the estimate. Others, such as the implementation error rate, I discounted by 85%.

8. To the challenge that Gartner's figures are all wet and/or that organizations are lying or in error on their progress, you declare that this wouldn't matter on a per organization basis. The key is the validity of the (in your mind, unchallenged) pessimistic assumptions that you began with and the analysis of the function points that are failing over 1998 and 1999 (ie, even if Gartner is too optimistic about rollover, the basic analysis holds).

In some cases, yes. Again, would need to know specifically what you are referring to. As for the remediation percentage, yes, the percentage isn't a precise estimate.

-- Hoffmeister (hoff_meister@my-deja.com), August 22, 1999.

Could you clarify (again, if need be) why you agree with Gartner about forward-looking vs backward-looking errors and what, in fact, you think they mean by that? That should be enough for the purposes of this thread.

-- BigDog (BigDog@duffer.com), August 22, 1999.

Reinterating Heller's points in his summary of Debate 2:

Here's my summary of what this MCI problem tells us that can be extrapolated to give us some insight into Y2K.

1. When a serious software problem occurs involving more than one company, a great deal of finger-pointing will follow.
2. According to at least one press report, Lucent had "certified" the software that failed. If this is true, then we can see that even large companies can claim something is Y2K ready when in fact it is not.
3. Press reports will often contradict one another, leaving us without the information we would need to determine what actually happened.
4. Software problems are often not fixed in "oh, two or three hours", as Cory Hamasaki likes to put it. They can often go on for days or weeks, even when everything else is working.
5. In the case of serious difficulties in updating or installing a piece of software, the "solution" is often to fall back to a previous version of the software. Of course, this will not work after January 1st if the previous version was not Y2K compliant.
6. If you have critical suppliers, the failure of one of them can bring your business to a standstill.
7. It is not always feasible to change to a new supplier even if the failure of your current supplier is endangering your business.
8. You can't count on your suppliers to tell you what they're going to do, even if you could be severely affected by problems they encounter.
9. A failure by one of your supplier's suppliers can affect you just as much as a failure by one of your direct suppliers.

Anyone who can understand these points and not be concerned enough to prepare for potential serious disruptions next year is beyond my ability to convince of anything.

-- a (a@a.a), August 22, 1999.

'a':

If you read Heller's list, you will notice that with the exception of point #5, every single point describes life as we've always known it, and y2k isn't involved with any of those points. Point #5 just says that if there's a total failure, the fallback code may be no better. But what we've always faced is that if your code fails, there may be no fallback code at all (new developments are like that).

And Heller is certainly correct, every organization has always been in danger if either their own operations, or the operations of their supply or customer chains, should go belly up. That's the nature of the free market, and bankruptcies have always been pretty common.

But Heller is now saying that y2k will *cause* these boogeymen to crawl out from under the bed and start strangling us. Hoff doesn't deny the danger, Hoff demonstrates that the *mechanism* isn't there, and asks how it might be there after all. If the best Heller can do is repeat the age-old threats, he has made NO case after all.

Yes, IF someone hits you with a baseball bat, you may suffer broken bones. But when you ask who might hit you, it does NOT answer your question to cite the *number* of bats in existence, or list every vulnerable bone in your body. There's always been a lot of bats, and you've always had the same number of bones, and the actual threat doesn't change just by listing these things.

-- Flint (flintc@mindspring.com), August 22, 1999.

But Heller is now saying that y2k will *cause* these boogeymen to crawl out from under the bed and start strangling us.

Yep. He sure is. Along with Yourdon, Hamasaki, me, and hundreds of other veteran software experts who understand the nature of the problem in minute detail. Our opinion is that a disaster is imminent and we should prepare.

Your opinion differs only in that you think a disaster is not imminent and we should prepare.

Hoff, OTOH, thinks a disaster is not imminent and we should not prepare.

-- a (a@a.a), August 22, 1999.

"Along with Yourdon, Hamasaki, me, and hundreds of other veteran software experts who understand the nature of the problem in minute detail. Our opinion is that a disaster is imminent and we should prepare."

When I first heard about Y2k I didn't want to fall victim to the P.R. hype I knew would be flying fast and furious...I wanted to hear what was going on from the guys and gals in the trenches who knew - firsthand - the *exact* status of the situation. I thank you and your cohorts tremendously for your insight and candor: it's what's made me a confirmed GI, prepping like crazy before the big day.

I admittedly have an occasional Polly-Day, wondering if maybe I'm not insane for turning my back bedroom into a pantry (lol) but the reminders such as yours confirm that I'm acting in the most prudent way possible. Thanks again!

LunaC

-- LunaC (LunaC@moon.com), August 22, 1999.

BigDog, don't know that I completely agree with GartnerGroup on this point. I do agree, however, that you cannot simply write-off date-forward processing as "trivial" compared to date-backward processing.

-- Hoffmeister (hoff_meister@my-deja.com), August 23, 1999.

Perhaps this is already embedded in the foregoing debate above ,but, please remember that the remediated and re-installed software is NOT currently running in a post 2000 environment. Being "remediated" and running now doesn't insure post Y2K. I am specifically thinking first about the underlying systems software that supports the application software. Only a few of the largest orgs have done extensive Time Machine testing. Some parts of some operating systems/support systems will fail in some organizations - and ALL application software at those sites will grind to an abrupt halt. Maybe its a pause of a day, maybe its a week, maybe its longer. Depends on how many super geeks are on vacation. Second, all the remediated application software in ALL the various companies (and diseparate parts of the same Corp) will see Rollover simultaneously. A certain fraction will therefore fail simultaneously. Its not If these things will happen, they will. The real question is magnitude and people resources. If enough geeks (and geekettes) are spooked early then some orgs are toast.

-- RDH (drherr@erols.com), August 23, 1999.

RDH:

Admittedly, there are only a few thousand time-machines out there, but everything I've seen remediated had at the least a separate partition/region of the machine where the appropriate dates WERE tested before moving them into production.

Hoff:

Even if a totally new software package was not installed, in many cases the extent of changes to existing software was significant enough to cause the same sortof problems associated with any other mass modification effort. I've seen programs or transactions not defined in production, or not defined properly, SQL binds not included, etc. As you said, however, these problems are happening TODAY.

a:

I consider myself a software veteran also, and I don't know ONE other veteran that sees Y2k as anything other than a world-wide remediation project. I don't think we can extrapolate on what programmers think based on the reports of those who post to Y2k fora or write books or newsletters. I've said this before, but *I*'m the doomer amongst the veterans in my extended circle simply because I follow Y2k progress/slippage.

-- Anita (spoonera@msn.com), August 23, 1999.