| The Millennium-Bug Muddle: Please Panic Early |
|---|
| From The Economist, October 4th - 10th 1997 |
CARE for a thrill? Consider what might happen if the “millennium bug”, that tendency for many of the world’s computers to mistake the year 2000 for 1900, is not eradicated in time. The new century could dawn with police, hospitals and other emergency services paralysed, with the banking system locked up and governments (to say nothing of nuclear reactors) melting down, as the machines they all depend upon stop working, puzzled over having gone 100 years without maintenance. The cover of one news magazine asked recently “Could two measly digits really halt civilisation?” and answered “Yes, yes—2,000 times yes!”.
If the world’s companies and governments really were to do nothing about the millennium bug, then dire results would certainly follow. But thanks partly to all the alarming stories and reports, that is unlikely. At any rate, given the zeal with which commentators, regulators and supervisors are lecturing the world on the consequences of millennium-bug complacency, nobody will be able to say they weren’t warned. Typically, William McDonough, the president of the Federal Reserve Bank of New York, used his big speech at the recent meetings of the IMF to drive home the point to the world’s assembled bankers:
|
|
|
Bluntly stated, if your own management and staff, or your correspondents and customers, take any of the following positions, your organisation may be at risk. • Denial. “The year 2000 is not an issue for our organisation.” It is. • No resource problems. “Our organisation can handle the year 2000 with its existing resources and within current budgets.” Very unlikely. • Vendors will address the issue. “Our outside vendors and service providers won’t let us down.” Trust is not a substitute for testing. • Covered by contract. “Our lawyers have determined that we are appropriately protected by our legal agreements.” The lawyers may get rich, but will you be in business? |
The global repair job is a formidable one, by any calculation. But just how big and how likely most firms are to meet its immovable deadline is difficult to say. Depending on who you ask, the millennium bug is either the worst crisis ever to confront the world’s information infrastructure, or just another nasty software error, to be fixed much like those that have plagued computers since their birth.
Consultancies, many of them selling millennium-bug services, tend unsurprisingly to line up with the messengers of doom. The Gartner Group, an American consultancy, says that 30% of companies worldwide will see some critical software fail because of the date problem. The resulting disruptions could halt many of their businesses, causing hundreds, even thousands, to fail. Forrester Research, another consultancy, warns of global economic consequences: stockmarkets in the West, where decades of computerisation have left the worst problems, could slump as firms suffer, while emerging economies laugh all the way to the bank, largely bug-free.
Even firms that can fix their problems in time will pay a heavy financial penalty, these consultancies say. The Gartner Group reckons the error could end up costing the world’s companies and governments $600 billion to fix. Technology Business Reports, a Californian market-research firm, goes further, counting the final cost at more than $2 trillion, including the cost of liability lawsuits and lost productivity due to crashed machines. Boston’s Software Productivity Research puts it even higher—at $3.6 trillion, when all is said and done.
Other experts, with less of an interest in stirring anxiety, have come up with smaller—but still substantial—figures. J.P. Morgan, an investment bank, reckons the cost might amount to $400 billion. Killen & Associates, a Californian consulting firm, thinks it will be $280 billion. International Data, a market-research firm in Connecticut, reckons on less than $200 billion. And BZW, a British investment bank, thinks that the direct costs of the bug could be as little as $52 billion. By these estimates, the millennium bug still counts as a serious computing problem, probably the worst to strike the industry to date—but it is hardly to be ranked alongside the Great Depression or Godzilla.
Swat
Yet this is all guesswork. No one knows how many programs are affected worldwide, how many of them are worth saving, nor even—until the fateful day dawns—how effective the solutions will be. The most reliable guess comes from talking to the companies that are actually fixing their own problems, with their own money. By and large they are fairly calm.
Firms that are a year or so into the repair job say they have learned two things. Had they done nothing, the consequences would have been ugly indeed, from complete failure of their accounting and billing systems to, in the case of some retail firms, an inability to do business at all. But solving this problem is proving relatively straightforward, if time consuming and expensive. The millennium bug, after all, is just a bug, and squashing bugs is something IT departments do every day.
Jim Bottome, IT director of British-American Tobacco, likens the millennium fix to another sort of major IT job—switching from a mainframe computer to “client-server” PC software—and says he devotes just a few days a month to overseeing the job. Jim Sutter, Rockwell’s IT director, says the Californian defence company’s millennium-bug repairs are absorbing 25-30% less time and money than the firm had allowed for, and are ahead of schedule. And David Starr, chief information officer of the Reader’s Digest Association, calls hype over the millennium-bug problem “the biggest fraud perpetrated by consultants on the business community since re-engineering”. He says that fixing the problem at his company will cost less than 5% of its IT development budget.
Various surveys suggest that most affected firms plan to spend between 5% and 25% of their IT budget on the problem between 1997 and 2000. Most appear to be on the low side of that. A survey of 700 firms conducted earlier this year by the Cambridge Information Network (that’s Cambridge, Massachusetts) found that more than three-quarters expected costs to amount to no more than 10% of their IT budget next year. Assume a 10% average and that implies a worldwide cost of about $300 billion between now and 2000. Crucially, of that, only a fraction (probably less than a fifth, according to J.P. Morgan) will be new money. Instead, most of the funding will come from regular software maintenance and repair budgets, or from pre-empting some upgrades and new systems that would otherwise have been commissioned.
For the shareholders, customers and taxpayers who must ultimately pay the bill, $300 billion may nonetheless seem like quite a lot—especially for something that offers no increase in productivity, merely the possibility of doing business as usual on January 1st 2000. They may like to know who or what is to blame for wasting this tidy sum. The answer is a strip of cardboard called a Hollerith card.
These cards were, in effect, the hard drives of the first corporate computers. They stored data and programs in the form of punched-out rectangular holes. Each had room for just 80 characters of information, barely enough for a full name, address and account number, much less a full date of birth. So to save space, programmers truncated years to just two digits—“65” rather than “1965”. Even when computers were later equipped with magnetic storage disks, memory was often the most expensive part of the machine, so saving half the space used by any date continued to make sense.
Programmers in the 1960s and 1970s reasoned that this solution would be good for decades, and would in any case have been superseded long before the next century came along to make trouble. Surely by 2001 computer-users would be plugging into HAL’s holographic brain, not still cranking through accounting code more than 30 years old.
They were wrong. Although computer hardware has indeed come far in the past 30 years, the mainframe machine is still very much with us. Today’s big IBM contraptions are designed to run software written for their great-grandfathers, albeit much faster and more cheaply. And that is because a lot of old mainframe software is still around.
Many of these programs were custom jobs, written for individual companies and government departments to do a specific task, from billing customers to paying employees. Over the years, as companies asked more of their computer systems, programmers modified the software, adding more features—but very often they retained its ancient core. Although many of the programmers who wrote the original software have retired, most were good enough to pass along to their successors their programming conventions—including the pernicious use of two-digit dates.
In principle, fixing the millennium bug is as simple as telling the software to add a “19” to existing dates and to accept only four-digit dates in the future. But finding every date in a program is difficult. In mainframe programs a date occurs, on average, once every 50 lines of code. Few are as easy to spot as “date=MM/DD/YY”. Often they are “derived dates”. How do you know that “snowball - breakeven = blossom” is actually calculating the difference between two dates? You don’t, unless you have already worked through the logic of the code to know what “snowball” and “breakeven” mean—and that, for someone who almost certainly did not write the code in the first place, is no easy task. Multiply it by hundreds of programs involving millions of lines of code in thousands of computers around the world, and it is easy to see where the big estimates of millennium-bug costs come from.
Making the problem worse are a gaggle of related date irritations. Murphy’s Law dictates that 2000 is a leap year. Any program unaware of any century but the 20th will not know that. September 9th 1999 will also be a day that lives in infamy, thanks to the programming convention that uses “9/9/99” as the code for “forever”—that is, for products that have no expiry date. And programs that calculate the day of the week for some future date, most of which use two digits for the year, are likewise going to give the wrong answer unless modified: January 1st 1900 was a Monday and January 1st 2000 will be a Saturday.
Pre-millennium tension
The results of these unfortunate programming decisions are already appearing. The Produce Palace, a retailer in Michigan, brought the first millennium-bug case to court earlier this year, suing the makers of its sales terminals because the terminals cannot handle credit cards that expire after 1999. To help prevent more of this, Visa and Mastercard have asked their member banks not to issue credit cards with such expiry dates. As the new century approaches, this has forced many of them to go from expiration after three years to expiration after two. (Visa and Mastercard say they have fixed their own systems, but plenty of sales terminals may still cause trouble.) Meanwhile, Hartford Insurance had to start fixing its systems as far back as 1988, when it realized that its 7-year bonds would crash its software from 1993 onwards.
The problem extends far beyond mainframe computers, though not always with such serious consequences. Much has been made of the worry over “embedded systems”—chips that run everything from coffee machines to bank vaults and lifts. It is said that these are just as 2000-unaware as their big brothers. In many cases this is true: many office telephone systems use two-digit dates, as do some security systems, fax machines and copiers. One manufacturer had to recall a heart defibrillator because its built-in safety feature would shut it down if it had not been serviced recently—and it thought 2000 was 1900.
Embedded chips generally cannot be fixed, only replaced. Testing them is difficult for anyone but the manufacturer, who may not as yet have given the millennium a moment’s thought. And since such chips are practically everywhere, from the factory floor to automobile brakes, it is impossible to test them all. Giga Information Group, a Massachusetts consultancy, reckons that 5% of all embedded chips—which could amount to millions of devices—will fail the date test. According to other estimates, embedded chips will account for about 30% of the total millennium-bug cost.
Yet embedded-chip experts see less of a problem. They say that most such chips track not the date, but rather the time elapsed since an event. And even when embedded chips fail, it is rarely a disaster. Video players flash “12 : 00” most of the time anyway. The worst a security system or lift is likely to do is go into hibernation until fixed. Voice mail may give the wrong time-stamp, as might a fax machine.
Nevertheless, the unpredictability and pervasiveness of such chips worry even the best-prepared managers. They seem confident that their mainframes will survive New Year’s Eve 1999 without a hiccup—but they may be unable to get into their office after the holiday to see it for themselves, or may have to shiver in an unheated room while they do.
PCs are another worry, although less uncertain. New PCs and the latest Microsoft operating-system software handle four-digit dates perfectly well. But older machines do not, nor do those sold today with older chips. One study found that 47% of consumer PCs now sold in Britain had older chips that will crash at the change of the century. Not the end of the world—on a typical day 47% of PCs probably crash anyway—but irritating.
In fact, as with mainframes, the problem with PCs is not so much the hardware and operating system, but the application software. Programs written for PCs are newer than most mainframe software, and PC memory constraints have always been far less, but the two-digit date technique is so rooted in programming convention that much PC software still observes it. Still, the latest versions of most popular commercial programs, such as Microsoft’s Excel, are safe. And any user-written spreadsheet files that use Excel’s built-in date functions should also make it through the change of century untarnished.
Black Saturday?
With wide variation in estimated costs, enormous uncertainty about the scope of the problem and mixed confidence in the repairs, the millennium bug has the potential to be anything from a hiccup in IT spending to a thunderbolt to the world’s economy. In either case, it is hard to see anything but bad news: at best, all the spending will simply retain the computing status quo; at worst it will fail to prevent an industrial catastrophe.
Yet for companies undertaking repairs there may also be unforeseen benefits. Measuring these is complicated by the fact that the returns for IT spending of any sort are fiendishly difficult to gauge, supposing they exist at all. Already, according to a survey by the META Group, a Connecticut consultancy, 30% of IT spending produces no extra business value at all; it merely pays for routine software-maintenance and repair. META expects the millennium bug to increase this burden of cost to 55% over the next 21/2 years.
But this does not have to be so. Some firms are using the millennium bug as a prod to move more quickly to the sort of software that can help their business, killing two birds with one stone. British-American Tobacco’s Mr Bottome, for example, is considering accelerating his company’s move to a new client-server system to beat the 2000 deadline. If it succeeds, that will squash the millennium bug and make the firm’s computing systems much more flexible at the same time. Likewise, Pierre Mosselmans, the year-2000 director for GIB Groupe, a Belgian retailing conglomerate, reckons that the cost of killing the bug—a 20% increase in the firm’s IT budget—will be partly offset by the benefits of carrying out such a comprehensive review of its software. The firm has repeatedly discovered other processes that can be improved at the same time.
Unfortunately, it is getting too late for most firms to switch from mainframe to PC-based software in time for the new century. A modern client-server system, for example, may take more than two years to install and another to test. Any firm that has not already started will probably have no choice but to repair what they have. For them, the returns may even be negative: after investing millions to drag their mainframe systems through the millennium, such firms will not be keen to dump them immediately for client-server software. Instead, they will put that off for a few more years, thus postponing any productivity gains a new system might bring.
Should January 1st 2000 bring civilisation crashing to a halt, with aeroplanes falling from the sky and anarchy in the streets, such concerns will not be uppermost. It seems more likely that the computing world will muddle through the millennium, one way or another. Few firms will be destroyed, with any luck—but many will be disappointed to reflect that the final years of the 20th century were spent paying for the sins of computing’s callow youth.