This from ComputerWorld

____

Study: 9% of all software still has Y2K errors By Thomas Hoffman

Based on an analysis of 60 million lines of code reviewed by San Jose-based Matridigm Corp., 9% of all programs still contain year 2000 errors, and on average, 185 errors per million lines of code (MLOC) were discovered.

Among industries represented, the financial services sector averaged the fewest errors -- 141 glitches per MLOC. Code from the U.S. government and other vertical industries experienced a higher error rate.

____

Interesting that the way it is phrased: banking "still" has year 2000 errors.

Also, notice the error rate found in the latest SEC "almost-integrated" "almost-universal" securities (stock market) test. 98.5% were successful - remarkably close to the usual 3% of errors "expected" lef tin programs AFTER changes are made.

Again, the fundemental predictions made by Ed (aand Cory and others) last year remain frightenly true: lots of predictions of success, little actual testing - and that testing partial and not covering all companies or agencies, and no clear direction nor guidance from the government. Changes made to the programs causing more errors....

-- Robert A Cook, PE (Kennesaw, GA) (cook.r@csaatl.com), July 22, 1999

Answers

Gawd, such terrible scaremongering from COMPUTERWORLD. What ominous scare story are they going to run next? Some doomer trash like, "Y2K Is Systemic - Cannot Be Fixed"???

-- King of Spain (madrid@aol.com), July 22, 1999.

...and the FY2000 will apex sometime in mid-July causing havok to third world countries. The Jo Ann Effect will build up and small businesses, banks and finacial institutions will stagger backwards bankrupt from the y2k induced computer erros, nose bloodied, going "huh", "wha was that??".

(Just more "fundemental predictions from Ed and Cory")

Note to readers: We are now past Mid-July

-- (doomers@suck.com), July 22, 1999.

Tick Tock-Tick Tock

-- Mike Lang (webflier@erols.com), July 22, 1999.

OK, serious question for the techies from a non-geek: How bad is 185 errors per MLOC compared with a normal, day-to-day error rate that wouldn't cause anything to melt down?

-- Thinman (thinman38@hotmail.com), July 22, 1999.

To the polly's responding: What if you're wrong? Then what? What will you eat if we do have some disruptions? I have a supply of food and if not much happens, well, then I'll have fun eating.

I've had to go through and fix y2k problems at my company. It was a tremendous job. I was busy working hard, fixing code while mostly everybody was ridiculing me (with those snickering smiles, you know). Today, none of my programs are blowing up. Our fiscal year ended in Feb, so March was the beginning of fiscal 2000. No problems were found. And so again, I still get those people even in my own agency telling me I'm overblowing the problem because we've had no failures yet. Knowing what I know now, I should have said I was working on it, but not fix a thing, then I should have quit just before the problems were to begin. The system would have been down for months. There wouldn't be any smiles then. This is just a fantasy. I probably can't bring myself to do this, but I keep thinking how those idiots scoffed at me when I a saw a genuine problem and was concerned. They quickly forgot how hard I had to work to take care of this mess. It's working because I wasn't in denial. No problems have been found because they were the first programs I worked on. I tested and tested these programs. Furthermore, these programs are only 5% or so of all the programs out there. Is this an indication of things to come? Of course not! Even so, when I saw the work that was ahead of me around 1994, I didn't like what I saw and it motivated me to get busy and fix the code. As time went on, I did complete all the fixes. This didn't happen until Jan 1999, 5 years later. We had to wait for our software vendor before we could make the rest of our changes. I can tell you, that if our software vendor didn't come through, we would be through in 2000. It would have been the end of the world for this agency. Usually, I find it's mostly non-programmers that proclaim it's no problem. It's easy to say this when you don't work on this.

-- Larry (cobol.programmer@usa.net), July 22, 1999.

Come on Robert you know better than that. Ed was just quoting software metrics available from a wide variety of sources. Ed didn't make any predictions he just look at Gartner Group, Dr. Howard Rubin and other such companies about these metrics. He just quoted these sources and you mistakenly attribute these numbers to Ed. Did you loose the by line?

Anyway, of course code put back into production has errors in it, nothing new here. And further these IV&V companies are expected to find errors but guess what... The majority of errors found are not critical.

Most errors found (in my case) pertain to outdated code and "criteria" that was incorrectly stated. The IV&V vendor need info from the company on their remediation techniques and other Y2K related data. Sometimes when they translate that into their product to find errors, it comes up with mistaken fixes. But upon closer examination, you'll find that it was the product's misinterpretation of the data not actual code errors.

Now does anyone else have any real life experiences in this area?

-- Maria (anon@ymous.com), July 22, 1999.

To Thinman: It only takes 1 bug to cause chaos in a system. I can remember a time when I had one line of code accidently commented out. It prevented data from being properly validated. The data entry people wound up keying in all kinds of bad data (because it wasn't being checked). Financial reports were all screwed up. We were uncertain how much money we were actually making. It was a cascading effect. Because one program was screwed up, bad data was fed to all the others in the system. It took us a long time to fix the mess.

-- Larry (cobol.programmer@usa.net), July 22, 1999.

"Furthermore, these programs are only 5% or so of all the programs out there."

Thank you Larry, for being yet another person to confirm what I have been saying all along! <:)=

PS - And again, how many embedded systems do look-ahead processing???

-- Sysman (y2kboard@yahoo.com), July 22, 1999.

To Maria: I don't have any statistics, but I can tell you in my 20 years of DP experience, errors are introducted when changes are made, especially extensive ones. Y2K fits this category. Again, this is why testing is essential. If adequate testing is done, then it's possible that few problems will arise. My feeling is that the testing phase is going to be short-changed. I know this, because fixes are still going on. To the public, they think fixing is ok. When I hear it, at this late stage, I know it spells trouble.

-- Larry (cobol.programmer@usa.net), July 22, 1999.

To Sysman: PS - And again, how many embedded systems do look-ahead processing???

This isn't my area, processors, chips and so on. I'm pretty much an application programmer. However, 18 years ago, I did do some mico- computer repair work on the Z-89 and z-90 micro-computers. This was when we had 48K. I also worked on an old IBM system 3, complete with 512K for a mainframe! Talk about a system with dates! And converting this stuff, forget it. So, I've been around.

Your question is a good one and one that I've thought about. Unfortunately I can't answer it, nor have I seen anything on the net about this. And I've studied this subject for over 1000 hours.

-- Larry (cobol.programmer@usa.net), July 22, 1999.

Thanks for some good replies, Larry.

OK, serious question for the techies from a non-geek: How bad is 185 errors per MLOC compared with a normal, day-to-day error rate that wouldn't cause anything to melt down?

I don't think there's an answer to that question, Thinman, because I think the statistic is misleading because it's so specific. What kind of code are they talking about? COBOL? C++? Visual Basic? Assembler? Comparing LOC among them is pretty much useless.

Besides, a system can have a thousand bugs that don't matter much, but one or two that can really screw things up big time. All bugs are not equal.

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

The significant "numbers" can't be reported: errors that will result from non-mission critical systems that were actually mission-critical; non-mission critical systems that bring down mission-critical systems and the millions of mission-critical systems from SMEs that were left for FOF.

Otherwise, I agree with Robert, Lane and Larry.

In simple terms for non-techies, "we're hosed." Everything critical will get fixed by entities that survive. I'm guessing 2005 for returning to computing as it was in 1999.

Barring Infomagic, I'll have work coming out of my ears for the next five years. Regrettably.

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

Hi Larry,

Yes, thanks for your comments. My embedded question wasn't really directed at you. It's just one more thing that the polly crowd "forgets" when they talk about lack of early failures. <:)=

-- Sysman (y2kboard@yahoo.com), July 22, 1999.

Lane:

It seems we FINALLY agree on something. "Besides, a system can have a thousand bugs that don't matter much, but one or two that can really screw things up big time. All bugs are not equal."

I've NEVER worked a contract wherein I didn't find AT LEAST one bug in EVERY program. Obviously they weren't show-stoppers, or the company/municipality would have gone out of business long before I showed up. There also WERE show-stopppers (as Larry mentioned), and it wasn't fun to spend weekends working on those, going to backup after backup before we found the origin of the problem. Once we found the problem, however, we managed to resolve it using those quick little one-time programs we code so often, not to mention resolving the problem in the code that caused the problem.

It's clear that my thoughts on remediation outcome differ completely from those of you, or Big Dog. I can only base my thoughts on my experiences...20 years at various large companies, and over 10 years contracting. I've only rarely seen the incompetence of which you and Big Dog refer. These incompetent folks were always fired within two weeks' time. I guess we'll just have to agree to disagree.

-- Anita (spoonera@msn.com), July 22, 1999.

I'll agree with the point that throwing numbers out there are is almost close to useless.

If anything, it could give the public a false sense of security. When we think 90% range, or close, we think of an A in school. It is human nature to think like this. But thinking technical, the computer won't care if 99.9% of the code is right. If it hits a faulty line of code that is critical, there's no telling what will happen. How many other programs read data from the program that produced the error and do any of these programs send data to other files, databases, programs or systems? It all goes back to the interconnectiveness of programs and systems. This is why some experience programmers are concerned. We know these things and we're terrified for good reasons.

So, even if we say 95% of the code in the World's is fixed (fantasyworld), we've still got a very big problem depending on what kind of bugs are still out there. As Lane pointed out, "All bugs aren't created equal."

This is why I always tell all my family and friends to prepare. I always say I hope it won't be a breakdown, but even if we manage to get electricity, water, sewage, gas, oil, telephones and so on, we don't know how expensive these things will be or if we'll even be able to keep our jobs in 2000 to pay for these things. What will you do if you don't have food stocked up (among other things) and your funds are dwindling fast?

-- Larry (cobol.programmer@usa.net), July 22, 1999.

" For example, he said the USS Atlanta sent out an equipment request and it was tracked across the entire procurement system. Cohen said there was only one failure in 200 million lines of computer code and that has been fixed. "

(From two threads up)

(snip)

Study: 9% of all software still has Y2K errors By Thomas Hoffman

Based on an analysis of 60 million lines of code reviewed by San Jose- based Matridigm Corp., 9% of all programs still contain year 2000 errors, and on average, 185 errors per million lines of code (MLOC) were discovered.

(end snip)

Now it seems to me that the military must be included in that phrase "all software". So which is it, 185 errors per MLOC or only 1 in 200 MLOC? 185 and 1 is alot different. Hoffman said ALL SOFTWARE, remediated and unremediated I take it. So there can't be a discrepency between the typed of code or where they are found. Hoffman said ALL SOFTWARE. It's all included in the same report right?

So which is it? 185 per million or 1 per 200 million. Sounds to me that one of these reports is grossly misjudged. I'm guessing Hoffman doesn't know what the heck he is talking about and he is only looking at a tiny portion of whatever code fits his theory.

I'm also thinking that Ed's 90% drop in the Dow Jones Average is grossly misjudged too. By the way Ed, when was that supposed to happen again? I know your not real good with specific dates and all but could you at least give us a year? Maybe within the next decade perhaps? Or sometime before the year 3000? I guess I'll just wait for the telltale signs of Invisible Failures. Oh no wait I can't , I won't see them. Damnit, how am I supposed to find Doom and Gloom when I can't get any real good failures to brag about?

I guess I'll just have to wing it, like you do.

-- (doomers@suck.com), July 22, 1999.

Robert, Honorable Mr.Sucks, everyone, I urge you to go to the following hot link

http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id= 0016Cp

where this very same subject matter was analyzed deeply and exhaustively, believe me. Furthermore, if you wish to see the nitty- gritty details (intersting, although not really needed) the original Matridigm paper was posted by GN under "Compliance" category a week or so ago.

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

---

Moderation questions? read the FAQ