The Three Legged Stool / y2k Fixes Breed New Bugs : LUSENET : TimeBomb 2000 (Y2000) : One Thread

Yourden is quoted in this article from the Chicago Tribune Several times. From Feb.15, 1999

Here is the address:,1714,biztech,00.html


By James Coates Tribune Computer Writer Monday, February 15, 1999

As just about anybody who ever tried to level a crooked 3-legged stool using a handsaw can tell the world, sometimes trying to fix a problem just makes it worse.

You saw off the leg you think is too long, and then it's too short. So you trim down the other two legs to match the first boo boo. Now you've got a stool that still wobbles but now it's too short as well as unstable.

The parable of the milking stool and the handsaw is cited frequently to describe the situation as computer experts realize that the very weapons they use to fight the Millennium Bug are, themselves, buggy.

"Bad fixes," as computer professionals have taken to calling them, are emerging as a major source of concern as the world's computer programmers scramble to unsnarl all the hardware and software built and programmed to keep track of years by the last two digits only.

This system collapses with potentially dire results when computers can't distinguish 1900 from 2000 as their internal clocks move past midnight, Dec. 31, 1999.

There are lots of ways to patch the software and fix that glitch--but the fix itself often inflicts another problem.

"Bad fixes are something that must be expected any time that you take on programming at the amazing levels of intensity that the current crisis is creating," said Edward Yourdon, chairman of the Cutter Consortium, a company of information technology experts specializing in the Millennium Bug.

For example:

Mica Hill of Las Vegas said he encountered the milking stool problem in January when he and a group of partners developed a program called Shelter Harbor 2000, designed to let personal computer owners insert a floppy disk in their machines and test them for Millennium Bug problems.

The bug fix software worked by setting the computer's date forward to after Jan. 1, 2000 and then examining how the machine and its software handled the event. The software performed its task perfectly, creating a printed report showing exactly how each machine handled the transition from the 20th Century to the 21st.

But Hill said he was dismayed when between 20 and 25 of his first customers found that using the Y2K disk triggered a virus called Monkey V that had been lurking in each machine, waiting for a trigger date to pass. Once the machine's clock was moved forward to 2000, it assumed that the date had passed.

The virus locked up many of the computers and could have done worse damage still if the testers hadn't complained to Hill's company, where programmers quickly found the problem.

"We spent a very large amount of effort trying to think of everything and prepare to handle all possible pitfalls, but we didn't come up with the idea that hackers are out there writing virus programs designed to kick in when the Year 2000 turnover happens," Hill said.

Failing to anticipate that the bug fix might trigger a virus attack could have been a bigger problem than the one it was supposed to eradicate had Hill's company not acted in time.

The latest studies of the bad fix problem by such research houses as Cap Gemini, MatriDigm and Reasoning Systems have shown rates as high as 1,200 bad fixes per 100,000 lines of computer code repaired, noted Y2K expert Yourdon.

"While this error rate is pretty close to the error rate of regular programming projects, it is quite serious because in the case of Y2K we have a fast approaching deadline to finish the fixes and get them right," Yourdon said.

The problem with bugs in bug fixes is expected to reach crisis stage between July and September, as the computer establishment orders a lockdown of any further repairs and equipment replacement to allow time to focus on making sure that what experts say is fixed really is fixed.

Analysts at Forrester Research Inc. in Cambridge, Mass., predicted last month that the 11th hour shakedown to iron out bugs will be so extreme that much of the traditional industry will come to a standstill as companies and governmental bodies stop creating new software and buying new equipment while they work furiously to make sure what they already have is ready for the deadline.

Noting, for example, that desktop PC sales are up a record $55 million right now, Forrester warned, "But this demand will stall in late 1999, causing corporate PC purchases to decline for the first time in 10 years."

The prediction was made after Forrester analysts interviewed executives at 50 Fortune 1000 companies about their 1999 plans.

On the software side, a recent survey by the trade journal InfoWorld found corporate technology officers at companies including Northrup Grumman Corp. and Gannett Inc. saying they will put off all major new software purchases and upgrades until well beyond the January rollover.

Speculation is rife that Microsoft Corp. has delayed its plans to ship the new Windows 2000 operating system out of fear that it will meet with tepid demand because customers are obsessed with fixing what they already have rather than trying something new.

With only a few months remaining before the Year 2000 deadline arrives, the problem of bugs worming their way into Y2K bug fixes are becoming a major part of what often amounts to Herculean efforts to repair billions of dollars worth of computer code.

Experts point to three major ways that bug fixes can become bug-ridden themselves:

- Programmers hatch new bugs simply by making ordinary mistakes--typing the wrong word for a command or ordering the software to jump to the wrong routine. In these cases, the problem is replacing software that doesn't know the right date but otherwise works fine with software that knows the correct date but has new internal problems to jam up the works.

The Federal Aviation Administration found this out the hard way in 1997, when its programmers missed large numbers of flawed instructions while combing through the millions of lines of software code in the Enhanced Traffic Management System designed to spot major traffic bottlenecks.

As a result, after the FAA's software reported that the ETMS setup was fully fixed, it crashed during the first test and a subsequent analysis found that 150,000 lines of software had to be rewritten.

- Programmers write remedial software that works fine internally but that is based on faulty assumptions.

Such a bug is written into Microsoft Windows 98, which is supposed to automatically detect the start of daylight-saving time and advance the computer's clock one hour. But the software will fail to note daylight-saving in 2001 because the algorithm for keeping dates in Windows 98 assumes that the changeover happens on the first Sunday after the first Monday in April when, in fact, Sunday, April 1, 2001, will mark daylight saving.

This error was written into Windows 98 as part of Microsoft's massive effort to make the operating system as a whole Y2K compliant.

- As was the case with Shelter Harbor 2000, programmers sometimes fail to anticipate problems when one part of the programs they fix interacts unexpectedly with other features in the same system.

The U.S. Labor Department encountered this sort of bug in early January when a problem with a Y2K fix in the department's Internet software caused it to release the widely followed data for the producer price index one day earlier than it should have been sent out.

Most industry observers agree that these cases are the tip of an iceberg of bad fixes that either will be found and fixed quietly or that will slop through and cause problems when the millennium arrives.

Most also agree that because of legal liability issues, much of the drama unfolding as the programmers reach their Y2K end game will be kept under wraps.

Richard Balough, a Chicago attorney specializing in Y2K issues, noted that a large number of consulting companies involved in fixing Y2K problems have stopped guaranteeing their work at least partly out of concern that they can't catch all their bad fixes quickly enough.

Balough explained: "As we get closer to the Year 2000, companies that are making repairs and fixes are trying to get clients to sign agreements that have no warranties or performance standards.

"In other words, the company is selling its services as is with no warranties or are trying to disclaim any responsibility. Since this document will affect legal responsibilities, it should be carefully drafted and reviewed by a lawyer."

Yourdon agreed that legal skittishness will make the bad fix saga a difficult one to follow.

"This is not something the Fortune 500s are going to be calling the Chicago Tribune to admit to, but it's one of the last big hurdles to the huge efforts to be ready for the deadline," said Yourdon, whose book "Time Bomb 2000" (written with his daughter, Jennifer Yourdon) has become a best seller.

"If all goes well, you'll never hear about the bulk of the bad fixes that are getting written even as we speak. If all doesn't go so well, it will make for some interesting reading some time in the next century," he added.

Some time in the next century, tee hee,tee hee.0;-)

-- Deborah the Prophetess (, February 16, 1999


Good link - thanks - of course when things go tits up next year we won't know what exactly happened - no dial tone, power, teeveee, radio.......

-- Andy (, February 16, 1999.

Could go penis up too.

-- Feminist (, February 16, 1999.

Very powerful article from the Chicago Tribune! Thanks Deborah.

Just think of all the buggy software we got in normal times when programmers weren't so pressured. This messing around with the entire code now taking place in western countries, all at the same time, under pressure...

...and I don't believe in miracles.

-- Chris (, February 16, 1999.

The article is great, the analogy is terrible.

Three points define a plane......a three legged stool is uncondintionally stable, no matter where you set it. It's when you add the forth leg that you get in trouble.

-- De (, February 16, 1999.

Moderation questions? read the FAQ