Most people by now have heard of the general nature of the problem—two digit years, 98, 99, 00, oops, is that 1900?—so instead I'd like to explain why it's such a tricky issue to fix, and clear up the most common misconceptions along the way.

My first physics professor once quipped about a law of physics, "I believe in Conservation of Energy. Mine." Humans, as creatures of convenience, don't like to waste any effort. As such, we've written dates with two digit years for centuries. Computers didn't invent the problem; they've simply fallen victim to it. Consider that even today you're far more likely to write the date I'm writing this article as 5/20/99 rather than 5/20/1999.

The Y2K bug is commonly ascribed to memory having been expensive years ago and programmers needing to save a few bytes. While true to some extent, the primary reason is simply that humans prefer not to waste effort. Programmers have tried to be understanding: It's a chore for users to write or type that extra "19." One might argue that programmers should have had the foresight years ago to automatically type in the "19" part so that all years had four digits, but to be honest, that's not as user-friendly as it sounds—it adds one more item users have to be trained about how to change (for dates in the 1800s or 2000s), more error checking (did you really mean 1898?), more accidents ("A98" isn't valid, please type that again), and so on. People hate using computers as it is; adding this kind of "feature," even though it seems like a good idea in hindsight, would only have made people hate computers all the more and created all the more errors over the years. Even today, programmers are bowing to user and personal convenience and writing programs that rely on two digit years—because that's how people like to do years.

Two digit years are generally not the problem in themselves. Despite the fact that the Navy found storage systems that used a date of 12/31/99 to mean "save forever" and those files might get deleted in about a year, the problem usually arises when comparing two dates. 1/1/00 is not necessarily itself a problem. It's when a program asks a question like, how many days are there between 1/1/00 and 12/31/99 that you have a potential for error. Unfortunately, comparisons are something computers do a lot of, and often in subtle ways. I know of programs whose logic is something like: "List the names of files in a certain directory, and take the last one." That doesn't sound like it has anything to do with dates, does it? You're just grabbing the end, or the "tail" if you will, of a list of names. Yet if the names of those files happen to have the year in them, say something like "ACCT9810", and the listing is put into dictionary order as is almost always the case, the "last one" will be (in the programmer's mind) the "newest". This might be how the programmer chose to program up a requirement like "get the most recent file". This works just fine today: "ACCT9811" will come after "ACCT9810" and all will be well. But starting in January, 2000, "ACCT9912" will always be the last file on the list. Poor old "ACCT0001" (for January 2000) will never be at the end of the list because of that implicit dictionary-like ordering the programmer relied on. Someone looking for Y2K problems with that program may never notice this, since the logic says nothing about dates. This kind of problem with implicit comparison of dates is widespread and extremely hard to detect.

Thus the problem is not (as is commonly reported) that "00" will be treated as "1900", but that "00" is simply not the value that mathematically follows "99" in the normal ordering of numbers. Comparisons across that boundary won't work right.

Yes, indeed, some systems will treat "00" as some strange year (1900, perhaps, or 1980 for many IBM-type PCs, most of whose internal clocks only store two digit dates), and that will cause some problems as well. Many programs written for the popular UNIX operating system used for large databases will see dates like 1/1/100, since it tracks "years since 1900", and programmers are likely not to have anticipated that this would become a three digit value. Likewise programmers who thought they could simply "add one" to get next year, like the income tax program I mentioned at the start of this article.

So what will programs do when faced with a year of 00 (or 100, or...), or faced with some bad behavior on the part of some other program they rely on? Some programs may work just fine. Some programs will quietly spit out wrong data. Other programs will refuse to process those dates, refuse to run, or simply crash. Among the universe of programs in existence, all these results will occur. Unfortunately, the one result that will be almost entirely non-existent will be thus: Programs won't be smart enough to ask for help.

Well, some, yes, but not like 1/1/2000. On August 22, 1999 the Global Positioning System (satellites that help ships and such know where they are) will roll its week counter from 1023 to 0 instead of 1024; any GPS device that hasn't been programmed to handle that will revert back to a date of January 6, 1980 (since it only stores 1024 weeks). Newer GPS devices will be fine; older ones may become confused and not report locations correctly.

September 9, 1999 is one people like to talk about: 9/9/99. My gosh, what if programmers stored this as "9999", which might look like an end of data marker? Well, any programmer who stored that as "9999" was a moron. If they did that, then they stored 1/23/97 as 12397, too. Problem being, you'd also store 12/3/97 as 12397, meaning that program would never have been telling January 23rd apart from December 3rd for as long as it's been running (and a lot of other dates too), and somebody would have noticed that long ago. (By the way, you'd store 9/9/99 as "090999", which doesn't look like anything special.) Even if there are a few programs that have code like "if day=9 and month=9 and year=99 then..." they are in the tiny minority, and not likely to be seen on any widescale basis.

The only other date of possible concern is 2/29/2000, since 2000 is a leap year. (The rules on leap years are complicated: Every four years is; unless it's a multiple of 100, then it's not [1900 was not]; unless it's a multiple of 400, then it is again.) Fortunately, the most likely error here is that some programmer didn't know of the 100 or 400 year rule, and just coded up "every four years is a leap year". Then 2000 would be; and it is; so no problem. The odds of some programmer knowing about the 100 year rule but not the 400 year rule seem pretty slim. There are a few published algorithms for date handling that have leap year rules unobviously hidden inside them that a programmer copying from a book might overlook, but not on any widespread basis. Again, there may be a few isolated problems, but that happens every day anyway. The real issue with 1/1/2000 is that it's encoded into so many programs, that if not fixed, there will be massively widespread problems all on the same day. The domino effect hits hard in a big way.

This might seem like a simple thing to fix. Just insert the century, right? The problems are, alas, numerous:

(1) Which century? A program can't know what century it is unless someone tells it. It can't know that the century has changed unless someone tells it. It can't guess which century a user even wants; they have to tell it. Most programs have no ability to "be told" anything; they have to be rewritten. Even humans can have a hard time telling what the century should be: Does 1/1/20 mean 1920 or 2020? Many programs have been written with the assumption that they only deal with one century, and have numbers like "1900" encoded as if they were universal constants, like , and will have to be rewritten to understand that this is variable.

(2) What do you do with old data? Suppose you have ten years of existing data, and it all has two digit years. You're probably adding more data to that on a daily, hourly, minutely basis; the more critical the program, the more likely this is. How do you fix all that old data? It's almost certain that you can't fix the data while you're using the program that manages it. You'll have to quit using the program for a while. Suppose you had so much data that fixing it would take more time than you can live without the data? ("Just adding the century" to data is not as technically simple as it sounds, alas.) And yes, you do have to fix your old data, since you can't compare "98" with "1998" any easier than you can compare 99 with 00.

(3) What if it doesn't fit? There are many (oh, so many) times that there just is no room for those two extra digits. Consider Microsoft's MS-DOS operating system, which is still in use on millions of computers worldwide. It only allows filenames of a certain small size (eight characters, then a period, then three more characters). If your files are named "98101511.591" (the data file corresponding to 10/15/98, 11:59am and '1' for 10 seconds, say), you simply have no room to turn that into "1998101511.591". Perhaps you can alter the prefix to be "19981015.115" and lose the minutes and second information, but this won't always be possible, and requires even more reprogramming through your system. And within programs and data files, dates are often stored in ways that don't allow for expansion. Fixing these kinds of problems requires rewriting the program far beyond just "adding two digits". These dependencies spread through the program like a drop of ink into a glass of water, making it all too easy to overlook one line of code that needs to be fixed.

(4) Who says you can fix the program? Programs are written in "source code", that is, some computer language, like C++, COBOL, BASIC, FORTRAN, etc., then translated by a "compiler" program into "machine code" that the computer itself runs. If you don't have the source code, it's nearly impossible to change the program. There are an enormous number of points of failure in fixing the source code: It might not be legally yours (such as if it's Microsoft's program; or some other company that's no longer in business, or too busy to fix the particular program you're interested in); you might have lost it (if it was custom written for you years ago, there's no telling if you still know where it is, especially if the programmers who wrote it have left your company; Y2K consultant Peter de Jager estimates 60 percent of source code has been lost); you might have it, but you can't "compile" it (you might have lost the compiler, or you've upgraded your other software so that the source code no longer compiles; computers change so much that this happens frequently). As you can imagine, many programs will simply have to be rewritten from scratch; this creates all the usual problems associated with writing, testing, and debugging new software, training users to use it, and so on.

(5) Who's going to fix the program or write these new ones? Programmers are extremely scarce right now. Consider that the overall unemployment rate is the lowest in 30 years at 4.2% nationally. For college graduates (which most programmers are), the unemployment rate is an astoundingly low 1.6%. That's assuming someone speaks the computer language you need spoken. COBOL is a dying (if not dead) language, yet many old business programs were written in it. Many old programs were written in a dialect of "Assembly language", which is a kind of very hairy, hard to read and write language, compounded by each type of computer hardware having its own dialect—and almost no programmers learn this kind of language anymore. Nor is programming something simple that just anyone can pick up a book and learn. Programming requires years of study, practice, and a certain innate talent to become proficient at.

(6) But Microsoft is just waiting to sell a program to fix everything, right? If only it were so. The fact—I repeat, fact—is that there can be no single fix to Y2K problems. Period. Each program and piece of hardware must be individually analyzed for what date-related defects it has, and each must be fixed in a unique appropriate. Programs must be rewritten by a human. No program from Microsoft or anyone else can do more than either (1) help programmers identify where problems might exist or (2) fix a very small number of easily-fixed problems. Even Sir Arthur C. Clarke got this one wrong (in Ghost from the Grand Banks in 1991 he predicted both the bug—right—and that someone would write a single program to fix things up—wrong; our level of artificial intelligence won't be at the necessary level for, oh, I'd guess thirty years at least). By and large, most programs will simply have to be laboriously looked at and fixed by a human being.

(7) What will you do about "embedded chips"? Sometimes the programs aren't even things you can easily recompile because they're encoded directly onto chips themselves. These sort of "embedded chips" are everywhere: Cars, TVs, microwave ovens, VCRs, manufacturing assembly lines, medical devices, and on and on. Now, these are hard to fix. You have to replace the chip, which really means, replace the thing itself—replace the VCR, dialysis machine, etc. Fortunately, most of these sort of chips were not written to be date sensitive. The major automakers say they don't believe there will be any substantial problems with cars. Most embedded chips that deal with time do so in terms of counters (e.g., the number of seconds since something happened) rather than days, months, and years. Even then, most don't care about what year it is. My microwave oven, for example, has a clock, but it doesn't even know about A.M. and P.M., so I'm pretty sure it'll be fine in 2000. VCRs may fail to recognize future year information, but this doesn't seem like it will cause great problems. Of course, some embedded chips do care about years. These will be difficult to detect and will likely require replacement of the whole product (which could be difficult if you wait until 2000 itself).

(8) Who says you live on an island? Programs are like science: Built on the shoulders of those who've come before. You may be able to fix those specific programs for which you own the source code, but they may make use of many other programs. Spreadsheets are a good example: You might fix the spreadsheets you've written to use four digit years, but what if the spreadsheet program itself processes dates. Your programs almost certainly rely on other programs to do their job. Even if you fix yours, you're still at risk from the ones you can't fix. Large companies and government agencies are comprised of tens of thousands of programs cobbled together. A failure in any one of these can disrupt an untold number of others, which in turn disrupt...

(9) And have you thought about testing? Once you think you've fixed a program, it must be extensively tested under real world conditions. This is one of the hardest parts of programming, and the least well done. To begin with, testing programs is itself a difficult task. Programmers frequently don't know exactly how users will use the program (and may not understand the underlying disciplines — a programmer writing a medical program is almost certainly not a doctor). Users themselves are poor testers, since when asked to test a program, they use their limited time to test the most likely things they do. Alas, it's the unlikely things they do that most need testing. The only true test is to put something into live use (with the corresponding problems of what happens if a bug is found—people could die, etc.). Many companies don't have a complete set of duplicate hardware to create a 100% simulated "live" environment. And if you don't control 100% of the hardware, you may find that while your own parts work fine, the parts you don't control may say "huh???" when you set your date ahead to 1/1/2000 to test, foiling your ability to test. A survey by the Gartner Group found that only half of the companies fixing millennium bug problems planned to test their fixes.

Bank on it. Between people and programmers who take the wait-and-see, "it probably won't be too bad" attitude and those at the other extreme too scared of liability to admit to anyone that it'll be a hell of a mess, yes, it will be a helluva mess.

On May 18, 1999, CAP Gemini America, a New York consulting firm, surveyed the largest companies and reported that 22% said they do not expect to have all their critical systems tested and ready by January 1st. This is up from 16% last August. "Critical" systems are those without which the company cannot function. Thus over one fifth of large companies will not be functional. I probably need not add that such estimates are usually low.

On August 15, 1998, the U.S. Office of Management and Budget reported that, overall, of the government's 7,343 mission critical systems, only 50% were Y2K compliant. This includes those systems that were already compliant and needed no work (implying that the 50% remaining will take longer to repair than the first 50%, since (a) some of the first 50% needed no work at all and (b) the easiest programs to fix are the ones usually fixed first). Of the agencies listed as showing "insufficient evidence of adequate progress" are the Departments of Defense, Education, Energy, Health and Human Services, State, and Transportation. The only agencies "appearing to be making satisfactory progress" were the Environmental Protection Agency, the Federal Emergency Management Administration, the National Aeronautics and Space Administration, the Social Security Administration, the General Services Administration, the National Science Foundation, the Nuclear Regulatory Commission, the Small Business Administration, and the Department of Veterans Affairs. The remaining agencies were described as showing "evidence of progress, but [the OMB] also has concerns."

I'm glad to see that NASA and the National Science Foundation will meet their goals; but I might rather trade them for the Departments of State and Defense if it came to having a choice which ones would be fully functional in 2000. By the way, these are only the agencies own information systems, not the information systems of those sectors of the economy each represents. For example, the North American Electric Reliability Council has been asked to report to the Department of Energy by July 1, 1999 that mission critical systems needed to maintain the integrity of the interconnected power distribution grid have been tested and will be ready for the year 2000. I'm not exactly sure what one can do, at that late date, if they report that it won't be ready...

Nor does it bode well that, according to a Cap Gemini survey reported in the August 31, 1998 Infoworld, "the percentage of companies missing year-2000 milestones rose from 78 percent in April to 81 percent in July."

Dare I point out that those 7,343 systems the OMB is tracking are only the "mission critical" systems? The OMB does not list how many other systems there are, only that "most agencies have completed their assessments". Most? Have only assessed?

Non-critical systems are those that, if a single one of them goes down, is not a problem. This overlooks what happens if a whole lot of them go down. That's likely to be a problem. Hiring lots of people to "just do things manually" when unemployment is already about as low as it can go just won't work. That's like a dozen starving people eyeing an apple pie and each thinking, "It'll be okay; I only want half..."

All this from a government that is notorious for meeting its own projected deadlines. (Wink.)

Outside the government, there's a reasonable way to find out how a public company is doing: Read their annual and quarterly reports (see the EDGAR database at www.sec.gov). Check for yourself.

Statistically we should now be seeing a fairly decent percent saying "we are totally ready" (not "we will be ready by...") I sure don't see many saying that. Some, yes; but not enough to reassure me. And watch those "will be ready by" dates as they slip. What, programming projects being late? About 75% of the time.

Most companies originally projected their Y2K readiness date as the end of 1998. Then these dates slipped to the end of March. Now that date's come and gone, we're seeing end of June, September, even end of 1999.

For example, the gas and electric where I live is provided by New Century Energies. In their quarterly report (form 10Q) filed in November 1998, they said this:

Approximately seventy percent of the remediation and testing phase for all critical IT [Information Technology] systems will be completed in 1998 with the remaining portion being completed in the first quarter of 1999.

(emphasis added). In their annual report (form 10K), filed three months later, they said:

approximately 77% of the remediation and testing phase for all critical IT systems was completed in 1998 with the remaining remediation and testing planned to be completed by June 30, 1999.

Oh—and...

Remediation and testing for non-IT systems [i.e. power "generation, transmission and distribution areas of the business"] were approximately 46% complete at December 31, 1998, with the remainder expected to be completed by September 30, 1999.

Ouch.

Back to the original question: Is this really going to be a problem?

The chance that absolutely nothing will go wrong is: absolutely zero.

Now, don't get me wrong, I don't want to see the end of civilization as we know it any more than the next guy. I dearly hope I'm proven wrong about this.

But let's look briefly at some of the possible problems you should prepare for. All of these are almost certain to happen somewhere.

Remember, as you read these, that fixing a single y2k problem requires massive reprogramming, testing, debugging, possible wholesale replacement of entire systems (which may be unavailable for purchase), training, and so on. If you get hit by one of these, don't expect it fixed any time soon. Weeks at the earliest, months being the most likely, years in the case of non-life-threatening issues.

So what's on the menu?

Lack of power. The national power grid is tightly tied together, such that what one utility does has immediate impact on the others. Remember the blackout in July of 1996 in which a few damaged switches plus the interconnections of the power grid led to over a million people losing power in eleven states? Or the 1965 outage in the Northeast? Given the number of utilities, and the sheer number of possible y2k points of failure, it is certain that there will be many power failures. If the government is wise, they'll keep nuclear reactors shut down over the date rollover. Unfortunately, nuclear power accounts for approximately twenty percent of U.S. power generation (fifty percent along the east coast), which will further strain the grid. For areas that survive mostly intact, rolling blackouts may yet be instituted to both spread existing power resources evenly and help supply power to neighboring areas that are worse off. Many sites have generators, but often stock only a few days worth of, e.g., diesel fuel; and acquiring more when everyone else needs some too is not a sure thing. In the longer term, power generation relies heavily on the adequate supply of coal. If coal isn't getting where it needs to because of the factors listed below, expect more outages. Whether the grid sees another domino effect of cascading failures again, or simply whether you're unlucky enough to be in one of the areas hit by a localized failure, be prepared for a loooong wait.

Lack of other utilities. Water, gas, sewer, telephone, etc. also all rely on computers for distribution and management of their services. Even if the power remains available for pumps to continue pumping water to you (which is not assured if there were a prolonged power outage), pumps and whatnot are themselves computer controlled, and subject to direct or indirect failure. If your heat goes out and you live in a cold climate, figure that lots of pipes will freeze and burst, and that it will be a long wait for a plumber.

Shortages, long lines, painful delays. Manufacturers of any conceivable product may find themselves unable to produce their wares, ship their wares, etc. A rumor I heard from a grocery store data processing fellow was that their inventory control system was almost certain to fail and that they'd be unable to fix it in time. If there are any large scale problems (which will be first seen in New Zealand, Australia, etc. since they get midnight first), anticipate that grocery stores will be picked clean during December 31, 1999. Elevators keep track of their last maintenance date, and shut down if they're too long out of maintenance. Should a lot of elevators sit on the first floor and refuse to move on January 1, 2000, anticipate some stair climbing until technicians can visit them all. Presuming that gas stations can pump gas for their cars, or have any gas from the refineries to pump, or have working inventory systems to know where to send the gas. And let's not forget, those employees who don't have frozen pipes and make it in for work may have to suddenly do everything manually. That's if they know how to do things manually. Counting change seems to be a lost art, for heaven's sake. Lack of training in manual procedures, and the extra time cause by manual procedures are sure to create extraordinary delays everywhere. Delays which beget more delays. That's if you can get the labor. I see "now hiring" signs almost everywhere I go today—confirming that unemployment is very low. I'd almost say we have "over"-employement. How can we cope with immediately needing drastically more physical and clerical labor? And training them? Over time, sure, businesses will fold up and those people will get retrained for other jobs. But that will take many months (years, for highly technical jobs). So, assuming shipments arrive sporadically and nobody has enough help, plan to choose carefully which lines you spend your day waiting in.

Cash and bartering. Credit cards and ATM machines may not work, for a variety of reasons (their own software may fail, the power may be out, the phones may be out, the ATM machine may be out of cash, etc.). Depending how bad things get in your area, you may find yourself bartering. Plenty of people won't have taken anyone's advice and will be hankering for things like food, water, alcohol, cigarettes, etc. Cash will likely still work, but the prices may make your jaw drop, thus your best bet may be to trade necessities.

Fragmentation of the Internet. The entire Internet itself is not likely to go down. It was designed with widespread disasters in mind, and has a great deal of redundancy in it. However, it is likely that it will turn into an ever changing kaleidoscope of connected pockets. Assuming your ISP is running, and you can reach it, where you can go from there may change on a second-by-second basis.

Medical problems. Patient care, both critical and non-critical, is largely computerized now. Who's to say if a given dialysis machine is Y2K-compliant or not? What if hospitals refuse you for non-emergency care because they can't verify your insurance? What if hospitals take anyone, regardless of insurance, and can't get reimbursed? What if hospitals can't get supplies?

Billing/statement failures. This one seems to get the most press of all the Y2K problems. Beyond any doubt, yes, you will get strange bills and financial statements. However, these are the most easily solved problems of all: Keep your records. Now, it may take some time to convince the IRS that you don't owe them a hundred years' interest, but everyone will be so inundated with these things that everyone will understand, and it will (eventually) get straightened out. But keep all your old statements, bills, cancelled checks, etc. to prove you're in the right. Businesses will also be on guard for people making fraudulent claims, and will undoubtedly expect you to prove your case.

More lawsuits than you can shake a stick at. Expect everyone to be suing everyone else. Even businesses who've survived in tact and are fully functional may find their customers suing them just because their lawyers say to sue everyone. Remember, anyone can sue anyone else for any reason, regardless of their chances of winning, and it's costly in time and money to defend yourself even if you're 100% innocent. Congress is attempting to limit this, but even if they do it right, that doesn't prevent lawsuits, only helps defend against them, which may still be costly.

Business failures. Companies unable to function under such conditions may not survive at all. A survey of businesses in the United Kingdom found that 10% were certain their software would be failing in 2000. In a survey of Japanese companies performed by the Tokyo Stock Exchange in August 1998, less than 10% said they had achieved Y2K readiness. The Gartner group estimates that 50% of all companies, worldwide, will suffer at least one "mission critical" Y2K failure (i.e., one large enough that the entire business may fail). They also reported that, with about a year to go, 23% of businesses had not even begun to investigate their Y2K exposure. Given how long it takes to correct and test such problems, and how interdependent the world is, the rate of business failures and disruption is likely to be extraordinarily high.

Stock market crash, global recession. It seems like a foregone conclusion that the stock market will drop precipitously when these other factors kick in. Stock prices depend on corporate earnings, which will be almost certainly decimated both by companies being unable to provide their products and services, and by their emergency spending to get back up and running. The Gartner Group currently estimates it will cost on the order of $600 billion to fix Y2K problems. Bear in mind that this is probably (a) underestimated (Cap Gemini reports that 87 percent of companies say they've underestimated their Y2K costs) and (b) will go up dramatically after they have problems in January 2000 and need "immediate" fixes. Even at $600 billion, that's approximately five percent of the market capitalization of all the major U.S. stock exchanges combined. (Keep in mind that the $600 billion is money that must be spent; market capitalization is money on paper only. Five percent of most large companies market capitalization represents on the order of one entire year's earnings, which is what stock prices are based on.) Edward Yardeni, chief economist of Deutsche Bank Securities, puts the chance of a serious, 1973-74 sized global recession as high as 70 percent.

Lunatics. I hate to even say it, but with all the confusion, possible rioting and looting, with the police and national guard spread thinner than is useful, this is a ripe time for lunatics to pull crazy stunts. I don't think I'm doing any harm here by mentioning it, since the lunatics have probably all thought about it anyway; so everyone else might as well be prepared. If someone took hostages, for example, would the police be able to mobilize their best response, when they've got the rest of a city falling apart around them? Remember that we only employ enough police/etc. to handle routine matters and perhaps one localized crisis per city. There are a bit less than a million law enforcement personnel in the country. The National Guard represent less than half a million more. Presumably the rest of the military could be mobilized in some fashion, but this still looks to be a bit weak to maintain 100% order in the face of large-scale Y2K problems. I wouldn't count on outside help. Remember, this will be global, not localized like a hurricane that devastates a single area. Your area might be fine; or not.

As I said, I truly hope I'm proven wrong, and look like an utter fool in 2000. But I'd rather be a fool tomorrow than correct today and not have urged people to action. Besides, most of what you can do isn't so extravagant that you'll have hurt anything if your preparedness turns out to be in vain. So what if you're stuck with a few cheap cans of beans? This is truly a case where an ounce of prevention will be worth a pound of cure. Be prepared.

So, play along with me, and ask yourself, What would you do if you knew October 1929, the Great Depression, and Hurricane Andrew were coming on a specific date?

As an individual, you can...

(1) Have a survival plan. I hope you don't need it either, but (a) it's cheap and (b) better safe than sorry, eh? So, act like every city in the country will be hit by a category five hurricane. Have food and water enough for a few weeks for your family and pets. Nobody can predict how long a given problem might last, but I should hope society can feed people once it gets itself mobilized. You need not store gourmet food. Heck, cans of beans will do in a pinch. Have several months supply of any medicines you need. Have a plan for how you'll keep warm if your power goes it (assume it'll get as cold indoors as the coldest your area gets in January; if that's 25 below, plan for 25 below!). Talk with people who have a wood-burning fireplace where you might stay. A small generator is something to think about. Consider how you plan to protect your supplies should nasty folk discover you have them. I'm not generally big on guns in the house, but this is the case that convinced me to buy one and learn how to use it. Make sure you have adequate fire extinguishers. Definitely have a battery powered radio handy, with additional batteries.

(2) Know your neighbors. Know what skills they have (doctor, plumber, ham radio operator, etc.). Having a plan for 24-hour neighborhood guard duty rotation may not be a bad idea in case there are massive shortages, which could cause looting.

(3) Have communication plans with distant family. That is, arrange a low-tech plan for contacting anyone you feel you might want to contact (out of state siblings, parents, children, etc.). Unfortunately, without power and internal software, most means of communication won't work, so plan every manner you know of—make sure you have phone numbers, addresses, email addresses, etc. Remind everyone to check their email. The Internet is not likely to fail in entirely no matter what, though it may fragment and bounce like a yoyo. Your own Internet Service Provider may not be working (consider having multiple ones, and email addresses or web pages via the numerous free services like Yahoo, Hotmail, Juno, or Geocities). Another idea for getting the word out to relatives is to set up private web pages where you could disseminate information to anyone who can get there. Even if your mother in Podunk can't get to her own ISP, she might be able to find a public Internet kiosk and get to your web page. Yahoo and other portals offer private messaging groups that can serve a similar purpose. Set up several and let everyone know where they are, since you can't predict which services will be working or that you can reach. Likewise, remember to check all your communication paths frequently.

(4) Spread the word. While it is too late to prevent problems, it's never too late to mitigate damage. Talk seriously with your family and friends. The more people are mentally prepared (and physically prepared), the less panic will occur. Make sure your company has a plan for both fixing what it can in advance and a plan for coping with the mess when it arrives.

(5) Lobby Congress. Congress, in its infinite inertia, is not (to my knowledge) preparing any sort of contingency plans, and is enacting only very cautious legislation. Congress and your state legislatures can and should:

Establish and communicate national/state emergency plans

Encourage citizens to be ready, have food, water, battery powered radio, etc.

Create emergency shelters stocked with food, etc. and publicize their locations in advance

Act on all the points below for businesses (e.g., train government workers in manual procedures, etc.)

Establish a government agency to coordinate fixing corporate Y2K problems

Streamline and expand the number of visas for skilled foreign workers

Limit Y2K problems as grounds for lawsuits

Further limit liability in exchange for disclosure of Y2K problems

Allow sharing of Y2K information that would otherwise violate anti-trust laws

Offer tax-credits for Y2K preparation work

Relax inventory tax laws to allow stocking up on supplies and finished product

Plan to quickly offer operating loans to companies that suffer

Offer Y2K insurance

As a business owner/manager, you can...

(1) Fix what you can now. Of course, it's too late for everyone to fix everything, but the more that's fixed, the easier it is for everyone.

(2) Have a disaster plan, and let everyone know what it is. Assume that any individual thing that could go wrong, will, and let your employees know how they should handle each eventuality.

(3) Train your employees in manual procedures. Assume any given computer system of yours may not work. Your cash register. Your inventory control system.

(4) Cross-train your employees. Assume that any given employee may not make it in to work, because their pipes froze, etc. Have two or three other people who know the rudiments of everyone's job. This includes jobs from janitorial to executive.

(5) Document your plan. Have copies (on paper) readily available at every work site. Then if all four of your cross-trained tiddlywinkers are out, your grimblepritzer can read fast.

(6) Decentralize your management. If you have multiple sites, assume communication won't exist between them. Let the local management know what they're supposed to do.

(7) Stock up on raw materials. Whatever your business buys to do business (parts or raw materials for products you produce, office supplies, etc.)—have plenty on hand. You may not be able to get everything for a while after January 1, 2000.

(8) Produce extra products. Likewise to stocking up on raw materials, stock up on your finished products so you'll have them available to those who need them, should you find yourself unable to produce more because you can't get supplies, your own systems are down, etc.

(9) Arrange duplicate distribution channels. Do so for both raw materials and your finished products. You can't guess who'll be up and running.

(10) Arrange loans in advance. Set up emergency credit lines you can draw on should you find you can't get supplies, but still have payroll to meet, etc.

Well, for the short term, I doubt it; but for the long term, absolutely. Y2K preparations offer tremendous opportunities for businesses to reinvent themselves, to do things right. And, of course, all those failed businesses simply create voids for entrepreneurs to fill with new ones.

The other good news is that most of the preparations you make as an individual are neither costly nor difficult.

Hope for the best—but prepare for the worst.