Year 2000  The Butterfly Effect

In fiction, a well-used clichi notes that poison administered slowly and in small amounts is invariably fatal. And usually undetected until its too late. In engineering, minute failures accumulate until a bridge collapses or a plant shuts down. In business, examples of the cumulative effects of unintended consequences abound in lost markets, damaged careers, failed products, bankruptcy and endless litigation. A simple act or omission, repeated countless times, ripples and grows as the days pass  until the results become uncontrollable and immense. This is an example of the Butterfly Effect  a butterfly flaps its wings in Singapore and we get rain instead of sunshine in Central Park.

Known Year 2000 impacts are classic examples of this Effect, which is also known as the Law of Unintended Consequences. Before or after 2000 arrives, far too many organizations that thought their software applications and embedded systems were fixed and successfully tested will experience varying levels of disruption. Vendors who relied on conventional wisdom about Year 2000 will find that their tools did not perform as well as they thought. Service providers will face angry and litigious clients who believed that their systems and equipment were totally fixed.

For all the discussions about how we have broken the back of Year 2000 in both software and embedded systems, you begin to get the impression of a growing unease. For those who are interested in hearing, faint murmurings are beginning to rise from within numerous organizations. They are not coming from management, vendors or media. They are coming from programmers and engineers deep within the Year 2000 projects. All our work, our automated tools and our project management expertise has not fixed the Year 2000 Problem in its entirety. We have accomplished some fixes, and will accomplish more fixes, but will it be enough and have we gotten all of them?

One major cause of this unease has been the reluctance of Senior Management to get involved in Year 2000 Projects. The overall feeling among those Senior Managers that do not want to get involved is that A Project Manager or outsourcing firm has been hired to perform the Year 2000 Project; therefore, there is no problem. Although the Project Team is struggling, Senior Management is announcing to the world that This company is (or will be) Year 2000 Compliant.

Most of the software tests being accomplished are showing inadequately repaired software. And most organizations are not accomplishing anywhere near the number or types of tests that are required to fully exercise remediated software. Many of the unit and system tests are showing inadequately remediated embedded devices and systems. And many Year 2000 Projects are unable to perform end-to-end tests that might show up even more problems. Because of our inability or unwillingness to develop and perform adequate tests, many (if not most) of our organizations will have inadequately remediated IT and embedded systems. Such inadequately remediated software, in IT and embedded systems, is going to produce erroneous and unintended results. Or it will just stop because the internal logic cannot handle one or more of the date transitions. External programs and data will corrupt systems that were remediated  but remain too fragile and ill understood to survive the Year 2000 assault. Contingency plans, disaster recovery schemes and Year 2000 SWAT Teams may turn out to be less than adequate for the task since the essential technical understanding of the systems and equipment was not there in the first place. If you do not understand your software, whether in IT or embedded systems, you cannot fix it; you cannot completely test it; you cannot adequately maintain or migrate it; and you cannot make it completely Year 2000 Ready.

Interesting Article #1: Y2K may delay some payrolls

Thursday, April 29, 1999, By LOUIS LAVELLE

Paychecks and benefits for many employees may be delayed after the new year as a result of year 2000 computer problems, a survey released Wednesday found. The poll, by the Philadelphia-based consulting firm Towers Perrin, found that nearly three out of four companies have not completed year 2000 testing of their human-resource systems. Of those, one in three isn't even halfway there yet. The year 2000 computer problem is the result of many computers' inability to recognize dates after Dec. 31. Some say misinterpreting those dates will cause some computers to fail.

Tom Keebler, a Towers Perrin principal who conducted the survey, said the lack of preparedness in repairing human-resource systems is cause for concern. "There are a lot of employers who are still behind the curve," he said. "Having something completed in a December time frame is cutting it very close." The survey of 80 firms, which collectively employ more than 2 million workers, found that the computers that control human-resource functions at 27 percent of the firms already are Y2K compliant, with all necessary repairs completed and tested.

Twenty-eight percent of the companies surveyed said they plan to be Y2K compliant by June 30, while 34 percent said they'd be ready by Sept. 30 and 11 percent said they'd be ready by Dec. 31. Keebler said those target completion dates represent company "estimates," and that those who fail to meet the Dec. 31 deadline could find themselves unable to issue checks or coordinate employee benefits in the first weeks or months of the new millennium.

Beyond the issue of employee payroll, Keebler said companies that are not ready by Jan. 1 run the risk of causing problems for "downstream" computers that rely on payroll data, such as those used by insurance companies and fund managers for 401(k) plans.

"It's definitely not a cause for panic," he said. "But it is definitely a concern as far as how much attention companies are paying to the traditionally more behind-the-scenes systems like payroll."

Kerry Gerontianos, president of Incremax Technologies, a New York software services company that helps businesses resolve Y2K problems, said small companies that don't outsource payroll functions to other companies are much more vulnerable to Y2K disruptions than the large companies surveyed by Towers Perrin.

Gerontianos, who has been conducting a nationwide series of seminars on the impact of Y2K on small businesses, said many of those companies could wind up writing payroll checks by hand. "We see a very sharp divide," he said. "While they're not 100 percent ready, [large companies] will all be where they should be by the turn of the century. Small businesses look at this as a non-issue. Could there be problems? Absolutely. There are probably some companies that haven't started thinking about it."

With eight months to go, corporations, public utilities, and government agencies are struggling to resolve their Y2K problems in time.

How many of us have deep, accurate and complete multi-system, multi-platform, multi-language and internal-enterprise understanding of all of our application software, IT systems, embedded systems and equipment and infrastructures?

The scope, size and complexity of the Year 2000 Problem continues to expand. While mainframe and midrange software applications are still the primary focus of most Year 2000 efforts, embedded systems and equipment, client/server applications, networks, public and private infrastructures and personal computers have now been added to the mix. The IT industry, and most engineering vendors, have an almost unbroken record of missing delivery dates and overrunning budgets, yet many organizations, through their public and even private statements, continue to believe that the Year 2000 Problem is under control or that their Projects are on schedule. From what I am hearing through personnel involved in audits and tests, Senior Managers, rather than announcing the upcoming success story, should be extremely concerned about multiple errors and continuing failures and concentrating on ensuring that their Yr2K Projects are successful.

Interesting Article #2: Companies stretching truth about Y2K compliance By Howard Solomon, Computing Canada Honesty may be the best policy, but experts say it's being stretched by organizations in the latest Statistics Canada report on the nation's Year 2000 readiness. "It's bullshit," Jennifer McNeill, president of Calgary-based Cipher Systems Inc. and chair of the Western Canada Y2K User Group, said of predictions by large organizations that they'll be done with all mission critical Y2K work by the end of the year.

The report, released Tuesday, surveyed more than 10,000 business, health and municipal organizations. A final analysis of the figures will be released soon. "I still have people calling me that haven't started," said McNeill She and others are enraged at the astonishing completion performance being forecast by what StatsCan calls large organizations (those with more than 250 employees.) The survey states only 18 per cent thought their mission critical systems would be ready by the end of last month, but 52 per cent think they'll be ready by July, 67 per cent by the end of August and 92 per cent by the end of October.

Virtually all large businesses say their systems will be ready to face the millennium bug by December. "Companies are being unrealistic about their completion dates" in the survey, declared McNeill. "Every project I go into their schedules and milestones are off, some by as much as six to eight months. These are large companies that have missed their milestone dates over and over again. What makes them think they're going to hit them this year?" (Editors note: My emphasis) "I'm not a doomsayer I don't think the end of the world is going to come. But I think people have to use their heads and be prepared and I think reports like this keep people from doing that."

Y2K consultant and speaker Peter de Jager doubts that. No one will see the survey and stop or slow their work, he said in an interview. At the very least the report is an indication progress is being made, he said. How accurate it is, no one knows. "Ask any IT person if the project they're working on will be done on time and they'll say yes," he pointed out. Far more serious, he added are figures that some companies believe their critical systems will only be ready in December.

One way to read the figures is to declare the race to Dec. 31 a cliffhanger.

--In the hospitals sector, only 41 per cent say they'll have their critical systems done by the end of August;

--Only 60 per cent of large businesses in primary industries (such as mining and farming) say they'll have their critical systems done by Aug. 31;

--Only 46 per cent of small organizations are planning to speak to business partners about Y2K;

--Only 61 per cent of small municipalities are making contingency plans for sewage disposal;

--21 per cent of small fire departments are taking no steps to prepare their critical systems for Y2K.

"To even have mission critical deadlines in the fourth quarter of '99 is an indication of total incompetence," said de Jager. "It boggles the mind that an IT person would have that schedule. If I were their manager I would fire them."

On the average, you should expect that your remediated software, regardless of what language or platform it is in, will have several newly introduced errors. For example, one estimate notes that they have seen one programming error for every six changes that are made to a program. This is supposed to be a historic average in software maintenance for over 25 years and results for Year 2000 software remediation factories seem to be agreeing with it. One multinational company has noted that after remediation of their shipboard embedded systems, approximately 10% of those systems still failed Year 2000 readiness tests. This is less than one in six, but still a significant number.

Year 2000 work is big and getting bigger with each passing day. There has never been, and probably never will be, an accurate or even rough approximation of the amount and types of software deployed within any nation on earth. Most organizations still do not know what they have, maintain and pay for in all of their departments. The chances of missing several applications and embedded systems/devices are high. I have yet to see an audit that did not uncover 3-7% more potentially impacted items, either in IT or in embedded systems.

Even with this unease about the success of remediation efforts, most Year 2000 knowledgeable people now agree that a major collapse of society will not occur. A more realistic scenario is the Butterfly Effect, or as engineers call it, Positive Feedback. Small errors and disruptions will occur, ripple, aggregate and spread. They will compound at every turn until major systems begin to assemble enough corrupt data to fail. All this is likely to take hours, days, weeks, even months as little-used logic paths and programs are executed within the existing complex, little-understood systems throughout the world. The year 2000 may well become the longest, most expensive year in human history, lasting well into the next decade.

The real Year 2000 Myth is this: Continue to trust in what you and everybody else is doing. Everything is, and will be, just fine.

-- G Bailey (glbailey1@excite.com), November 22, 1999

Answers

The second article is circa June 1999 I believe. Could we get you to date the articles as you post them????

C

-- Chuck, a night driver (rienzoo@en.com), November 22, 1999.

Sorry Chuck here it is April 10, 1999

An Uneasy Feeling About Year 2000 Remediation Efforts

-- G Bailey (GBa6872290@aol.com), November 22, 1999.

Gawd, what time zone are you in, dude???

-- King of Spain (madrid@aol.cum), November 22, 1999.

IMHO there will be A few newbie's after the movie.This will get them started.Sorry to all the regulars who have discused these topics already.

-- G Bailey (glbailey1@excite.com), November 22, 1999.

G Bailey --

Don't let the 'old-timers' get to you. IMHO, the posts are very good, particularly for newcomers.

To those who think 'Let 'em go read the archives', lets admit that some of us haven't been as good at categorizing their posts as they might. (I went looking for a thread the other night and it took forty-five minutes to track the thing down. It was in 'misc', which appears either the second or third largest category (after 'government ' and probably 'uncategorized', which I suspect is the largest). This makes it *VERY* hard to track down threads which have disappeared from the main list or the 'New Answers', which, given the volume on this forum these days, tends to be a *very* short stay.

-- just another (another@engineer.com), November 22, 1999.