Reality Bytes

When the clock strikes midnight on December 31, 1999, computer systems large and small will grind to a halt. Are you prepared for the year 2000?

Your systems are guilty until proven innocent. That message, from technology consultant and year 2000 evangelist Peter de Jager, is directed at every single company that depends in some way on computers. To date, most people have treated the so-called Millennium Bug--a programming anomaly that is expected to cause widespread computer malfunctions at or even before the turn of the century--as a COBOL kind of thing, of concern only to the legacy-bound Fortune 1,000. But saying that only mainframes are vulnerable to Y2K misfires is like saying that only large countries have wars.

The Millennium Bug, in case you haven't been paying attention because you thought it didn't apply to you, is the product of programmers' age-old tendency to represent dates with the year expressed in two digits (mm/dd/yy) as opposed to four (mm/dd/yyyy). They did that for a number of reasons: First, it saved storage space. Second, they figured their systems wouldn't make it to the turn of the century. And third, they didn't think not to.

As a result, on January 1, 2000 (or more likely a few days later, because January 1 falls on a Saturday), people are going to turn on their computers and find that their systems either refuse to perform tasks involving dates and ages or hopelessly mangle them. The problem is already making itself felt, as organizations begin dealing with dates--expiration dates for example--that fall in the year 2000. And it's happening not only to mainframes but also to a great many of the PCs that constitute the small-business computing base.

Experts warn that no company is immune, although, as with most illnesses, some populations are more at risk than others. If your computers are only one or two years old and you're running Windows 95, then there's a pretty good chance that your hardware and operating system are OK (though you should still check them). But if your hardware is three or four years old and running DOS or even Windows 3.1, "I guarantee it's going to roll over and die," says Edward Yourdon, a software-engineering consultant and author, with his daughter Jennifer, of the year 2000 screed, Time Bomb 2000 (due out from Prentice Hall in early 1998).

When the clock strikes midnight on December 31, 1999, most older PCs will reset their internal hardware clocks to 1980. And that means that any program, including the operating system, that determines dates by reading the internal clock is going to become seriously confused. So, for example, a system that deletes the oldest backup file of an accounting database each time it creates a new backup file is actually going to eliminate the most recent file.

As for software, companies that assume their vendors will step into the breach with free or affordable Y2K-compliant upgrades are deluding themselves, says de Jager. "The reality is that a small company may have purchased its business package 10 years ago, and the vendor may not even be in business," he points out. "If that's the case, and that application is not year 2000 compliant, then that business is going to have to buy a new package."

If the vendor is still around, the first step is to contact the company and find out where its product stands compliance-wise. De Jager suggests involving legal counsel at this stage. "A lawyer can make it very, very clear in a letter that you will be making business decisions based on the information that the vendor gives you, and that therefore the vendor will be held liable if the information it provides you is incorrect," he says. "Use some legal weight to get some honesty."

No matter what the vendor says (or what you think) about your system's adequacy, it's still smart to test everything that's mission-critical. There are a number of ways to do that, including putting your applications through their paces using a variety of date combinations falling before and after January 1, 2000. For example, an invoice application might use three dates: date sent, date due, and date paid. First try setting all three dates in 1999. Then use 1999 as the sent date and due date, but make the paid date 2000. Then put the sent date and paid date in 1999 and the due date in 2000. You'll have to do a separate test to be sure that the software can handle February 29, 2000, because--as if this all weren't entertaining enough--2000 is also a leap year.

De Jager recommends having a professional do the testing "because the systems person, when he or she is testing, has the goal of making it fail." It is also imperative to back up everything or, ideally, to run the tests on a stand-alone machine. "Sometimes when things go wrong, they go wrong in spectacular ways," warns de Jager.

If any of your systems screw the pooch, you have several options. If the problem resides in a package from a major player like Microsoft and you're just a version or two out of date, then all you may need is an upgrade--usually a relatively trivial expense. But many small businesses lag further behind, having bought their software years ago and having seen no reason to update it.

"Now they have a problem," says de Jager. "Can they go directly to the new release, or will the vendor tell them they have to go through all the intermediate steps--paying at each stage? Or do they have to buy the new release outright? Either way, it's an expense and it's annoying."

It's even more expensive and annoying when you factor in the hardware and operating-system improvements that updated software requires. Then there are the costs associated with industry-specific, vertical packages--for insurance companies or manufacturers, for example.

"Anything you bought recently is probably under warranty," says Yourdon. "But if you bought a package several years ago for $10,000 or $15,000, you may end up paying 10% of the purchase price for a Y2K-compliant upgrade"--that is if one is available. Surprisingly, the highest-ticket item may well be one most people never even think of: the telephone switching system.

"A company with 50 or more employees is likely to have a PBX, and that can cost $50,000 to $60,000 to upgrade," says Yourdon. For that reason most small companies upgrade as infrequently as they can--and consequently may find themselves five or six very expensive versions away from Y2K compliance.

Companies with home-grown programs face the arduous task of combing their code for dates and fixing them manually, after which everything must be tested again. Although a number of tools automate part of that process for COBOL, none of the experts we interviewed could name more than one or two that tackle Visual Basic, a popular programming language among many small companies. (There are a few tools for C and C++, but none of them are cheap.)

Nor can you count on outside help. "Consultants aren't going to come knocking on your door," says de Jager. "A consultant is better served by going after a Fortune 2,000 company because that company has a larger problem and a larger cost of fixing it, and therefore the consultant can make more."

If fixing the code yourself proves too daunting--or if it was written in primordial times by someone long gone and it can't be deciphered--it's probably best to do some bullet biting and invest in a packaged product. Another factor to consider when making that decision: the Emerging Issues Task Force of the Financial Accounting Standards Board ruled in July 1996 that any money a company spends modifying its own code to deal with Y2K complications comes right off the bottom line.

The cost for all this ranges from a few days' time spent calling vendors and checking machines--if everything is fine--to $100,000 or more if everything must go. That prospect may tempt you to relegate the problem to the grease-stained ledge behind the back burner. But if you do, "you're giving up responsibility for managing your systems in the year 2000," says de Jager.

That's an abdication your customers may be unwilling to accept. Increasingly, large companies are trying to enforce Y2K compliance on their small suppliers. The big three automakers, for example, have created a Y2K-compliance definition and checklist that suppliers are being asked to fill out and return. (It's available on the Web at

Meanwhile, according to a recent article in the British publication Computer Weekly, telecommunications giant British Telecom has a color-coded system for rating suppliers' preparedness. Companies coded red are in danger of getting the boot.

At Mack Trucks Inc., in Allentown, Pa., year 2000 project manager Barry Sine recently sent letters to all business-unit heads asking them to check their own suppliers' status. Enclosed with each of Sine's cover letters were two others: one from Mack to the supplier and one from Mack's legal department to the supplier's legal department. "We say that Mack considers this very serious and ask them, 'Where do you guys stand?" says Sine. "'Are you working on it? What are you doing? If you don't have it fixed, when do you plan to have it fixed?"

The letters also urge the companies--which service Mack directly--to contact their own suppliers, "all the way down to mom and pop," says Sine. "Even Harry working in his garage with one PC needs to give a darn."

Mack's letters are mostly informational, but embedded in at least one paragraph is the hint of a stick: "In our view, failure on the part of any company to prepare for and resolve year 2000 failures constitutes negligence and, as with all acts of negligence, exposes the negligent party to claims for damages. Mack will not hesitate to aggressively prosecute year 2000 system-failure-related claims."

That kind of warning may bring home to some small companies the fact that fixing Y2K problems is an inevitability that cannot be postponed. "This is a fixed deadline for everybody," says David Eddy, president of Software Sales Group Inc., in Wellesley, Mass., and a self-proclaimed year 2000 alarmist. "No small or large company has ever experienced a fixed deadline. People say tax deadlines are fixed, but if you don't pay your taxes, do you suddenly go poof on April 16?

"With this," Eddy says, "you'll go poof."

Leigh Buchanan is the editor of Inc. Technology.


The Web is rife with year 2000 material. Check out for Inc.'s library of relevant links. The following books are also available from and other retailers:

  • Managing '00: Surviving the Year 2000 Computing Crisis, by Peter de Jager and Richard Bergeon (John Wiley & Sons, 1997). User-friendly reading--a nice combination of managerial strategies and brass tacks (including a rundown on Y2K tools).
  • Solving the Year 2000 Problem, by James Edward Keogh and Stephen C. Ruten (Academic Press Professional, 1997). The bad things that can happen to good systems plus a five-step plan.
  • The Year 2000 Problem Solver: A Five-Step Disaster Prevention Plan, by Bryce Ragland (Computing McGraw-Hill, 1996). The five steps in question are based on the U.S. Air Force's approach to solving its Y2K problem. Includes some information on small- and home-business issues.
  • The Year 2000 Software Systems Crisis: Challenge of the Century, by William M. Ulrich and Ian S. Hayes (Prentice Hall Professional Technical Reference, 1997). A good tool for figuring out what the Millennium Bug may do to your organization.