|
|
You've got to be Kidding!
by Peter de Jager
pdejager@year2000.com
first published January 10, 1997
Also available in French, Spanish, Portuguese and Lithuanian
------------------------------------------------------------------------
Unless they are fixed... All computer programs... Everywhere in the world... Will go on strike on January 1st 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 31st 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 23rd, 1955. So we store that information in the computer as 23/01/55. The Wright Brothers achieved their first flight on December 17th 1903 and that's stored as 17/12/03. When we get to January 1st 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 1st 1900. That's it. That's the problem. The computer, all computers, will think that all 'dates' past December 31st 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 23rd 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 1st 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.
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 colaboration. 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?"
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'll 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're making an assumption. The speaker is not even aware of the assumption they're 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.
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% 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're 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' one 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 we 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,000,000 lines of code to change in your company.
So no matter which solution you choose, you're still left with 100,000,000 lines of code, containing an unknown number of errors, that are difficult to identify, and have to be fixed by December 31st 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 31st 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.
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 have less than 120 weekends to fix all your systems. As I write these words in early 1997, less than 35% 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% 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 proven 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,000,000 lines of code then the cost will be $100,000,000 (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,000,000 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,000,000.
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 are 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 system 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?
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,000 lines of code then your problem is very different than if you had 500,000,000 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 that 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 1st 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,000,000,000 and spread it over 3 years, that's $200,000,000,000 per year. Assume that a programmer makes $100,000 per year, (they don't today, but they soon will!) that means we need 2,000,000 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!
------------------------------------------------------------------------
Peter de Jager is an industry speaker on the topics of change, creativity, and management technology.