All right, I’m exaggerating a little, but not much. Here are a couple of examples that are not exaggerated. First, how do you create quality programs when there is a complete reorganization of Management Information Systems (the computer department) every two weeks? This included changes of managers, supervisors, team members, and areas of responsibility approximately every two weeks for a period of months.

And, remembering my remarks about the Programmer as an Artist Syndrome, how do you keep productive between dodging rubber band wars when you walk in on a December morning and find two four-foot tall electrically animated 1890's-costumed boy and girl figures (the kind you see in department store windows) flailing away at each other under the Christmas tree while locked in a sexual position best known for its numeric designation? (I hurt myself laughing at that one!) Each day thereafter, they were in a different position. Later the Christmas tree was decorated with red panties.

Doesn’t that sound like something straight out of Dilbert? It’s amazing what people (myself included) will do to try to avoid burnout when faced with bizarre working conditions.

So much for explanations of Y2K-related (and many other) bugs. Now, what are you going to do about it? First, you have to decide on which of two major strategies to take, using either free or commercial testing software. If you have a small, very structured environment with a limited number of tightly controlled programs, you can use a mostly manual approach. In this case you start out by using one or more of the dozens of free programs available to test individual PCs for Y2K compatibility. Almost every company that makes a full, commercial Y2K program also makes a free, simple one to test the underlying PC hardware for Y2K compatibility. In addition, many national magazines publish their own free Y2K utilities. Needless to say, Web access is required.

This free software will automatically put your PC into one of three categories, compatible, incompatible but patchable (basically a system clock problem), and simply incompatible. If the tests result in a compatible rating, then you’re home free. If your system is patchable, then many of these free testing utilities will automatically install a free software patch. From that point on, every time your computer boots up, the patch will override incorrect information and provide valid dates. If the system is rated incompatible, you might still be able to salvage the system by replacing the BIOS (Basic Input/Output System) chip on the motherboard, if an appropriate chip is available.

You will have to use your own judgement as to whether it is worth the trouble to keep an older machine that needs a new chip, or just toss it. Note that even older machines may be useable as hardware assembly and repair training aids for some charitable organizations and that PCs are considered hazardous waste. Give a call to the National Christina Foundation at 1-800-CHRISTINA or check their Web site, www.cristina.org for further information.

After testing the PCs themselves, you must individually research each and every piece of software on every PC. You then must upgrade, patch or reconfigure each as specified by the publisher to make that software Y2K compatible. Now you know why I specified that this fully manual method was only practical for environments with limited complexity.

For more complicated and less structured environments, commercial Y2K software is required. (Of course you could always take the traditional MIS attitude which would hold that if your System Administrator is on salary, working that Administrator 24 hours a day, seven days a week to avoid paying for commercial Y2K software is permissible!) Not only will this type of software do the hardware test, and, apply a patch if necessary, but the better products will even coordinate version checking and will scan data for possible problems.

In version checking, the product is supplied with a database of Y2K facts about various versions of common software, updateable via the Web. It checks your systems for programs and uses its database to tell you what patches, fixes, or upgrades are required. While you still have to apply these patches, fixes, and updates yourself, this still saves a lot of time and potentially some trial and error experimentation.

Data scanning finds documents, spreadsheets, and databases which contain date-oriented data that is stored in ways that might make it vulnerable to Y2K problems. A human will still have to examine the results of the scan and decide what to do about it.

We have come full circle and are back to the WHY in the title. If you are informed by a software publisher that a specific version of their product is Y2K compatible, are you safe? Not necessarily! The people who allegedly cured the Y2K bugs are the same people who put it in there in the first place. Wait - it gets worse! Those people who created the bugs in the first place now have enough seniority to get assigned to new development projects, so the ones doing maintenance tasks like bug-fixing are the beginners right out of college or trade school, so they are probably even more likely to mess up the bug fix and maybe even generate their own new bugs.

Remember that Windows 98 was supposed to be Y2K compatible right out of the box, but now has a Y2k fix available. Just because a company says its software doesn’t have bugs doesn’t mean it’s true.

Finally, as in the example I gave in the first article in this series in which I explained how I was ordered to put in a limited decade-only date fix and found previously entered limited fixes, there is a right way and there are many wrong ways to fix the Y2K bug. The right way is to put in a fix that covers September 9, 1999 (9999 in computer format), January 1, 2000, February 29, 2000, all future leap years, and any artificially generated date limits created by programs which arbitrarily pick a start date for the creation of the universe and count up from there, potentially running out of digits at some arbitrary date in the future.

Sadly, lots of companies, government agencies, and especially consulting firms are allowing limited fixes that are marginally quicker to install and test, but will break again in the future. In many of theses cases, the internal MIS folks or the external consultants are not telling management that they are taking these shortcuts. Their excuses are the usual ones. "It looks good in my quarterly budget to fix this problem cheaply." "This program won’t be around long enough to break." And the ever popular, "I’ll have another job somewhere else by the time this program breaks, so I won’t be around to get blamed." Of course, the outside consultants have the added motivation of getting paid to fix the problem again in the future.