Testimony of Governor Edward W. Kelley, Jr. Before the Committee on Commerce, Science, and Transportation, U.S. Senate April 28, 1998

http://www.bog.frb.fed.us/BOARDDOCS/TESTIMONY/19980428.htm

Here are some points that jumped out at me as I read it:

1) Fed contingency planning can assist neighborhood contingency planning.

2) It has been my experience that people want to help others, given the chance to do so. This is why so many volunteers turn up for flood relief, or help strangers in an earthquake. And we are also a nation of entrepreneural problem solvers. But for y2k, we cannot turn out to help until we know what the problem is we are trying to solve. I am pleased Kelley has started to create a problem statement in this report. But I am disappointed that he missed the essence of the problem.

More detail:

1) "We are currently focusing on contingency planning for external Y2K-related disruptions, such as those affecting utility companies telecommunications providers, large banks, and difficulties abroad that affect U.S. markets or institutions."

If the Fed is doing contingency planning for these types of disruptions, then our commmunity y2k contingency plans should as well, ( once we start making them :/ )

2)

Reading between the lines, the Fed appears to be going through the same process most of us are going through,

o realization there is a problem, o trying to get our heads around it, o mitigating our part of it, o trying to get our heads around it, o creating contingency plans, o trying to get our heads around it. What is missing is a statement of the total problem and this omission means we spend more time trying to get our heads around it. This omission prevents people who want to help, from being able to help, because it is not clear what to do.

Look at this quote:

"We have many examples of how economic activity was affected by disruptions to the physical infrastructure of this country. Although the Y2K problem clearly is unique, some of these disruptions to our physical infrastructure may be useful in organizing our thinking about the consequences of short-lived interruptions in our information infrastructure. In early 1996, a major winter storm paralyzed large portions of the country."....

Kelley is stating that this y2k disruption is similar to a storm. We have had lots of ice storms. We have never had y2k. The Y2K problem exists in the information infrastructure we have created. To those of us in the software industry, this is a very familiar place with familiar problems and feelings. The y2k disruption will be more akin to a large system integration project than digging out from an icestorm. Integration testing requires time and patience and attention to detail.

Here's an analagy that rings closer to the truth to me.

You are working on part of an operating system and the project is to upgrade it from 32 to 64bit. Each component must be examined and fixed if need be. The toughest part of the project is system integration - that's when everyone throws their modified components into the sandbox and integration starts testing to see if the OS works correctly. You test your own component, which worked fine in unit test, but now it fails. Generally, there is a lot of time spent debugging and a lot of time spent locating problems in someone else's component or in interfaces. It's frustrating work. It requires the steadying hand of integration engineers/managers and maximum coordination and clear status data. It's notoriously difficult to estimate how long integration testing will take; unexpected problems continually arise. And completion date estimates are infamously optimistic.

Too bad Kelley did not give as analagies various large software projects. If he could have written that this is an information system disruption, not a physical disruption, then he would be providing more useful planning information for his audience.

Bill Gates wanted Windows 95 to ship in, when was it, 1991? Bill Gates, despite all his money and resources could not force the OS to be completed before it was ready.

I read that an analagy to software development is a traffic jam. That also is not a bad analagy that Kelley could have used. All the cars in the state must be at city hall January 1, 2000. And we all started late. So there is a traffic gridlock and no matter how good our managers are, how much we want to be on time, how much money we have, if we stay in the cars, we will not be on time at city hall. We will eventually get there but we won't like the trip. Especially if the cell phones and radio stations are down.

Ian

(cross post, year2000@efn.org)

-- Ian Wells (ian@rsn.hp.com), May 03, 1998

Answers

Ian,

I think you are missing a point. You said:

"Kelley is stating that this y2k disruption is similar to a storm. We have had lots of ice storms. We have never had y2k. The Y2K problem exists in the information infrastructure we have created. To those of us in the software industry, this is a very familiar place with familiar problems and feelings. The y2k disruption will be more akin to a large system integration project than digging out from an icestorm. Integration testing requires time and patience and attention to detail."

I think that it is evident that they y2k problem will have effects upon our infrastructure *exactly* like a big storm. There will be some power outages, some sewer/water system failures, some trains won't run, some airports won't be usable, and so forth. The effect upon the community is exactly like the havoc of a *big* storm. If the roads become impassable, for whatever reason, there will be local food shortages. In an environment like that, the community will not think that time and patience and attention to detail is required.

The big difference between y2k and a storm is that if we had started much earlier we could have avoided y2k alltogether. That is, we could have stopped the storm. With a natural storm we cannot stop it, no matter when we start.

-- George Valentine (GeorgeValentine@usa.net), May 05, 1998.