Ed Yourdon on 9/9/99

Just saw your posting about Bob Bemer being unconcerned about 9/9/99 problems. I agree with his basic point, but there's a subtle nuance that almost always gets overlooked: the computer system that requires the end-user to enter a date even when the end-user is convinced that the date is irrelevant.

Suppose, for example, that you've filled out an application form to open a new bank account. The account is opened while you're there in the bank, perhaps on a provisional basis, and you give the bank officer an initial deposit of $100. The bank officer gives you some temporary checks, shakes your hand enthusiastically, and tells you how happy he/she is that you're doing business with them. You take your temporary checks and various other scraps of paper that you've been given, and you go back home, assuming that you'll get your "real" checks in another week or so, at which point you'll start using your account.

A day or two later, the paperwork that you filled out, along with whatever forms were filled out by the bank officer, shows up in the data-entry department of the bank's computer department. There are thousands of such forms waiting to be processed, each one of which has to be entered into a computer system by a thoroughly disinterested, bored, barely-literate 18 year old high school graduate. He/she reads the information from the paper forms, assuming that the information is legible, and enters them into the appropriate fields on the computer screen. In a "modern" system, any errors are flagged as soon as the information is entered, and the data-entry person is required to fix the errors; in an older system, the error messages are not generated until ALL of the information has been entered and the clerk pushes the "ENTER" key. Thus, if the clerk is using a system that was developed back in the 70s (e.g., a dumb-terminal, character-based terminal system, rather than a more modern "GUI" system running with Microsoft Windows, etc.), he/she might spend 10 minutes entering all of the data about your new bank account, at which point the computer system informs him/her that it has found 19 errors that must be corrected before the account can actually be opened. This puts the clerk into an even worse mood than before, and tends to increase the chances that some or all of the data will be ignored or entered erroneously or maliciously...

Suppose, for example, that one of the required fields is "mother's maiden name" and another one is "mother's birth-date." When you opened the account, you provided the appropriate information about your mother's maiden name, but perhaps you couldn't remember your mother's birthdate. You can't imagine why anyone would need that information anyway, and indeed you're rather annoyed that they should be asking such personal information. So you leave that entry blank on the form, and the bank officer doesn't notice. Thus, when the data-entry clerk starts entering the information into the computer a couple days later, there's a problem: the computer insists on having a date entered, but the information is missing, and the data-entry clerk knows that the information is irrelevant. Or, to say the same thing in a slightly different way: the clerk knows (from trial-and-error experience), and/or from the "tribal folklore" that he/she absorbed during the first few weeks of working in the bank's data entry department) that it doesn't really matter what kind of date you enter into that field. 0/0/00 won't work, because it's a completely illegitimate date, but 1/1/11 will work, as will 2/2/22, or 3/3/33, or 9/9/99 or 12/31/99. Thus, the clerk (and all of his/her fellow clerks in the data entry department) adopts the convenient habit of typing a "phony" date into that field whenever the information is missing on the paper forms. For all we know, the clerk types in a phony date regardless of what's on the paper form, simply because the "tribal folklore" within the organization is that the computer really doesn't care what you've typed.

But the tribal folklore may turn out to be slightly incorrect: it may turn out that some other part of the overall banking system DOES look at the "mother's birthdate" field, for reasons that may or may not turn out to be important or rational. The significant thing about such entries as 1/1/11 or 2/2/22 or 3/3/33, etc, is that they are dates PRIOR to today's existing date of something/something/99. Maybe the computer has some logic that says "if the mother's birthdate was BEFORE today's current date, then don't do anything at all. But if the mother's birthdate is EQUAL to today's current date, then send her a pre-approved Visa credit card with an approved credit balance of $10,000."

Thus, when September 9, 1999 arrives a little less than a month from now, various computer systems may "wake up" and begin doing all kinds of strange things because the data that had been entered by the disinterested clerk was fundamentally incorrect. It's possible, though pretty unlikely, that the computer system will crash or stop; it's more likely that it will begin doing things that don't make sense, or have embarrassing and costly consequences.

How likely is such a phenomenon? Well, nobody knows ... but the key point is that you won't find such problems by scanning through old legacy code for programming statements that say "If the date-field is equal to 9/9/99, then do X, and Y, and Z ..." instead, you would have to look for situations where the computer logic accepts a date-field entry without doing sufficient error-checking. For example, in the banking situation mentioned above, the clerk may have opened the new account for you on, say, August 14th, 1999 and in the course of doing so, might enter a mother's birth-date of 9/9/99. A computer system with appropriate error-checking logic would notice that your mother has allegedly been born several weeks into the future, and indeed several years after YOUR birthdate; it would thus reject the date as being nonsensical, and would require the clerk to enter a date-value prior to today's date, and prior to the birth-date of the account-holder. But if that kind of error-checking logic has been left out, it might not be noticed until we actually reach the date of 9/9/99.

Given that the computer system has been programmed sloppily without the appropriate error-checking, the interesting question is: what kind of illegal date is the data-entry person most likely to use? As you can imagine, there is no universally-correct answer to this question; it depends on various factors. Here are a few plausible examples:

1. The data-entry person really doesn't care what value he/she types, and is most interested in minimizing the amount of time and effort required to enter the data; this is particularly common in cases where the data-entry person is paid on a "piece-work" basis, which means that he/she wants to enter as many transactions as possible during an 8-hour work-shift. Now, what that really means is that the preferred data-entry values will depend on how the clerk's keyboard is laid out, especially with regard to the numeric keys. On the keyboard I'm using right now, there is a numeric keypad on the right-hand side of the keyboard, and in order to minimize the physical distance that my right hand has to move from the QWERTY portion of the keyboard to the numeric keypad, for entering the "mother's birthdate" field, chances are that I would use 1/1/11 as the preferred value. On the other hand, if the computer system requires me to explicitly type the "/" between the numeric digits, then I would probably use 9/9/99 because it turns out that the "/" character is located immediately above the "9" character on the keyboard. Obviously, different computer terminals have different keyboard designs, so you might see a variety of different choices in this area.

2. The data-entry person doesn't really care what value he/she types, but is convinced that the computer system is idiotic, and that the people who programmed it are consummate idiots. Indeed, he/she feels that every aspect of the computer system is confusing, inconsistent, unfriendly, inefficient, and just downright annoying. As a result, he/she is happy to take advantage of any opportunity to wreak revenge upon the computer (which he/she views as a living, anthropomorphic entity) and the people who designed it, and the stupid managers who make him/her use it. Thus, choosing 9/9/99 as a data-entry value is a subtle way for the data entry clerk to say, "Hee hee hee! Look how stupid you are, you idiot computer! I'm typing in a totally nonsensical value, and you didn't even notice it! I hope this throws a real monkey wrench into your processing logic -- it will serve you right for making my life so unpleasant!"

3. The data-entry person is somewhat more aggressively hostile, and thinks that he/she might be able to accomplish an even greater sense of revenge by typing something different into the date-field for every new transaction. Thus, he/she might type "1/1/11" for your bank-account, and "2/3/45" for the next one.

4. The data-entry person is completely computer-illiterate, and has virtually no idea of what's going on "behind the scenes" in the computer. Most of the required procedures, and most of the error messages from the computer, make no sense to him/her, and nobody has ever provided a rational explanation of what's going on. Indeed, nobody provided any adequate training in the normal sense of the word; when initially hired, the new data-entry clerk was told, "Sit by Mabel for a few days, and watch what she does. You don't have to understand what's going on, just do what Mabel does." And if it turns out that Mabel types 9/9/99 for the birthdate of a new account-holder's mother, then that's what the new person will do. Why? Because that's what Mabel did. Why did Mabel do it that way? See explanation #1 or #2 or #3 above, or (recursively) #4.

5. The data-entry person is reasonably intelligent and well-meaning, but does not read or write English. He/she is an illegal alien and works long hours for below-minimum-wage pay. As a result, the data-entry person not only finds himself/herself in situation #4, but is utterly clueless as to what's going on. He/she is not about to complain, or ask annoying questions about the behavior of the computer system, because he/she is terrified of being fired. This may seem bizarre and implausible, but a local merchant here in my town told me of EXACTLY such a situation with his key supplier, whose factory and computer department are based in Southern California. The data-entry people are Mexican immigrants; they're as intelligent as you and me, but they really don't understand what they're doing -- they merely transcribe numbers and characters from a paper form into a computer system whose English-based error messages and displays are unintelligible to them.

Thus, like many other aspects of the Y2K situation, the devil is in the details. It will be interesting to see what really happens on 9/9/99 -- and it's also important to recognize that we may see a rash of similar problems on 12/31/99, since that's likely to be another common choice of "it doesn't really matter what you type into this date-field, so let's just pick an arbitrary date..."

---------------------------------------------------------------------- -------------------------------------------

-- Ashton & Leska in Cascadia (allaha@earthlink.net), August 15, 1999

Answers

Ed, your writing as usual is droll, informative, and thought/smile provoking. We peons expect to see ZERO effect of 9/9/99 failures because they probably will be few enough to Hide in the Spin Cycle.

Want to thank you for your tireless efforts to educate the computer clueless. There's enough for even the 0duh1duh0 to ferret out "upgrade" "teething" "bloopers." But the time for Hide and Seek is about to end, and the real Survival Chase to begin.

Keep writing!

-- Ashton & Leska in Cascadia (allaha@earthlink.net), August 15, 1999.

9/9/99 may or may not be significant. But I learned this week that the GPS 8/21/1999 12:00 pm rollover WILL absolutely have observable impacts. Whether or not they get reported remains to be seen.

-- Bill P (porterwn@one.net), August 15, 1999.

Bill P:

Are you serious here? So either we see GPS rollover problems (proving there were problems) or we don't (proving the problems were covered up). And how about if there really aren't any such problems? Well, that's impossible by *definition*. Not by evidence, by definition. So the only use you have for the 'evidence' is to find out how well the truth can be hidden, right?

Bill, this approach is not generally considered, uh, sane.

-- Flint (flintc@mindspring.com), August 15, 1999.

But I learned this week that the GPS 8/21/1999 12:00 pm rollover WILL absolutely have observable impacts.

Where did you learn that?

-- Lane Core Jr. (elcore@sgi.net), August 15, 1999.

There is a sail boat race on Lake Erie that is being postponed due to the GPS affect on marine GPS units. I was told that individaul race boats had not made appropriate updates. There is another race on Lake Erie that is not being cancelled which will run Sunday 8/22/1999. I doubt this will make the news.

-- Bill P (porterwn@one.net), August 15, 1999.

Flint,

I think you misunderstood or read too much intomy post above. I did not say there would be problems with GPS roolove and that they would be covered up.

I am saying that there will be problems with GPS and they might not be reported because it could be trivial in nature. That is unless a navigational error occurs during the race. I hope not - one of my best friends will be on one of the boats.

-- Bill P (porterwn@one.net), August 15, 1999.

Back to the 9/9/99 date. I just came across this Australian article, posted for information purposes only:

Y2K Expert: September 9, 1999 Not a Trigger Date For Disaster

12.13 p.m. ET (1613 GMT) August 11, 1999
By Ruth Pitchford REUTERS

SYDNEY  Popular fears September 9 might trigger widespread computer crashes are unfounded, Australia's top Y2K official said on Tuesday.

Graeme Inchley, chief executive of the government-sponsored Y2K taskforce, said he had asked companies in recent surveys if they had found software that could mistake the date 9/9/99 for the four nines once used as a cut-off code in some programmes.

"Everyone has reported (the risk) is minimal, if anything," he told Reuters in an interview. "Compare that with their response to the Y2K issue and it's chalk and cheese."

He said the four nines formula was never used as widely as the "millennium bug" device utilities and corporations around the world have been desperately rooting out ahead of December 31 this year.

The millennium bug fears surround the once standard use of only two digits to represent the year in dates, raising the risk date-sensitive technology would be unable to interpret the "00" in 2000 and would crash.

The four nines formula had been used for a relatively brief period, Inchley said.

And in any case, to have any impact the September 9 date would have to be represented as 9999, with none of the backslashes or full points that would normally be used to separate the numbers in representing a date.

"I'm absolutely convinced that date will pass without anyone noticing," Inchley said. "That's not to say some odd thing won't happen (on September 9) but it would be so rare as to be nothing more than the sort of bug that occurs in normal circumstances."

After months of work persuading utilities and major companies to come clean about their Y2K status, Inchley is now cautiously confident Australia will escape the doomsday scenarios still being touted in some popular handbooks.

He is currently running seminars across Australia aimed partly at avoiding what he calls self-fulfilling prophecies.

"For instance, don't pay January payrolls in December," he urges major companies.

"Not only is that unnecessary, it's unwise. It sends the wrong message, it puts too much cash out there in the community, which is a security risk, and there is no risk (of Y2K banking disruption), so why do it?"

But he is still urging Australian companies to dust off and test the contingency plans that they should have in place regardless of any millennium bug risk.

He says Y2K fears have done some companies a favor by forcing them to test longstanding contingency schemes  only to uncover unworkable plans and broken emergency generators.

-- Chris (%$^&^@pond.com), August 17, 1999.

Lake Erie is in Eastern time zone. GPS EOW rollover will occur 13 seconds before 8:00 p.m. there.

-- Lane Core Jr. (elcore@sgi.net), August 17, 1999.