***More specifics on the Year 2000 Problem are found in de Jager’s 1997 Web offering, "You’ve Got to be Kidding!" You’ve Got to be Kidding! Unless they are fixed... all computer programs... everywhere in the world... will go on strike on January 1, 2000. Can you imagine... just for a moment... the chaos this would cause? There would be no air traffic, no traffic lights, no lights in your company, companies could not produce goods, no goods delivered to the stores, stores could not send you bills, you could not send bills to anyone else. Business would come to a halt. Could such a catastrophe happen? Well, if you read this article and think about the consequences, then you’ll decrease the likelihood of this unsettling event. If you ignore this warning, or fail to ask yourself the question, "Could this happen?," then you become a part of the problem. How could computers possibly go on strike? The explanation is very simple, so simple, that many people like yourself, have great difficulty believing the problem is real. After December 31, 1999, computers won’t know what year it is. This sounds insane. It sounds like a science fiction story. It just happens to be very true. Here’s why. We programmed computers to store the date in the following format: dd/mm/yy. This means that we’ve allowed 2 digits for the day (dd), 2 digits for the month (mm) and only 2 digits for the year (yy). Can you see the problem? Some examples might help. I was born on January 23, 1955. So we store that information in the computer as 23/01/55. The Wright Brothers achieved their first flight on December 17, 1903 and that’s stored as 17/12/03. When we get to January 1, 2000 we’ll store that information in the computer as 01/01/00. See the problem yet? We’ve told the computer to assume that 23/01/55 means 23/01/1955, and that 17/12/03 means 17/12/1903. What will it assume 01/01/00 means? It will assume that 01/01/00 means 01/01/1900 or January 1, 1900. That’s it. That’s the problem. The computer, all computers, will think that all "dates" past December 31, 1999 are 100 years in the past. So what? To understand the implications of this little error, we must look at one of the most basic, and most common, calculations performed by the computer. The calculation that determines how much time has passed from one event to the next. For example, how old are you? I was born on January 23, 1955. If I ask the computer how old I am, it subtracts my birthdate from the current date. So it’ll perform a calculation similar to 96-55 (remember it only has 2 digits for the year information) and gives me the answer of 41 years old. Which, while unfortunate, is also true! On January 1, 2000, the calculation will be exactly the same. Subtract my birth year from the current year, 00-55 and the computer will loudly and proudly proclaim that I’m -55 years old. Which is silly, and wrong, and will cause havoc with every type of interest calculation in every program in every company in every country, worldwide. It affects more than just interest calculations. It affects all information based on time. When will your driver license expire? When will your credit card expire? When will this drug no longer be safe? When should this machine undergo regular maintenance? When was this product built? How long has this invoice been overdue? Has this subscription expired? All of these calculations are based on the date, and if the computer does not know what date it is, then these calculations are no longer possible. If I were a mind reader, I’d say the thoughts in your head at this moment would be a collection of "How could computer programmers be so stupid? Didn’t they know the year 2000 would arrive? Why didn’t they store all 4 digits for the year?" And last, but not least, would be, "Well... just put the extra digits back into the program! How difficult could that be?" These are very natural responses from anyone just hearing about the Year 2000 Computer Date Crisis. The listener becomes even more incredulous when I mention that the estimated costs of fixing this problem are upwards of $600 billion (US) worldwide. $600 billion to fix 2 missing digits, otherwise all the computers worldwide go on strike... you’re right. It does indeed sound like science fiction. Unfortunately, it’s not. It’s very real and affects everyone on earth. Why Only 2 Digits? Let’s answer your obvious questions. "Why did we use only 2 digits when we knew we’d need 4 of them when the Year 2000 rolled around?" Well, the bad news is that we did it deliberately, but with the very best of intentions. Honest! When computers first entered the business world in the late ‘60s and the early ‘70s, they were very expensive. This ?expense’ was tied directly to two aspects of computing, how much data could the computer store and how fast could it process that data. Even tiny, incremental increases in either attribute resulted in huge cost increases. One way to store data, was on a piece of stiff cardboard known as a Hollerith card. By literally punching holes into this Hollerith card according to a set of patterns, and reading those patterns with a beam of light, one could store and retrieve information. Each of these cards had enough space to hold only 80 characters of information; 80 characters is not a lot of information. Write down your full name, address, birthdate, bank balance and bank account number. The chances are very good you’ll have written down more than 80 characters. Which means you’d have trouble storing all that necessary information onto a single Hollerith card. This is exactly the problem programmers ran into in the late ‘60s and early ‘70s. Hollerith cards were not big enough to store all the data they needed to store. So they compromised. They wrote 230155 instead of 23/01/1955, thereby saving themselves 4 precious characters, 2 of which were the crucial "19." When designing a computer application you’re always making compromises. There are compromises between what you’d like the computer to do and what you can afford. You compromise between the speed of delivery and the quality of the final product. Hopefully, you understand the consequences of the compromise, because compromises are never perfect solutions. We compromised on accuracy vs. cost when we decided to store only 2 digits of the year. Our reasoning, even now, makes a lot of sense. Especially if you keep in mind when this compromise was taking place. It was the ‘60s and ‘70s, when the year 2000 was 30 or 40 years away! Part of our reasoning was that surely our code would be replaced by then. We assumed that the program we were writing in the ‘60s would not be in use 30 years from now. That particular assumption was wrong, very wrong. We have way too much old code, known as "legacy systems" in use today. Major applications are still using code developed in those early days. Another interesting fact to take into account is that the programs were written by programmers who themselves were most likely less than 30 years old. Surely their code would not last longer than they’d been alive? It seemed a very reasonable compromise to make at the time. Also, keep in mind, compromises are never made in isolation, compromises are always a conspiracy or collaboration. Computer managers would tell the client that if they stored all 4 digits, they’d have to buy a bigger computer or they’d have to write a much more complicated program to store the data of 2 or 3 or 4 Hollerith cards. The client would typically respond "Are you crazy? You want me to spend another million dollars to store an extra 2 digits that won’t even be used for 30 years! Just store the 2 digits and leave me alone! In fact, store a single digit and save even more money?" Compromise Becomes Standard So, this compromise became an industry standard. Computers have remained very expensive until only the last decade, when it became possible for nearly anyone to purchase a computer for their home. These home computers are much more powerful than the computers used by entire businesses in the ‘70s. Trouble is, while computers changed, the standard didn’t. Many programmers, even as you read this, are writing code that will fail in the year 2000. Why? Because business is not very proactive when it comes to anything happening after the next annual report. Our focus is on immediate cost savings, immediate profits and immediate consequences. We’re not very good at looking out into the future and planning for events that’ll take place 5 years in the future. Another unfortunate chapter in this story is that computer "professionals" are very mobile. It is unusual in the computer industry to work for a company for more than 5 years. Why worry about a problem that will take place in the future, when you’ll most probably be working somewhere else? "Okay," you say, "How we got here is understandable, but surely the problem is easy enough to fix. Just put the 2 digits back in... how difficult is that?" Well, in a sense, it’s not difficult at all. Practically any programmer can look at a line of code containing a date calculation, and make the necessary changes to the program to make the problem go away. The problem is... that’s not the problem! When someone makes the statement, "Put the 2 digits back in," they are making an assumption. The speaker is not even aware of the assumption they are making, which makes it all the more dangerous. The assumption is that we know where the dates are. That’s right. We don’t know where the dates are, we have to go find them. Finding them is a large part of the problem, for two reasons. First, do you have any idea how much programming we’ve done in the past 30 years? It is not unusual for a company to have more than 100,000,000 lines of code! (For the purposes of this article, assume your company has 100,000,000 lines of code.) 100,000,000 is not a number we run into very often, and it’s rather difficult to get a sense of just how much work that represents. How long would it take you to just look at all that code, if you spent just one second on each line? Assuming 8 hours a day, 5 days a week... It would take you just over 13 years to look at all your code. Or it would take 13 people one year. Or 156 people could do it in a month. So the haystack we’re searching, to find all these little date needles, is huge. What’s A Date? The problem though, is more than just the sheer size of the haystack. The problem really lies in the next, almost philosophical question. What’s a date? That’s not a facetious question. It’s very serious. It sits at the heart of this whole problem, and if we had a clear, 100 percent accurate (and useful!) answer, then the problem would be much easier to solve. To understand the complexity of the question "What’s a date?" we need to understand a key concept regarding computers. Computers are idiot savants. They perform miraculous tasks, but have no understanding of what they are doing. One way to describe computers is to assert that they are nothing more than symbol manipulators. The symbols themselves have no "meaning" to the computer. The symbols might mean something to us, but to the computer they are "just" ones and zeroes being manipulated according to the rules we’ve defined. When the computer subtracts 55 from 00 and offers the result of -55, it does so following the rules of arithmetic and does so correctly. The answer it provides is arithmetically correct. It’s correct until - - we - - decide those numbers represent years and since these numbers don’t contain all the necessary year information, the answer is meaningless. It’s meaningless because 00 should represent 2000, but we have instructed the computer to "assume" that 55 represents 1955 and also that 00 represents 1900. And these incorrect instructions result in the error. If we had labeled all the dates according to some naming standard, for example all dates must be prefaced by the word DATE. Then finding the dates in our programs would be easy. We didn’t create such a standard. (Hindsight is a wonderful skill, pity it’s not around when you need it!) Dates have been labeled everything under the sun. Everything from ?Bdate’ (for Birthdate) to Snowball (for reasons known only to the programmer). So the advice that we should "Just add back the 2 digits," while well intentioned, is, to put it kindly, useless. There are some other alternatives to the "just add in the 2 digits," although this happens to be the simplest to communicate. Here are two more "solutions" to the problem. Create another bit of data known as the "century" indicator. If the indicator is set to 0, then the year of 55 refers to 1955, if it’s set to 1, then 55 refers to 2055. This is a little bit more complicated and takes more time to communicate. It also creates a second problem. Will all companies use 0 to indicate "19" or will some of them use 0 to indicate "18" and 1 to indicate "19"? Another solution, much more complicated to explain and therefore much more susceptible to error, is to use "date logic" to have the computer determine the proper century. For example. If I’m entering in new birth records to the computer for the purposes of enrolling students into kindergarten, then I can assume that any year greater than 90 is a "19nn" year and that those less than 10 are "20nn" years. Of course, I’d either have to update this "date range" on an annual basis or have the computer change the range depending on the current date. (I warned you it was more difficult to explain!) There are other more esoteric solutions to the problem. None simpler than what we’ve already described and all suffering from the same failing... there are still 100 million lines of code to change in your company. So, no matter which solution you choose, you’re still left with 100 million lines of code, containing an unknown number of errors, that are difficult to identify, and have to be fixed by December 31, 1998. 1998? That’s another part of the bad news. No matter how much code you have, no matter how much budget you have available for this task, no matter how skilled you are at the conversion, you have the same deadline. December 31, 1998. You must be complete by this date so you can test the hundreds of thousands of changes you’ll have made to your applications. Full Year of Testing You’ll need a full year of testing because you need to test the full suite of applications required to process the full fiscal year for your company. You must do this before the year 2000 because, it is risking the business to discover errors when you have no idea how long it will take to fix them. Meanwhile, your production line is stopped, you’re unable to bill your clients or ship your product, because the programs which drive these functions are not working. As of September, 1996, you had less than 120 weekends to fix all your systems. As I write these words in early 1997, less than 35 percent of North American businesses have addressed this issue in any significant manner. Based upon informal surveys, Europe is even further behind, with less than 10 percent of organizations actively solving this problem. Those companies who have begun to address the issue, have never overestimated the amount of time required to solve the problem. The problem has always proved to be larger, uglier and more costly than anyone imagined. Costly... more costly than you can imagine. Those are chilling words. Yet we have to talk about the cost. How much will this cost to fix? A mercenary consultant might ask, with an evil grin... "How much do you have?" Here is a very rough guideline being used in the industry: $1.00 for every line of code. Which means that, if you have 100 million lines of code, then the cost will be $100 million (Please keep in mind that this is a very difficult project to estimate and the final cost will be dependent upon a hundred different variables). Remember how big 100 million was? If you spent a dollar every second 8 hours a day, 5 days a week, it would take you more than 13 years to spend $100 million. Companies have discovered to their amazement it will take them hundreds of years to solve this problem. That they must place 30 or 50 people on the project. That these people will do nothing else for the next 2 or 3 years but work on the Year 2000 project until the problem is solved. Other companies are suggesting someone will come up with a simple solution. That they can leave the problem until later, because like in the old cowboy movies, the cavalry will ride in to save them at the last moment. Those experts who have studied this problem in depth agree on very little, but they do agree on one thing. The likelihood of a magical solution is non-existent. Personally, I don’t gamble much, and I certainly never bet on a loser, so I’d suggest a different, less risky strategy. So it’s big and it’s ugly, and unless you solve it, the computers go on strike. Where do you start? You start by checking to see if the problem is real. The only good thing about this problem is that you don’t have to believe this writer or anyone else who claims this problem is real. All you have to do is examine your systems to see if a date of 01/01/00 will be processed correctly. Before you start examining your business systems, open your purse or take out your wallet and examine all the documents you carry. Look at your bank card, your credit card, health card, driver’s license, insurance, identification card, etc. etc. How many of them contain 2 digit years? How many systems that use the data contained on these documents will assume an expiry year of 00 implies 1900? To continue this mini-audit, go to all your systems and see if they accept 4 digit dates. If they don’t, then the chances are very good that those systems will be adversely affected by the year 2000. Then get a bit more aggressive in your testing. Start entering some test information into your system. Where the computer can only accept 2 digit years, enter 00 as the year and see what happens. If it accepts the data, don’t rejoice too soon. Wait until the computer tries to process that data and look at the results. Did the computer assume the 00 year was actually 1900? If it did, then you now have conclusive proof that you have a problem. What are you going to do about it? That’s the key question. Will you ignore it until your system fails? And then try to fix it? Or will you fix it now? Steps to Fix It To fix it, you must follow these steps. Appoint someone as responsible for making sure your company can sail into the future and not crash against the reefs of 00. Someone who has no other responsibility except making sure your company can operate in the Year 2000. If you try, as some have tried, to make this a part time responsibility, you’ll fail. You’ll fail because, if this is not a first priority, then there will be too many other demands on this person’s time and the project will either never start, or it’ll never finish. Next, you need to find out how much code your have in your organization. If you only have 50 thousand lines of code, then your problem is very different than if you have 500 million lines of code. The first thing you’ll find out as you try to identify how much code you have is that no one will know the answer. Why? Because we’ve never had any project that spanned the entire organization. Companies have found that just getting the answer to that first basic question takes anywhere from 3 to 6 months, sometimes longer. While you’re getting the program inventory together, you can start taking a look at what tools and services are being offered by the blossoming Year 2000 conversion marketplace. Despite what I said earlier about the difficulties in identifying dates, there are some very good tools available to perform automated inventories. There are also some extremely clever tools that can actually change some, not all, of your code automatically. The ability of these tools to help in the process depends greatly on what language you used to develop your applications. Be prepared for some disappointment when examining these tools. Chances are there will not be any tools available for a substantial portion of your program inventory. There are close to 500 programming languages used to develop applications. Most of these conversion or inventory tools are directed toward a very small subset of those 500 languages. A majority of the tools are focused on COBOL, the most popular business programming language in the world. Very few tools, if any, have been designed to help in the area of APL or JOVIAL for example. Once you’ve selected a vendor from the hordes of vendors entering the fray, you’ll be ready to perform your first impact analysis. The purpose of the impact analysis is to determine in greater detail the nature of your problem. There are important questions to be answered. Which are your mission critical systems? These are the systems that MUST work each and every day, otherwise you cannot do business. When will they fail? Many systems will fail before the Year 2000 arrives. They’ll fail early because for some reason the application uses dates in the future. An example is a car rental agency which accepts driver licenses that expire in the future. Once you have the information from the impact analysis, you can begin to create the project plan. Which applications must be changed? And when must they be ready? How many people will you need at each phase of the project? What are your critical deadlines and what will you do as you begin to miss deadlines? Unlike every other project you’ve ever been on, this one has immovable deadlines. You cannot miss the January 1, 2000 deadline. It will NOT be postponed. On that date, your systems will be on strike and will not work again until fixed. If your accounting system fails, then you will be unable to produce any invoices until it’s fixed. How long can your organization survive without the ability to bill for its services? With a project plan in place, you can begin the largest, most important project you’ll ever work on. The road will be long, difficult and with the most uncompromising deadlines you’ll ever face. There is only one good bit of good news in all of this, and that is that salaries for programmers are expected to skyrocket in the coming years and company after company discover the Year 2000 problem is real and that they do require the services of a finite number of programmers. (Of course this will not be good news to those who have to pay these salaries, seemingly to people who caused the problem in the first place!) Do the math. Take the estimate of $600 billion and spread it over three years, that’s $200 billion per year. Assume that a programmer makes $100,000 per year, (they don’t today, but they soon will!), that means we need 2 million programmers working on this, each year for the next three years. And all because programmers tried to save space on a Hollerith card 30 years ago!
Finally, de Jager sets a philosophical tone in these additional Web comments.
It would be amusing if it were not so sad. What a pitiful commentary on our well proven ability to overcome adversity.
I’ve been at this battle longer than most and my message has always been the same. The code is broken, let’s fix it. In the beginning I was described as a doomsayer... today I’m seen as a moderate. Amazingly, by some, I’m now even described as a Pollyanna!
The message never changed. What changed was the general awareness of the problem. I have never underestimated the size or the severity of the problem. The code is broken. If today (August 5, 1998) were the first day of 2000, then civilization as we know it would stop and people would die. Having food, guns and money would be a good idea. But, it’s not January 1, 2000, it’s today.
We are now working on the problem.
Yes, we started late.
Yes, some management folks are still clueless.
Yes, our leaders are nervous and at a loss as to what to do.
Yes, the problem is serious.
Awareness and understanding continue to grow. As it grows, more and more unnecessary activities are being put to the side. As we move forward, urgency increases and the difficult decisions are finally being made. We’re finally facing the problem and beginning to treat it with the respect it deserves.
Will we fix everything? Of course not. But I honestly believe the mission critical stuff will get done. And where it doesn’t get done, work arounds can, and will, be found.
Why this belief that, what must get done, will get done? For 7 years I’ve been baffled by the thick headedness of some individuals, the press, management and the politicos...How could they ignore and deny what could be, and was, demonstrated time and time again ? that the code upon which society depends is broken...
...But I have seen one behavior pattern play out over and over again. Once someone gets it, no matter how difficult it was for them to get it, once they get it, they become fanatics about fixing it. Nothing else matters, everything else is put to the side and they become maniacal in their dedication. And, perhaps more importantly, they infect others with their zeal.
Consider some of the absolute worst cases imaginable. Please note, I’m not saying the following are going to happen or are even likely, I’m using the worst examples I can find to make a point. The point is, we’re not helpless children lost at sea in a fierce storm, we’re grown ups, capable of fixing things when they break:
Social Security checks don’t print on January 1, 2000?
Reprint the printfiles for the cheques you printed last week. And do that week after week until you fix what you now know must be fixed. A perfect solution? No! It stinks to high heaven. But it serves 99 percent of our immediate need.
Train switches don’t work automatically?
Put men with lanterns along the tracks. An inhuman use of people, but the trains will move. If the switches no longer have manual capability, then replace them with those that do... none available? Build it! Take a piece of track and lay it down so it can be moved manually by a gang of men using crowbars... a ludicrous image? Of course it is... will it work? It worked for more than a hundred years... Will it handle the current level of traffic? Of course not, but Beanie Babies are not a vital part of our economy, don’t ship them for a few weeks... or would you rather curl up in a corner and die?
FAA not ready or not 100 percent certain the systems will work okay?
Don’t fly the planes at the same rate you’re currently flying them. There are airports all over America which have no computers, no radar, no electronics, period. Planes take off and land every day. Is this a desirable situation? Of course not. But would this slowdown in air travel cause the death of civilization? I sincerely doubt it.
No dial tone? Worldwide?
That’s unlikely in the extreme. Why? Because no matter how pessimistic you are, you have to concede that some of the people we’ve hired must be competent. So... no worldwide lack of communications.
No dial tone? In local areas?
We’ve already been without dial tone for days and weeks at a time. Ice storms, hurricanes, earthquakes, etc., etc., are all recent examples. Did we survive them? You’re reading this, so I guess your answer is yes.
Nuclear power stations go boom?
After a while, the solutions become childlike... turn the damn thing off if you’re not 100 percent sure. Will turning it off have an impact on the power grids? Of course it will but, if planned for, the systems can handle the load. Will there be problems with the Grid? Of course there will but, once isolated, the problems can either be fixed or bypassed.
A worldwide recession?
Ahem... been through a few of those myself. Lived to tell the tale.
You get the general idea - - for every problem, there’s either an ugly way to avoid it, or an even uglier way to cope with it. Let’s move on.
Remember, part of the Year 2000 problem, perhaps the largest part, is that we don’t know what will fail in advance, so we have to fix everything which might break.
However when it breaks, and we’ll see enough computer breaks to last us a lifetime, we almost immediately know where the break is. True... we’ll fix a problem, only to have a new one crop up and have to fix it again and have the same thing happen again and again. This is not going to be pretty, but the notion that we should all run for the hills is truly silly.
Why? Because it’s like finding a hole in the boat, giving up immediately, and jumping overboard, only to either drown anyway in the deep water or looking like a fool standing in a foot of water.
Nobody, but nobody, knows how this one will shake out. Let’s at least try to fix it, before we give up.
Don’t misunderstand me. I’m not against contingency plans for applications and/or services. I live in Canada and they have lots of snow up here. It gets rudely cold in winter. Having a generator in the garage has always been a good idea. If I go for a long drive with my family in the dead of winter, it is irresponsible for me as a parent not to have some emergency supplies in the trunk.
But moving to the South Sea islands to escape the mere possibility of an ice storm AND advising everyone else to follow me, is irresponsible at a totally different level.
The Year 2000 project is most likely the largest, and most important, project we’ll ever attempt. We could, I guess, look up at it and say to ourselves, that’s too big for little 'ol me and run away to mommy.
For myself? I guess I’m just an arrogant SOB, I’ve never yet come across a problem too big to tackle...
So, I guess my final question to you is this... are you an arrogant SOB? If you are, then hang on, the ride gets interesting from here on in.
Yours in defiance of defeatism, Peter de Jager firstname.lastname@example.org
Peter de Jager is considered to be the world’s foremost leader in creating awareness of the Year 2000 Computer Crisis, speaking to technical and general audiences throughout the world and appearing on network television. He writes extensively on the subject and comments through his Internet home page, The Year 2000 Information Center. In Congress, he has testified before the House Science Subcommittee, and he has been invited to speak before the World Economic Forum in Switzerland and the Canadian House of Commons Standing Committee on Industry. A graduate of the University of Toronto, he serves as a special advisor to the United Kingdom Taskforce 2000.