Some say that the biggest winners in the looming Year 2000 computer crisis will be the lawyers who profit from the resulting litigation, while the biggest losers will be the computer programmers who are stuck with the task of fixing the millennium bug.

Explains one programmer, "If you try to do the job right, you'll work yourself to death. If you don't do the job right, you'll get fired." How exactly does one go about exterminating the millennium bug? Why is it so difficult? Who really understands the predicament in which these programmers find themselves?

To get top executives and business owners to understand the gravity of the Year 2000 (Y2K) problem, experts often emphasize that it is not just a technical problem.

That is entirely correct. It is not just a technical problem, but the technical aspects alone are enough to drive computer experts crazy.

Godzilla on the loose

It doesn't take a rocket scientist to understand the basic problem. In many computer systems around the world, software has been written to store and manipulate dates using only two digits for the year. Now that we're about to enter a new century, these dates have to be changed to four digits. To solve the problem, we just need to hire computer programmers to find the dates and change them all.

Easier said than done, unfortunately. In Computer Crisis 2000, Michael Fletcher uses the example of changing a light bulb to illustrate the nature of the problem. It is not difficult at all to change a single light bulb, but suppose you were given the task of changing all the light bulbs in your entire community? 10 watts, 60 watts, 100 watts; fluorescent tubes, halogen lamps, auto headlights, neon signs, flashlight bulbs, Christmas lights. . . . There are light bulbs everywhere. You don't even know where they all are. Some are in empty homes that you're not allowed into. Some are old-fashioned bulbs that went out of production years ago. And worst of all, you've only been given two weeks to complete your task, with absolutely no possibility of extending the deadline!

Actually, the light bulb example oversimplifies the Y2K problem. Computers are linked together into networks, and networks are linked to other networks. A light bulb doesn't begin to compare with the complexity of a computer. The reason why some people think of Y2K as a virus is that the problem is capable of spreading from one computer to another.

For example, the tax authorities in many countries now allow taxpayers to file electronic returns, but the people filing their returns may or may not be using Y2K-compliant computers. When a bad date is entered into a tax authority's computer system, the system has to be capable of recognizing, isolating, and correcting the date problem, otherwise the defective date can result in erroneous tax calculations, and the system itself can be damaged.

Furthermore, no matter how fancy a light bulb may be, it's still pretty much the same as other light bulbs. Dates, on the other hand, can be recorded in many different ways in a computer. This makes it more difficult to find where they all are. Some may be overlooked.

For the average user, there is no big difference between the various date formats one typically runs across. When you take a close look at computer programs, however, you will find that in some cases the order is day/month/year (DDMMYY), while in others it is year/month/day (YYMMDD), and there are many other combinations of these three elements. For the sake of convenience, some programs record all dates as simple numbers. The number 8796, for example, might refer in some systems to the 8796th day of the 20th century. In other programs, a number might represent the nth day of the current year. Some application programs have their own peculiar date formats, depending on the needs of the company. There are accounting systems, for example, which divide the year into 13 months, each one four weeks long. And here's one for the "don't-know-whether-to-laugh-or-cry" category: Computer programmers have been known to use their child's name to represent the year in which that child was born!

Says Chiang Shu-shang, a Y2K expert at the Corporate Synergy Development Center, "I used to think the millennium bug was just a tiny problem, but it's starting to look like an entire pride of Godzillas lying in ambush."

Unbeknownst to the general public, these Godzillas have already been around for quite a few years. Back in the 1960s, there was a big controversy within the information technology community about how to deal with these monsters.

Short horizons

Because memory capacity was extremely expensive in the 1960s, many software engineers routinely used a single digit for the year. The number 5, for example, meant 1965. Then everyone had to get busy and change these dates when 1970 rolled around.

So why didn't that experience teach people a lesson? The answer to that question shall forever remain a mystery. Some suggest that it is because computers were not widely used in the 1970s. Perhaps the people who wrote software at that time never imagined their programs would still be running in the next century. It could also be argued, perhaps even more plausibly, that the technicians of that time felt optimistically that the problem would take care of itself in due course, as if some all-powerful being would wave a magic wand and make it go away!

Unfortunately, with just 200+ days remaining until the turn of the century, that magic wand is nowhere in sight. Thanks to our procrastination, the millennium bug has become an extremely serious problem with no easy solution.

Jack Chen, Chief Engineer in the Marketing Division at Syscom Computer Engineering Co., spends his days tracking down and eliminating millennium bugs. Every day he must examine thousands of lines of code. Only half in jest, Chen complains that he sometimes can't help exclaiming in frustration, "What idiot wrote this crap?"

But be careful! Our predecessors are not the only ones who will ever deserve criticism for lack of foresight. We may now be suffering the consequences of their mistakes, but we could well end up victimizing future generations with mistakes of our own. Most of the Y2K solutions being implemented today are nothing but stopgap measures designed to postpone the day of reckoning for a few years. Programmers of the 21st century will continue to be plagued by descendants of the millennium bug.

Explains Jack Chen, "The year shouldn't be recorded with two-digit numbers. You need to expand to four-digit numbers. That would be the most complete solution to the problem." To do that, however, all the year-dates in all programs must be converted to a four-digit format, and then all the year-dates in every single file ever created must be changed over as well. Files have to be changed to a different format, and the revised files require more storage capacity. The cost of these changes is prohibitive for many companies. Analysts abroad have estimated that no more than 20% of all companies have opted for this method so far.

There are a number of quick fixes available that cost less money. One of the most common tricks is known as "windowing," whereby a program's baseline year is used as the dividing line between the two centuries. If you're running a bank that was established in 1958, for example, you might pick 50 as the baseline. Any year-dates greater than 50 are assumed to belong to the 20th century, while any year-dates less than that are assumed to belong to the 21st century. 58 automatically means 1958, while 48 means 2048.

With the windowing method, only programs are altered, while data files are left untouched. This method will only work, however, within a range of 100 years. Furthermore, in a large system, different applications might require different dates as the baseline, and as time goes by it could be necessary to shift baselines forward or backward. The effort of maintaining this sort of makeshift system is a great nuisance, but it has thus far proven to be the most popular means of dealing with Y2K.

What about "Y10K"?

Another quick fix takes advantage of the fact that in the Western calendar, every date in the year falls on the same day of the week in year n as it does in year n +28 (i.e., if January 1st fell on Friday this year, it will fall on Friday again 28 years from now, and every subsequent date all the way through December 31st will also fall on the same day of the week as it did this year). This fact allows programmers to push back the clock 28 years-back to the 1970s! If a computer is programmed to add 28 years before producing any output, the result is all the same to the user, who is blissfully unaware of the hoops the computer has just jumped through.

This practice of turning back the clock 28 years (known in the industry as "decrementing") has a peculiar variant in Taiwan, where the Western calendar exists side-by-side with a date system which takes the first year of the Republic of China (1912) as year 1. In other words, people in Taiwan can refer to the current year as either 1999 or the 88th year of the Republic of China. It is simply a matter of personal preference. Some programmers are dealing with the Y2K problem by programming computers to interpret ROC year-dates as Western year-dates. With this fix, the date field for the current year, for example, reads "88" instead of "99," but the number 88 is interpreted to mean 1999. Voila! The millennium bug won't bother anyone for another 11 years! Others arrive at the same result by taking the last two digits of the Western year-date, adding 89, and subtracting 100, i.e., 99 + 89 = 188 - 100 = 88. Once again, this keeps the millennium bug at bay for 11 more years.

If the gravity of Y2K is so clearly understood, why is it that most companies choose these band-aid solutions instead of going for a permanent fix?

You can ask this question until you're blue in the face, but you'll never get an answer. One systems expert even jokes, "If you think we've got a problem now, wait until the year 9999!" If human civilization is still in existence by then and technology has continued to advance all that time, the chances are that computers will be humming away on Mars and points more distant still. Imagine the frustration of our descendants in the far-flung reaches of space as they grapple with the "Y10K" fiasco!

The engineer as archeologist

The "bug catchers" that we depend on to get us through this crisis have got a tough row to hoe.

Wu Tseng-feng, Business Manager for Software Sales and Support at Hewlett-Packard Taiwan, compares the task of "bug busting" to peeling an onion-the more layers you peel away, the more you want to cry. Wu, the Y2K point man for HP Taiwan, confides that the problem has given him an entirely new appreciation for the mysteries confronted by science.

Wu emphasizes, "We don't know what we don't know." We are under pressure because there are so many unknowns.

Customers are counting heavily on providers of services, software, and hardware to guarantee safe passage come January 1st, but Wu warns, "You simply can't give a 100% guarantee for software." Even if you examine every line of code and correct every problem you find, you still can't be sure that a particular program will function properly.

Even though the Y2K crisis has created intense demand for programmers and sent wages skyrocketing, the work is so tedious that many do not consider the money sufficient compensation.

Jack Chen explains, "Every software engineer wants to be working at the bleeding edge, but tracking down Y2K problems is nothing more than a boring check of line after line of code written in out-of-date programming languages such as COBOL and FORTRAN."

James Fu, chairman of Hytec Systems and Consultants Co., reports that his company refuses all of the frequent requests it receives to help companies deal with Y2K.

"The Y2K market is going to disappear on January 1st. Why should I be concentrating on a short-term market like that? And what about all the extra people I'd have to hire? Do I really want to turn right around and fire them?" Fu points out that advances in the software industry occur at a dizzying pace, and if he poured his resources into Y2K, his competitors would leave him in the dust in less than two years. Who wants to make that kind of sacrifice?

Another factor that makes Taiwanese information services firms reluctant to handle Y2K business is the fact that people here are not sufficiently aware of, or concerned about, the millennium bug. It is generally accepted overseas that cleaning up the Y2K problem costs about US$1 per line of code, and that this price will climb as the millennium approaches. According to H.L. Chen, deputy assistant general manager at Computer and Communication Integrated System Inc., "You can only charge about one-third that price in Taiwan." He reports that his company is preparing to seek Y2K business in the United States.

Bearing bad tidings

Information services firms can refuse any job they're not interested in, but in-house programmers have no choice but to tackle the problem.

David Lin, a former Executive Vice President of Yulon Motor Company, spent last year acting concurrently as the director of the company's Information Center. As such, he is keenly aware of the arduous task these programmers face. Yulon decided to respond to the Y2K problem by overhauling its entire computer system. The task is placing a heavy load upon the shoulders of the programmers.

"For a while, we would all take a break every evening at 11:00 for a late-night bowl of noodles or something, then we'd come back and keep at it until we couldn't keep our eyes open any longer. Then we'd stagger back to the company dorm to go to sleep. Our favorite piece of black humor was to say, 'Yeah, we get off work earlier than anybody-3:00 in the morning.'"

Because Y2K measures cost a lot of money without contributing to the development of new products, top executives and company owners tend to look at them as an unwanted burden. They seldom take a close look at the state of their companies' Y2K efforts, but when they do find out that the problem has not yet been solved, they generally get quite angry. In this type of atmosphere, there is an almost universal tendency to avoid delivering unpleasant news to one's superiors.

A programmer at a 2000-employee company in the service sector was sent by his company to listen to a speech on the Y2K issue, and he was shocked at what he learned. His company had done nothing to address its Y2K problem. He found himself in a dilemma about whether he ought to give an honest report on what he had learned.

"It's too late to do anything about it," he thought to himself, "and besides, I don't dare be the one to deliver the bad news, because it might get my boss fired."

Says Chiang Shu-shang of the Corporate Synergy Development Center, programmers at a lot of companies are planning to retire before the end of June. They put a brave face on it, saying that they're going to use the Y2K problem as an opportunity to go into business for themselves, when in reality they're just abandoning ship before the Y2K time bomb blows up in everyone's face.

James Chan, a systems engineer at Hewlett-Packard Taiwan, recounts a joke that has been making the rounds within information technology circles: A programmer could no longer take the pressure of his Y2K work, so he decided to look for a job with some other company. Every company he interviewed, however, wanted to hire him to work on their Y2K problem. With no escape route available, he opted for cryopreservation. Before climbing into the freezer, he set the timer to have himself thawed out after the turn of the century. Unfortunately, no one ever heard from him again, because he forgot to fix the millennium bug in the microchip that controlled his freezer!

Encouragement needed

Austin Lin, who is in charge of the Y2K effort at IBM Taiwan, takes a different attitude toward the situation. In his view, programmers ought to take a more positive view of their work and approach it with a sense of mission.

IBM Taiwan is now hiring new employees to tackle the company's Y2K problem. During the recent lunar new year holidays Lin received a lot of calls from colleagues interested in leaving their current jobs to work at IBM, but he told them all, "I'm sorry, but I don't want you at IBM. What would your company do without you? Who would take over your responsibilities?" In a speech to more than 200 of his colleagues, Lin said, "No matter how much you hate your boss, and no matter how ignorant your boss is, you have to think about your hundreds of co-workers. Their livelihood depends on the hard work that you are putting in. Working on Y2K is like running a marathon. Regardless of whether you win or lose, you've got to keep going to the end."

Austin Lin's words have proved a great inspiration to many. Maybe it would be a good idea if all of us gave a little more recognition to these unsung heroes.

p.22

Outside the sites of Y2K-related lectures, information companies peddle their own solutions to the Y2K problem. (photo by Pu Hua-chih)

p.25

A Y2K Threat Calendar

Date Reason for potential malfunctions

1999/1/1 The transitional year begins; "99" could be a special code in a chip, leading to problems.

1999/4/9 The 99th day of the year, which may appear as 9999; this could be a special code, leading to problems.

1999/9/9 Calendar date 99.9.9; again, if this is a code with some particular meaning in a given chip, problems could result.

1999/12/31 Last day of 1999.

2000/1/1 First day of 2000.

2000/1/3 First business day of 2000.

2000/1/10 First appearance of seven-digit dates.

2000/2/29 Extra day; 2000 is a leap year.

2000/10/10 First appearance of eight-digit dates.

2000/12/31 Last day of 2000.

2001/1/1 First day of 2001.

Notes:

* Pay special attention on the last day of each month and each quarter.

* 1999/8/21: Global Positioning System timers reset to zero. Unless adjusted, many GPS receivers will automatically reset to 1980/1/5, and cease to function; this could, for example, cause planes to go off course.