NPR radio just aired a commentary by Gary Beach, of CIO Magazine. He stated that up to one in every four lines of supposedly fixed code could be bad because of human error. And: how humans react to Y2K during the rollover and beyond will be the big issue, he guessed.

Although the human reaction part is pretty much cookie cutter, I wonder if Joe Sixpack caught the significance of the "one bad line in every four lines of code" and the possible impact that might have on his Sunday bowl games?

-- (troubles@coming.com), December 27, 1999

Answers

I heard that, too. It gave me a chill since this guy was trying to be reassuring about how smart programmers are......how they didn't create the Y2K crisis because they are stupid.

-- Lara (nprbuff@hotmail.com), December 27, 1999.

1 in 4 lines of code bad.....Sorry, this smells funny or at least misleading....

I suppose if you use peoples ignorance of how programs work you could almost make an exagerated claim like that........i.e. one line isn't correct so the next 200 lines don't function properly......therefore you say that the whole subroutine of 201 lines is faulty and all needs correcting.........

In reality most programs that have problems can be fixed relatively quickly.....in some cases, if a program is severly buggered up it may need to be rewritten completely........

But I don't know a programmer anywhere who has 1 in 4 lines that are incorrect and still has a job!

-- Craig (craig@ccinet.ab.ca), December 27, 1999.

troubles -

Which NPR show was that on? NPR News, All Things Considered, The World, other?

-- Mac (sneak@lurk.com), December 27, 1999.

Mac,

I heard it in the second hour of All Things Considered (4p.m. Central).

It comes right after a polly piece on Japan's y2k compliance. NPR's been doing a y2k story a day on ATC ... but they are often style over substance.

There's no there there.

-- Lara (nprbuff@hotmail.com), December 27, 1999.

Check that, found it listed for All Things Considered, about 40 minutes into the program (and right after a "Y2K Japan" report):

Y2K in Japan -- Japan is one of many Asian nations which got a late start preparing for the Y2K bug. Y2K glitches in the world's 2nd largest economy could be felt globally. NPR's Eric Weiner reports from Tokyo how Japanese corporations and Government agencies have been frantically trying to catch up the last few months. The country's Prime Minister has declared Japan as officially Y2K compliant. (5:30) Debunking the Millennium Bug -- Commentary Gary Beach, publisher of CIO magazine, says that the origin of the Y2K bug is not what most people believe. (3:00)

Thanks for the heads-up. I'll listen this evening with great interest.

-- Mac (sneak@lurk.com), December 27, 1999.

In some cases, if you count the errors introduced in the remediation process the number is higher-in MOST cases it is considerably lower. Financial services sector did the best job, averaging 80 lines per M unfound dates(remember that dates comprise a very small fraction of all lines of code and in some cases they are entirely unimportant and in others critical with a capital C. Average in sectors other than financial was 550-600 unfound date data formats. As a percentage of the total number of dates this is inarguably unacceptably high. What has always rendered me speechless is the belief(widely held amongst most programmers) that they'll be able to find in a few days or few weeks what they couldn't find in 2 years. The reason they didn't find them in the first place is that they are a bitch to find-period. They are expressed in ways that are IMPOSSIBLE to find using the standard case tools and business rules. Only a highly developed automated tool can apply the 17,000+ business rules NECESSARY to find ALL the dates. We're screwed-count on it. By the way, this information comes directly from the gentleman who was the chief OS390 architect.

-- Blew5M (gaf@mindspring.com), December 27, 1999.

Craig -

I don't know many PMs who can have their major projects blow through critical deadlines like tissue and still keep their jobs, but that's what's happening (with the occasional exception of, say, the Y2K PM for SSA, who actually bailed out.) What are they going to do, fire them? Unlikely.

Perhaps Mr. Beach's 1-in-4 number is simply another way of stating that 25% of total remediated code may be faulty. Since there has been a fair amount of deathmarch work on Y2K and "the last 10% of the code takes the other 90% of the schedule", that seems a pretty reasonable estimate for overall code quality. Fixes have been and will continue to be slammed into place, come Hell or high water. Unit testing has been combined with system, integration, release, and Beta testing into one grand "go live" test. Saves time, doncha know?

As noted elsewhere, the majority of organizations are at SEI Maturity Level 1, meaning they have essentially "ad hoc" development processes. The code will reflect this.

-- Mac (sneak@lurk.com), December 27, 1999.

A co-worker of mine spent last evening reviewing code that had one error that was causing a glitch. It took three people looking thru less than 3000 (no that's not a misprint)lines of code. They found the error at 5:00AM (they started at 11:15PM when they were alerted that there was a problem. Bye the way, they wrote the code, and it was only a simple subroutine, so they thought. I think we are in "for a wee bit of trouble" in the not to distant future.

-- Michael (michaelteever@buffalo.com), December 27, 1999.

I doubt those who aren't programmers can really plumb the depths of what computers can do, regardless of the programmers' intentions. An old saying among programmers is "Computers are dumber than people, but smarter than programmers".

The vast majority of errors programmers make are "head slappers", obvious (and easily fixed) errors that show up the very first time a routine is run (which had damn well better not be in production -- any sane programmer writes a bit of code, tests basic functionality, and writes another bit, etc.)

And any programmer can tell you about the time they spent weeks tracking down a bug. Some bugs are very well hidden, especially those that rarely happen and are impossible to replicate. It doesn't help that the eventual symptoms bear no relation to what started the chain of internal errors in the first place -- that is, the bug itself.

Still, one line in four being bad *as originally fixed* is simply lousy programming. One line in four *still* in error after initial sanity testing and unit testing and back into production is terrible management. Unfortunately, bad managers hire bad programmers.

-- Flint (flintc@mindspring.com), December 27, 1999.

FWIW, one bad line per four lines of compiled code seems to me to be implausible even for novices just out of training.

Jerry

-- Jerry B (skeptic76@erols.com), December 27, 1999.

Hi Troubles,

It's not so far fetched nor are errors necessarily significant. I haven't been hanging around this forum much lately but earlier this year put in my 2 cents now and then. (I got drafted back to the trenches fixing code - from mananging our Y2K project - because I was one of the 2 remaining staff who had any experience in the languages used in a problem system.

Recently I got some of my work back - it had errors. (It couldn't be I had tested it myself!) When someone else tested my work they just hit enter without entering any dates... and the procs blew up.

What happened? I was so focused on making sure the date routines were correct, so busy testing the date handling, I overlooked an obvious. I know better. I done this too long not to. But Y2K work is routine, boring, and easily becomes mindlessly mechanical. The date stuff worked fine but someone failing to enter a date screwed it up.

So yes problems can happen but the probability of those error and effect need to be considered. In this case, individuals using these procs are highly unlike to hit enter without putting in a date - they have used them too long not to. But technically there was an error.... so I fixed things.

Remember that ultimately a coding error only is consequential if the code is executed.

Good luck jh

-- John Hebert (jt_hebert@hotmail.com), December 28, 1999.

In case anyone would like to listen to Mr. Beach's commentary, here's a link to the "All Things Considered" archive of the 12/27/1999 show.

Note: requires RealAudio.

-- Mac (sneak@lurk.com), December 28, 1999.