Y2K and the Bump in the Road

Name-calling has too-often replaced serious debate as we envision likely outcomes of Y2K. Thinking through the systemic issues of Y2K requires extraordinary feats of imagination as well as analysis. In addition, such thinking requires the push-back of community dialogue, the kind of dialogue that already takes place on several Y2K forums, accompanied by some judicious and righteous flaming.

Unfortunately, Y2K pollyannas have not put forth imaginative scenarios that rival those of Milne or Infomagic. The doombrood (and this author is a card-carrying, computer consulting member of that sect who is preparing personally for TEOTWAWKI) would say this is because there are no such scenarios to be made. Maybe so.

The conceptualizing of possible post-Y2K futures during 1999 must require the open, honest exploration of the most reasonable possible "best case". By determining how plausible that case is, we can re-evaluate all the other cases, most notably Infomagic, as well as gain a better picture of the range of outcomes that can be projected.

While many might feel that no serious "bump in the road" proposal can be made at this late date, the fact is that many expect just a bump. Lets see how reasonable that is.

*The Y2K problem is very broad, but extremely shallow.* While there are an extraordinary number of fixes that must be made, we rarely need to change an applications requirements, design or functional specification. While date formats are often idiosyncratic and even bizarre, the Y2K challenge resolves fundamentally to "find and replace". Consequently, Y2K does not place great stress on an organizations technical competence.

*Completed work is under-reported.* Compliance percentages are misleading and under-state the progress that has been made, for two reasons. First, organizations are focused on fixing the problem, not on reporting progress. Progress reports lag the work completed. Second, over-reporting compliance is a sure route to legal exposure. Even if the work is done well, the lawyers will seek every opportunity to punish problems: why make their work easier?

*Budgets do not take into account the type of expenses scheduled for 1999.* The reason most Y2K budgeted amounts are scheduled for 1999 is due to the lag in payments for work already done (60 to 120 days) as well as for major equipment replacement (hardware and software) that will be expensed in 1999. The budget lag is insignificant with respect to the pace of Y2K fixes.

*100% compliance is desirable but not required.* Admittedly, it would have been better if everyone had started earlier. However, because Y2K is a shallow problem, the benefit of fixes is mainly additive. 70% compliance is meaningfully better than 60% and 80% that much safer than 70%. Though "fix on failure" will be undesirable, we are already focusing on an ever smaller universe of remaining date issues. Most systems will remain operational even if they are somewhat degraded.

*Code breakdowns will be mainly trivial.* Contrary to conventional wisdom, most breakdowns will be minor in significance, though not necessarily in quantity. A high percentage will entail mis-display or mis-printing of dates (for instance, on report headings) that are not germane to mission operation. The majority of the remaining small percentage of mission-critical errors will be corrected rapidly by programmers or can be compensated for by human staff until corrections can be made. Much Y2K-remediated code is already executing safely in a production environment and this percentage will grow throughout 1999, supporting ongoing fixes to reduce overall Y2K risk.

*Embedded system issues are extremely minor.* Over time, the expected crisis posed by embedded systems has been greatly reduced in scale. Undoubtedly, there will be problems. However, viewing Y2K as a whole, there is no evidence to suggest that effects will be widespread or critical.

*Y2K is not systemic and the key world infrastructures are highly redundant.* While Y2K bugs certainly exist in a very broad set of programs, this is not equivalent to it being a systemic problem, which implies that infrastructure interdependencies and domino effects will be accelerated by code breakdowns. In fact, while true, it is trite to say that water, energy, finance and telecom must all function simultaneously. Each of these infrastructures is replete with their own version of redundancies, islanding capabilities, manual over-rides and the ability to function with a sharply reduced rate of efficiency.

*The most dangerous Y2K effects will be caused by panic and loss of confidence, not be the technical realities.* Although Y2K is a well-bounded problem, we risk grave problems if people lose confidence in systems and, especially, financial systems. It is unconscionable that so many consultants and commentators are focusing on Y2K uncertainties and concluding that TEOTWAWKI is a reasonable possibility. Much government and corporate contingency planning, as a result, has to go to reducing the potential of panic rather than addressing the problem itself.

*Look to the Euro.* Finally, despite the doombroods comparison of Y2K to the introduction of the Euro, the Euros introduction has been remarkably smooth. Fixed deadlines concentrate organizational resources and skills, unlike classic software projects with floating schedules. Y2K is a very big problem, but it is being fixed.

While I welcome rebuttals to the points above (Ill be incorporating my own shortly), we should work first on capturing all the essential pollyanna points of argument. The first question is: what are the best arguments and defenses of those arguments? Did I make them here or not? Pollyannas, its up to you to help me.

I personally consider each of the arguments made here to be erroneous and disconnected from the actual facts of the case. Once we sharpen the arguments, we will begin to deal with the disconnects. If you fellow doombrooders cant resist doing so from the start, thats okay. Fire away, Im with you.

-- BigDog (BigDog@duffer.com), January 09, 1999

Answers

A further pollyanna argument is that much of the computer output (paper or screen) of any large company is simply unnecessary. There are a lot of "critical" reports that are critical only in the sense that they justify someone's job. Maybe they were truly useful 5 or 10 years ago, but now the same info is pulled up real time by system xyz.

I believe this is a true statement, but it ignores the impact of erroneous date processing on the 'good' stuff. It also hurts the remediation effort because the truly critical systems are degraded by the effort but into the faux-critical systems.

-- RD. ->H (drherr@erols.com), January 09, 1999.

Good analogy.

-- flierdude (mkessler0101@sprynet.com), January 09, 1999.

"We will just buy some new computers, if the old ones can't be fixed. We only have 6 in the office and they are 5 or 6 years old anyway. It will only cost about $10K." Small business pollyannas, without a big picture perspective.

-- Bill (bill@microsoft.com), January 09, 1999.

The argument back at the beginning of 1998 was to take compliance letters at your own risk. That is, a bonified letter of compliance along with the president's or CEO's signature warranting that compliance had been achieved.

At this juncture I would have to say that compliance letters are rare. This is very telling. Too many IF's, And's or Butts on the line.

The pollyannas partaking in today's arguments are likely not to have been aware of the problem for long. I would argue that the vast majority of pollyannas from early 1998 have moved into the larger "Get It" group, and are now taking it seriously enough to make personal preparations. Some of them may even be stepping over into the "fringe" group who are voicing their concerns and warning others.

Pollyannas will be cropping up all over the place in the next few months and it will be more because the future is looming ever closer and the options are reducing day by day. It's a hard fact to swallow, so deny it. At least you will sleep okay, if nothing else.

-- Got It (gi-alongtime@ago.com), January 09, 1999.

BigDog,

Thats a good collection of Pollyanna arguments. In fact one of the best Ive seen, and there is more than a grain of truth in quite a few. However...

* Y2k is broad but shallow *

If a site has to revise their database because of 2-digit years (i.e., the correct solution), the problem becomes technically deeper. Revising old mainframe code is not all that trivial an exercise, either. Business software has a great deal of date logic. Over the years, much of this logic has become quite challenging to decode. Many shops have only marginal experience revising and coordinating an enterprise-wide systems change.

* Y2k completions are actually under-reported *

If anything, Y2k completions are over-reported. The pressure on corporate and government entities to show real progress at this late stage are palpable. Some notable early completion reports have been shown to be fraudulent. The competitive advantage in (truthfully) demonstrating early Y2k compliance is not lost on the business community.

* Y2k budgets are back-loaded due to payment patterns and remediation plans *

This is a stretch. Arent budgets set for date spent, not date paid? Mine are. In any event, even if true, the numbers are still too large in comparison to the amount of work theoretically remaining. 1999 hardware/software upgrades as a rationalization dont really work either, unless the enterprise is quite small. In my firsthand experience, it takes a fortune 500 company a minimum of 5 years (!) to do anything across the entire enterprise the right way, and, even then, the net result might be less than desirable. This is why they needed to have started on Y2k, in earnest, in 1995 if a non-trivial amount of their I/T infrastructure required Y2k upgrades. They can do a hatchet job in about half that time, with much follow-on expense for years thereafter.

* Y2k 100% remediation is desirable, but not required *

Depends. Few dates used, true, though unlikely. If databases are to be revised, pretty much everything has to be looked at (hence the popular, though fraught with problems, windowing techniques being applied to fix Y2k). Not fixing everything requires effort spent on some level of triage, which may or may not be correct or successful. Fixing everything is expensive and time-consuming, though more definitive.

* Y2k code breakdowns will be trivial, many remediated systems are already running *

Depends. Stumbling blocks include: external data feeds, internal cross-process data communications, inadequate testing, NO testing, inadequate post-2000 testing, NO post-2000 testing (!), and potential database corruption. Most people have no idea how precious and fragile correct data is. It has taken decades of system tuning to approach the current level of correctness and reliable we now enjoy. Y2k jeopardizes this.

* Y2k embedded system problems will be minor *

This is not my area, but hundreds of articles on this topic, from those who should know what the issues are, would suggest this statement may be wishful thinking.

* Y2k is not systemic -- the infrastructure is redundant *

An interesting assertion. In certain respects, this is true. There are lots of gas stations, fast food restaurants, banks, hair salons, and coffee bars. But, there is only one phone line into my house, one gas line, one power line, and one water main. There is really only one air carrier of any consequence at my local international airport. There is but one US post office, one IRS, one FAA, and one Social Security Administration. This is one New York Stock Exchange and one Chicago Mercantile Exchange. There are but one or two reliable manufactures of any number of items and materials, strategic and sundry. We are living in an age of specialization. If a company is not number one or two in its chosen specialty, it drops out of the running. So a couple of companies make commercial jet engines, a couple deliver packages overnight, a couple make purified silicon for chip production, and a couple make PC microprocessors, etc. Supply chain disruptions are not out of the question. I think most stuff will still be available, it just might not be available at reasonable prices and in a timely manner.

* Y2k panic and loss of confidence will be worse than the Y2k technical problems *

I dont know what to make of this statement. These two are joined at the hip, and making qualitative distinctions between the two serves little purpose. The two will feed each other, for good or ill. Factual Y2k reporting may well cause panic and loss of confidence. Actual panic and loss of confidence will make Y2k remediation that much more difficult. Actual Y2k failures will cause more panic and loss of confidence. Additional panic and loss of confidence will delay repairs to actual Y2k failures. The panic and loss of confidence will probably be delayed for as long as possible -- much like the required Y2k repairs themselves were delayed as long as possible. Hmm, we seem to have a pattern here...

* Y2k will be OK, as the Euro conversion demonstrates *

Big apples versus tiny oranges. How many non-multiple currency systems were out there in the first place, especially in Europe? Financials work with different currencies all the time, but they all use but one concept of time. Few systems care little about the currency unit, but many need to know, unambiguously, what the year is. Records are rarely stamped with the currency unit, but theyre stamped with the date all the time.

Oh, and in case you were wondering what a Pollyanna looks like...

-- Nathan (nospam@all.com), January 10, 1999.

I'm mortified. The best omnibus Pollyanna post I've ever read was written by a self-proclamed Doombrooder. [sigh]

Hallyx

"The basis of optimism is sheer terror."---Oscar Wilde (The Picture of Dorian Gray)

-- Hallyx (Hallyx@aol.com), January 10, 1999.

Thank you, BigDog.

You know, I WANT to believe; I really do.

Yet, when I see these arguments gathered together -- *this* is the hope, and faith, and confidence, and trust, that guides our Pollyanna bretheren....

I feel sick. Just sick.

Anita E.

-- Anita Evangelista (ale@townsqr.com), January 10, 1999.

Agreed. You've compiled the best possible case for the pollyanna/bump-in-the-road argument. For additional feedback, I suggest you cross-post it to Rick Cowles' forum, Electric Utilities and Y2K.

As Nathan notes, household utilities are not redundant. Neither are individual jobs or personal bank accounts.

And some event sequences are not reversible. If power to my house is out for only a week, wonderful. But if the outside temperature that week was sub-zero, my burst water pipes won't care that the power's back on. And all the plumbers in the area will be fully booked.

-- Tom Carey (tomcarey@mindspring.com), January 10, 1999.

Big...

The one I hear often you left out. It is the Rush Limbaugh favorite and De Jager leanto. How can we leave out how creative, flexible, innovative, and indomitable our spirits and minds? We can fix anything. This is American you're talking about bub? We've put men on the moon. They will fix it!!! b

-- b (b@b.b), January 10, 1999.

Yes, and here's more evidence that it's a bump in the road: many of the failures will be spread across the coming year, not all happen simultaneously on 01/01/00.

But here's the problem with this statement and with the original list: it makes best case assumptions. In actuality, assumptions tend to favor the worst case. In other words, it's a lot easier for a complex system to fail than it is for it to work properly. System people see this a lot, when initial designs that seem simple turn out to be horribly complicated, or a system whose code looks like it's got to work, but doesn't.

-- a (a@a.a), January 10, 1999.

Big Dog, this one's a beauty. Along with Nathan's response, this goes in my binder as the first piece in the "Pollyanna Responses" section.

Thanks...

-- pshannon (pshannon@inch.com), January 10, 1999.

"And some event sequences are not reversible. If power to my house is out for only a week, wonderful. But if the outside temperature that week was sub-zero, my burst water pipes won't care that the power's back on. And all the plumbers in the area will be fully booked. "--Tom

And companies that went out of business because the electric was out for longer than their contengency planned for. And the economy that went down because of them. And...ad infinitum.

-- Chris (catsy@pond.com), January 10, 1999.

A corollary to b's contribution: It won't happen because "they" have too much incentive to take care of it.

A response may lie in the high turnover of corporate management and personnel, previously CEOs and IT staff not wanting to make waves on their watch. So human nature ensured that the overall problem could not be resolved in time.

-- Brooks (brooksbie@hotmail.com), January 10, 1999.

And a few more: We'll find different ways of doing what we're doing now, and we still have time to make lots of fixes, and we've made a sizeable dent in the problem already.

This is a really excellent list. Many thanks to Big Dog and Nathan. All of these points have some truth and a lot of problems. Nathan's approach is excellent -- the question isn't whether each statement is true or false, the question is just how much truth is there in each statement. Not will things be bad, but how bad will they be?

From what I've read, perceived carrots and sticks lead the private sector to underreport progress a bit, and the public sector to overreport it.

The Euro project wasn't trivial, but it did consume resources that could have been spent correcting date bugs.

Many embedded problems will be small and easily corrected. Some will be doozies, no question.

Percentage of remediation is pretty meaningless. If I knew exactly where every date bug was and exactly what it would cause, I could probably keep my head above water fixing only a key 5%, and drown after fixing only the other 95%. We can somewhat identify what key systems do, but we can't anticipate consequences very well on a bug- by-bug basis.

Shallowness is hard to grasp. What's worse, a problem that makes phone lines noisy and lasts a year, or a problem that disables communications altogether for two weeks? A problem that corrupts a database and requires manual repair from now on, or a bug in the tape transport unit that prevents us from reading that database at all, but we get it working again in a few days? There will surely be problems that are both serious and long lasting, but how many?

There's an awful lot of scope when you start trying to quantify 'at reasonable prices and in a timely manner.' I hope to see years of argument over how much is too much and how long is too long. At least this would mean there are still people around to argue, and have the means to do so.

-- Flint (flintc@mindspring.com), January 10, 1999.

I've got nothing to say to this question right now, I'm just posting so that Big Dog's very good thread gets up to the top of the hit parade where it will get more of the attention it deserves.

-- humptydumpty (no.6@thevillage.com), January 13, 1999.

Also: American ingenuity and inventiveness not withstanding - assuming there is some left after a government education - but there is absolutely nothing an "American citizen" can do to get water, 911, phones, satellites, power, or natural gas back after an infrastrucutre failure.

You can only sit at the end of the pipe, waiting for somebody else to recover each and every section.

The situation is worse in distributed systems needing multiple silumtaneous systems to also work: even the expert id held hostage by factors he or she can't influence.

And so the repairman (or programmer) desperately working on the SCADA system to work in Atlanta to get the natural gas flowing through Lousiana can't do anything about the power outage in Houston that is causing the pumps to fail in Beaumont so there is no gas pressure in Mississippi!

And the Atlanta power station that is keeping his lights on has three hours of natural gas supplies left before it trips off line.......

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