This post is not intended to debate which flaws in what types of systems may be fatal to systems or to people. I am satisfied that 00 flaws in some systems may lead to fatalities.

My curiosity relates to whether FOOFs may still be breeding and multiplying within some systems that are regarded as remediated.

-- Watchful (seethesea@msn.com), March 21, 1999

Answers

Watchful,

As I pointed out in my my "Y2K Projects: Deja Vu All Over Again " article, studies by three different Y2K vendors (Cap Gemini, Reasoning Systems, and MatriDigm) on a total of roughly 50 million lines of Y2K- remediated, fully-tested code showed an average of between 460-900 defects per million lines of code. That's just under one defect per thousand lines of code, which is the same number we've been experiencing for "bad fix" defects for the past 30 years in the software industry.

It's important to emphasize that this was code that had been fully remediated, fully tested, and was ready to be put back into production. As we get closer to the Big Day, I believe that we will see much sloppier testing (Q: "How do you know when you're finished testing?" A: "When you've run out of time!"), and therefore much higher bug rates. If anyone was tracking this stuff on a month-to-month basis, I think we would see a steady increase in bug rates all through 1999...

Ed

-- Ed Yourdon (ed@yourdon.com), March 21, 1999.

There is a high (imho) error rate in code fixing. There is also a high rate of error in initial code.

-- SCOTTY (BLehman202@aol.com), March 21, 1999.

When I first started reading here in November , someone posted that there was some error rates as high as 1 in every 14 lines of "remediated" code. This means before testing, right ? But if programers were only to make. say one error in 100 lines of code, when they tested, wouldn't they then ( by accident ), incorporate 10 more in 1000 lines of tested code ?? Can someone explain how I'm wrong , using the same numbers; right or wrong IMHO. Eagle

-- Harold Walker (e999eagle@freewwweb.com), March 21, 1999.

Thank you for the above answers.I need further clarification about 00 date flaws that may or may not be fatal.

Recognizing that new flaws in code resulting from errors or oversights in remediation activities may be increasing, my question is; are overlooked and remaining two digit date flaws able to continue to multiply within those systems where they still reside?

-- Watchful (seethesea@msn.com), March 21, 1999.

Watchful....

You got me a bit baffled here. Code errors multiplying? On their own or through human intervention. Are you talking about reusable time based libraries? or possibly continued reproduction of 6 digit dates in data?. If its reusable libraries, I think it may be a doulbe edged sword. While one boken date routine may infect a dozen programs, One remediated library could fix a dozen . Anyway, can you clarify the scenarios your referring to.

Ed,

With regard to the question, "How do you know when Y2k testing is done?"

Its been my experience this level is achieved in one of the following instances. In an integrated test (ie more than one system) Its when the guy responsible for signing off on your downstream systems , stops yelling, Your sending me shitty data, and I can sign off till its fixed!!!!.

In a unit test of a single system, its when the end user stops saying, " I refuse to put my name on this signof form cause its still broken."

I dont know how you can cut both edges here with an answer like "It when I run out of time". If that were the case, wouldnt everyone be hitting thier deadlines? Why all the slippage in the dates, if everyones saying there done when they run out of time.

In summary I differ with your assesment on two fronts. My own personal experience and the news clips in this very forum stating that the dates of various companies are slipping.

nyc

-- nyc (nycnyc@hotmail.com), March 21, 1999.

Managerial "deadlines" are on wheels, by default if not by intent.. The Y2K rollover is not.

From what I've read here and elsewhere about IT work, deadlines are seldom if ever met.

-- Tom Carey (tomcarey@mindspring.com), March 22, 1999.