Peter de Jager
The Year 2000 Information Center


"The Question of Italy: An Analysis" (01/06/2000)

"Y2K: No Sham -- A Success Story" (01/03/2000)

"The Question of Italy: An Analysis"
By Peter de Jager
January 6, 2000

Like yourself and everybody else I am trying to understand what happened. While it is still too early to be doing this analysis, month end processing must still take place, I find myself compelled to provide some answers to the legitimate question -- why were places like Italy not impacted by Y2K.

The question goes deeper than just why Italy and others escaped the problem -- the other part of the question is why I and everyone else who worked on the problem are so adamant that the problem was real and that we took the correct and proper action.

You could place a gun to my head and threaten to pull the trigger unless I told you the 'truth' that the problem was NOT real -- and I would steadfastly refuse. I KNOW, with every fibre of my being that we were right. Nothing can shake me from that belief.

And therein lies the glaring contradiction I struggle with. My view of the problem is contradicted by a fact I cannot refute, and make no attempt to, Italy has seen no significant effects.

Nor would I even suggest for a second that there is significant enough difference between how Italy and Canada/USA/UK do computing to account for the conundrum.

There is an answer to this, there has to be. The world does not allow 'contradiction' to exist. Like you and others I am groping towards understanding.

What I am going to offer here is my first attempt at an explanation. An explanation which MUST fit all the facts as we know them and become 'obviously' true to any fair minded reader.

While the media attacks are disheartening -- the contradiction broiling in my mind is driving me insane. This search for truth is now a purely personal matter. Here goes.

We do know some very simple facts which cannot be denied:

1. We did have a pervasive habit of storing the year with only 2 digits. This habit is worldwide.

2. There exist date constructs which perform calculations and comparisons on 2 digit dates. This is nothing more than an observation of existence. It holds true in code around the world.

3. IF these date 'constructs' operate across the 99/00 boundary then they provide inaccurate results. This a key point. IF the constructs are faced with 99/00 data they fail. The key word here is IF.

4. Canada/USA/UK spent an awful lot of money to fix Y2K and avoid problems. Italy spent very little and there is no evidence that they have more problems than the above countries.

***The statement 'Italy spent very little' could be a misjudgment on our part.

***However I will assume the statement to be true.

***All the evidence suggests that Italy ignored this problem.

Okay -- with this in front of us how do we reconcile the contradiction? Let's examine a typical company with say 50,000,000 lines of code.

The Y2K issue is raised at this company and they decide to see if they are affected by the problem.

A very cursory examination will verify they use 2 digit years (Fact 1 confirmed). This can be confirmed in 5 minutes - you need only examine the data definition area of practically any program.

A further examination verifies a pervasive dependency on the date 'constructs' (Fact 2 confirmed). This can be confirmed in 5 minutes. - you need only examine the code of practically any program.

So far we have NOT demonstrated this company has a Y2K problem. We have demonstrated that the potential for a problem exists.

The next question we have to ask, and then answer, is "Can we confirm that the date constructs in question will face the 99/00 boundary?"

That is a difficult question to answer.

First let's recognize that 'facing the 99/00 boundary' is NOT an unreasonable expectation.

Examples: Money deposited in 1999 drawing interest in 2000 requires a time period calculation which crosses the boundary; an invoice due for payment in 1999, but paid late in 2000 requires a date comparison.

Coming up with examples of date boundary crossings are exceedingly simple. These do not require huge leaps of faith or even great intelligence.

AND -- if we create test data that creates these examples for our programs, they will, without question, fail.

However, there is something important to remember about 'test' data. It is not 'real' data in the sense that it is contrived to achieve a particular goal. It might never actually occur in the normal course of business.

Despite these test results we have not yet determined if the 50,000,000 lines of code we depend on will actually encounter this problem - DURING THE NORMAL COURSE OF BUSINESS.

There is another complicating factor. Identifying all the dates in those 50,000,000 lines of code is almost impossible. The very best automated tools only achieved a 95% accuracy rate which included both false positives and negatives.

This means from the very start, any examination of the 50,000,000 lines will be performed through a fuzzy lens. Any examination you perform will not examine every date. No matter how hard you try you will not be able to state conclusively 'These 50,000,000 lines of code will never result in a date construct crossing the date boundary 99/00.'

Okay -- Let's summarize:

1. the 50,000,000 lines of code do rely on 2 digit years

2. the 50,000,000 lines of code do utilize these 'date constructs'

3. if the date constructs encounter the date boundary, they will fail

4. We cannot, easily, due to the lack of complete data on all the dates, and the complexity of 50,000,000 lines of code determine if indeed we have a Y2K problem.

So far these are hard facts.

Where does the company with these 50,000,000 lines of code go from here? They have three choices in front of them:

1. They could go back to point #4 above and do what is necessary, to find out exactly where this body of code WILL be affected by Y2K. This is an extraordinarily difficult and expensive task to accomplish PRIOR TO THE ACTUAL FAILURE

2. They could decide to 'fix' every instance of 2 digit dates wherever they could find them. This, while expensive, is significantly cheaper than option #1 It is ALSO overkill. They would be changing many date constructs which would never have been faced with the date boundary of 99/00

3. They could chose to do nothing. They could chose to adopt the strategy of 'Fix on Failure.' The benefit of this strategy is that you don't have to search for the problems, they will make themselves known to you. The downside is that prior to failure you have no idea what size of problems you might face, or how long they would take to fix, or how many you will encounter.

Strategy #1 "Fix only what you know will break" was adopted to some degree wherever possible. Programs which only 'printed' the date were sometimes ignored. For the most part however this strategy was too expensive to implement and too susceptible to human error. It was, for the most part, an unacceptable strategy.

The decision now boiled down to a choice between 'Spend money and fix everything' or 'Fix nothing and hope for the best.'

At this point the decision rests partly upon the answer to the question 'How many 99/00 boundary crossings can we expect to occur in our 50,000,000 lines of code?'

Understand that at this point, the answer to this question cannot be determined with any worthwhile accuracy. We are trying to predict a future event. It is all but impossible to sift through 50,000,000 lines of code to determine exactly what will happen.

We do know that the examples we create to demonstrate failure are not complicated examples. They are easily devised and do not strain the bounds of credulity. There is at this point in the analysis a reasonable expectation that there will be some problems, but no way to determine with any reliable degree of accuracy -- how many.

Our decision also rests on how much risk we are willing to assume on behalf of our shareholders and stakeholders.

If we decide to fix on failure, are we certain that when a failure occurs we can fix it before the failure impacts our business? The honest answer to that question is 'No, we are not certain.'

Another question, are we certain that the number of failures we might encounter can be managed by our available resources? Again, the honest answer is 'No, we are not certain.'

No one can honestly answer yes to either of these two questions, anymore than we can accurately determine how many problems we will encounter. The questions are basically the same -- How many problems will we encounter? And the answer is "We don't know!"

So it all boils down to this final question:

Given that we know we use 2 digit dates, we utilize those constructs which will cause problems IF faced with the 99/00 boundary, the 99/00 boundary crossings are not unreasonable situations.

How many 99/00 boundary crossing problems can we reasonably expect to occur in the normal day to day operation of 50,000,000 lines of code and are we willing to accept the risks associated with letting this unknown quantity of problems to occur and then fixing them after the fact?

And this is exactly where, only with 20/20 hindsight, can we determine we made our 'error' in judgement.

We made the decision, based upon everything we had discovered, that there would be enough 99/00 boundary crossings to make choosing Strategy #3 an example of gross negligence.

I could not in good conscience advise anyone to ignore this problem and only worry about the problem when it occurs. I could not advise anyone to accept failure as a viable strategy -- especially since I had no idea how large the failures might be.

It turns out that there were fewer 99/00 boundary crossings than we feared. Countries that did nothing were faced with fewer problems than we expected. If we are to be convicted for refusing to accept an unacceptable risk, then so be it -- but anyone who chooses to do so should have the decency to admit that the only reason we can be judged harshly at this point is with the impunity of 20/20 hindsight. We choose the safer, but more expensive, path into the future.

One final thought is worth pointing out. The countries that did very little Y2K work did not choose that path after careful consideration of the issues. They chose that strategy by default. They ignored the problem entirely and were lucky that our considered and carefully weighed risk avoidance strategy was, with 20/00 hindsight, faulty.

Anyone who seriously examined the Y2K issue chose the path we chose. I have no regrets. Faced with the same situation, I would choose the path we walked with the same dogged determination.

I hope this helps in the understanding of what happened.

Yours truly,
Peter de Jager




"Y2K: No Sham -- A Success Story"
By Peter de Jager
Monday, January 3, 2000; Page A19
The Washington Post

As the New Year arrived in city after city around the world, those of us involved in the Y2K problem were paying little attention to the fireworks. We were focused instead on the lights in the background. Despite our technical competence, hands-on experience, diligent testing and confident statements, we were still holding our breath as the Year 2000 arrived -- and we released it in a sigh of relief when the lights stayed on.

Throughout the globe, the phones worked, and nuclear reactors hummed. Missiles remained undisturbed in their silos, and planes flew through the air. I was particularly grateful for the latter, because I was at 37,000 feet over Toronto on a United Airlines flight to Heathrow just to prove a point about my confidence about Y2K.

But before dawn even broke over party-weary cities, the Y2K critics were sharpening their knives. To them, the lack of havoc was proof that the Y2K problem was an illusion, just as they suspected all along. Within nine hours of midnight, Universal Time Code (formerly known as Greenwich Mean Time), I gave several interviews to reporters who seemed to be gloating over the apparent lack of Y2K problems.

Y2K has always been a question mark. The possibility that a Y2K problem would affect power was remote, but even a slim chance for failure required contingency plans. We knew from the beginning, though, that if we had any success in fixing Y2K, the critics -- supported with the infallibility of 20/20 hindsight -- would claim the problem never existed.

That argument does not hold up to examination, however. The critics contend that the continued use of a two-digit year would not cause any "significant" problems and that money spent on the project was unnecessary. The truth, however, is that the hype about Y2K, including some of the more ludicrous statements, forced companies to examine their systems with the goal of answering one question: Did Y2K pose a threat to the computer system that provided benefits to their organization? If the answer was yes, they took appropriate action; if the answer was no, they did nothing.

Each time that money was budgeted for Y2K problems, the expenditures were initiated by technical and management experts who had the skills to comment on whether the two digits would cause problems that required remediation. Because of these projects and the efforts of hundreds of thousands of programmers around the world, the phrase "Happy New Year" is still a pleasant greeting and not an exercise in irony.

What is ironic is that unlike the critics, only a few Y2K managers are willing at this early date to pronounce the Y2K operation a success even though it is way too soon to signal an all-clear. Over a holiday weekend, especially this holiday weekend, only a tiny percentage of computer applications are active. Most of these relate to the infrastructure, which received a tremendous amount of attention and was predicted to run smoothly. The real test arrives when the engines of commerce are restarted today, and all the applications in the world deal with the Year 2000 for the first time.

We need to wait a month or two before detailing our success or failure. We avoided chaos because programmers and managers around the world did their best to solve this potential problem before it became a reality.

Of course some projections were inaccurate, falling on both the low and high sides of reality. Were the assessments of a foreign country's Y2K status accurate? I doubt it, because they were based upon the unknown accuracy of the most accurate data available.

Ironically, the greater our success, the more "evidence" critics will cite for declaring that Y2K was an illusion. But it's always easier to predict the future after it becomes history. Meanwhile, programmers around the world wish you a Happy New Year.