Less than 1000 days remain until the beginning of the next century and also the next millennium. Most of us look forward to January 1, 2000 with excitement and anticipation. The current millennium has borne witness to great advances in art, medicine, education, and science. In particular, this century has brought forth the greatest technological achievements. Computers were central to technological development during the last half of this century. Between 1950 and 1970, computers were used by a relatively small number of people in universities and large companies. However, today, most people use computers at home and in the workplace. Most young children today are even more computer literate than their parents are, or ever will be.
Most companies depend upon computers for their very existence. Years ago, it was not uncommon to see a vast office area with rows of desks hosting mechanical calculators. Many employees used these calculators and slide rules for their daily work. Secretaries transcribed hand written notes from dictation tapes to typewritten drafts that were revised by their authors and then retyped many times. In modern times, computers have replaced the vast army of workers often performing mindless tasks. However, office automation, unexpectedly, did not eliminate jobs. Because of increased productivity, companies could now devote their efforts toward previously unaffordable tasks. Consequently, non-computerized firms became unable to compete in today's marketplace.
Now, imagine a disaster occurring that would cause a company's computers to become non-functional. How long would essential operations within that company be able to continue? How long could the company continue to function before being forced into a business shutdown? A banking or financial institution could continue operations for two days. A wholesale or retail distribution company could continue for a little more than three days. The longest survivor would be an insurance company. Here, because the work is so paper intensive, operations could continue for four-and-one-half days (1). In the event of such a computer disaster, a company could restore vital data from a recent backup or resume operations on another computer at a disaster recovery hot site. These eventualities are normally part of a company's contingency and recovery planning. However, imagine that this company's computers do not fail suddenly. Suppose that its data becomes corrupt gradually over a period of months prior to discovery. Now, the backup data is also corrupt, and moving to a hot site is useless, since the company's computers are still operational even though they continue to spew forth garbage. A disaster of this type would be fatal, since either the paper trail is now lost or it would be too costly to fix the problem.
If the loss of a single company's computing capability could wreak such havoc, imagine this scenario occurring simultaneously for every business in every industrialized nation throughout the world. This would represent a disaster of unprecedented proportions. It would result in the collapse of the global financial structure. Banks would be unable to dispense or receive funds (2), manufacturers would be unable to ship goods or to collect debts, and insurance companies would be unable to pay claims. As great an effect as there would be on businesses, the effects on the social infrastructure would be unbelievable. The IRS, Social Security Administration, and other governmental agencies could grind to a halt. Telephones could cease to operate (3), airplanes could stop flying (4), medical equipment could malfunction (5), and hospitals could lose patient records. VCR's and coffee makers would no longer be programmable (6). Even some military operations could cease. A science fiction or political intrigue movie might begin with a global computer disaster such as this as a prelude to world conquest. But, of course, this scenario cannot actually occur. We are only discussing science fiction -- right? It can't happen -- or can it?
This scenario can actually occur if every computer in the world were to be simultaneously infected with a common bug or virus for which an automated antidote could not be administered. There are millions of computers in operation throughout the world. For such a global infestation to occur, it would require decades of preparation.
The aforementioned science fiction plot assumes a sinister effort. It might depict a malcontent genius or hacker working diligently with purpose and foresight to achieve a higher goal -- to save mankind from government, or, perhaps, from computers themselves. A second scenario might describe the efforts of a small army of programmers with a common ideal or a plot to extract billions of dollars from world governments.
However, a third scenario could describe a design or coding error, commonly made by all programmers, being written into virtually every program day-after-day, month-after-month, and year-after-year. This mistake remains undetected until triggered by some common computational event, and once it takes effect, it reduces or destroys the functionality of almost every computer in the world. Well, wake up world! This is not science fiction. Such a scenario is occurring today, and it cannot be stopped.
The Technical Nature of the Problem
The simple design error derives from the shorthand notation that most people use to write dates. In the United States, most people write dates in MM/DD/YY format. For example, October 20, 1997 would be written as 10/20/97. Throughout most of the world, dates are written in DD/MM/YY format. In this case, the same date would be written as 20/10/97. For sorting purposes, dates are often written in YY/MM/DD format or sometimes in YY/DDD format. This would result in the same date being written either as 97/10/20 or 97/293. Almost everyone in the world writes dates in this way. People rarely use formal date notation (e.g., October 20, 1997 or 20 October 1997). The problem arises from the two-digit year (e.g., '97 from 1997). Truncation of the century designation is a natural thing to do when writing dates since everyone knows in which century we are living. However, since we are rapidly approaching the twenty-first century, there will be some confusion as to what two-digit years beginning with zero will mean. Was a person whose birthday is written as 3/22/00 born on March 22, 1900 or March 22, 2000? A human would know by observing whether the subject is an infant or a very old person. However, how would a computer know? Well, most software running on computers today uses a two-digit date notation, and once computer operators enter dates of January 1, 2000 and beyond into the system, most computers will not know to which century they belong. In fact, on January 1, 2000, many computers will reset their internal clocks to indicate the current date as being January 1, 1900.
This problem is often referred to as the "millennium bug" or the "Y2K" problem. Today it is well known. But, how could it happen? How could software developers not realize that this would come back to haunt them? Well, in the 60's, 70's and 80's, the maxim in the data processing industry was that software has a useful life of five years. After that time, an application would become obsolete and require replacement. This was a reasonable expectation. By the late 60's, relational data bases had not yet been developed, and data was still being entered into computers using punched cards. During the late 70's, data was still being entered into computers without using full screen editing techniques. The graphical user interface (GUI) concept was not even introduced until the mid 80's. Software development techniques were changing rapidly. New languages were introduced on a regular basis. Many users went from using mainframe systems in the 60's to minicomputers in the 70's to micro computers in the 80's. Batched computing applications gave way to time shared systems that often gave way to local area networks. Suddenly the world of the personal computer was upon us. Computers truly became our servants, and it proved impossible to keep track of advances in computer technology.
In the 60's and 70's, disk space and computer memory were at a premium. Programming techniques had to be developed to save space. Use of a two-digit year instead of a four-digit year conserved an incredible amount of storage since so much of our data was date dependent. Even though storage and memory became cheaper in the 80's, date storage methodology continued as it had been done earlier. No one envisioned that the year 2000 would arrive with any of the software then being developed still in use. However, the widespread introduction of client-server technology into most companies in the late 80's and early 90's allowed companies to use many software applications for a longer period of time. As long as the front-end (software that the user sees) is modern, the back-end (software that the computer uses to store and manipulate data) need not be modern. Back-end software is generally the more expensive of the two. Why should companies make a major investment in new back-end software when the current software is still useable merely because it has been around for a long time. Therefore, some software developed in the 70's is still being used, and much software developed in the 80's is still around.
Many people assume that the millennium bug will occur only when and after the century rolls over. This is not true (7). Some computer systems are already feeling the effects of this problem. Whenever a date later than December 31, 1999 is entered into a computer application, the potential for disaster exists. Presently, some magazine publishers refuse to take five-year subscriptions (8). A company selling canned beef recently had one of its customers return all its shipments. The customer had already converted its computer inventory system in anticipation of the millennium bug, and the computer told the receiving clerk that the beef was already ninety-seven years old.
All software developers are now aware of this problem. Most new software is free of this bug. However, the fact that so many programs currently being used (legacy systems) have this problem makes the global computer disaster virtually inevitable.
Can The Millennium Bug Be Fixed?
Can this problem be fixed? With all our marvelous technology, is it possible to avert the disaster? The answer is YES! The obvious solution would be replacement of all legacy software with Year 2000 compliant software. Existing data would then be converted to the new format. This solution is analogous to surgically removing a malignant tumor. If the cancer is localized, the patient is cured. Many companies, especially small businesses, have chosen this route. However, replacement of all legacy software presents the following problems:
The other solution would be to repair the legacy software. There are three generally accepted methods of attack (9):
1. Conversion to full four-digit year format
2. Windowing techniques
3. A two-digit encoding/compression scheme.
Using the first method, the date format in all currently used programs having this problem would be changed to allow a full four-digit year. All previously entered data would then be automatically converted to the same format. The advantage of using this method is that once the software and data are fixed, such a repair would be permanent. The problem will not surface again until the year 10,000. The disadvantage is that so much program code has been written using the two-digit date format that it is almost impossible to find every instance where it appears. In the 70's and 80's, clever programmers used dates improperly to encode data that should not have been date dependent. In addition, certain dates were used as special values (e.g., 99, 365/99, or 12/31/99 to indicate no expiration date; or 00 to indicate an unknown year). Finding and repairing such code would be extremely difficult.
The second method would allow the data to continue to use the current two-digit year format. A time window would then be created to interpret the data. Windowing is a way of redefining the concept of a century to a computer. This allows programmers to get around the millennium bug by using the overlap of the new computer definition of "century" and the human definition of "century". The window would encompass a 100 year time frame, but the century would not necessarily begin in the year 1900 and end in the year 1999. For example, the current century could begin in the year 1925 and end in the year 2024. Therefore, a date of 3/22/40 would be interpreted as March 22, 1940 and a date of 10/20/10 would be interpreted as October 20, 2010. The window could have fixed end-points or it could have sliding endpoints (i.e., it could begin fifty years prior to the current date and end fifty years following the current date). The advantage of using this method would be that the software repairs would be relatively simple and existing data would not require modification. The disadvantage is that a software application might be required to interpret dates spanning more than a century. We already have a reasonable number of individuals who have passed their hundredth birthday.
The third method would allow the date field in the data to continue to use the same storage as the current date field, but the data would be modified to encode the date in such a way that the century would be apparent. One example of how this could be done would be to convert the two-digit year to a base higher than decimal. For instance, encoding the year in hexadecimal (a notation commonly found in computers) would allow the two-digits to span 256 years instead of 100 years. This would mean that two-digit dates would be valid from the year 1900 until the year 2155. The advantage of this method would accrue primarily to software written in older languages such as COBOL or RPG. Here, data was originally entered on 80-column punched cards, and retaining the two-digit date format is necessary. The disadvantages of this method would be that the program code and data would require extensive modification, and the date encoding scheme would be obscure and without industry standards.
Industry Response -- The Size of the Problem
The data processing industry is already working feverishly to avert the Y2K disaster. Billions of dollars have already been spent. The demand for programmers currently far exceeds the supply. In many American companies, junior programmers with a knowledge of COBOL can be assured of a six-figure starting salary. The Gartner Group has stated that the total cost necessary to fix the problem is between $300-billion and $600-billion (10). It is estimated that, by the time all the money has been spent, the total global Year 2000 expense (including litigation) will be $1,510,000,000,000 (11). It is also estimated (with a probability of 70%) that 50% of the companies with this software problem will not have adequately addressed it in time and will begin having their computer systems shut down or producing incorrect data by the turn of the century (12). Yet, 65% of corporate executives are either unaware of the problem or do not believe that it will wreak the predicted havoc. Most of them believe that we can solve the problem in time. More than 65% of North American businesses have not yet begun to address the problem (13). Well, for most businesses, if they have not yet started their Y2K project, they are already too late (14). For all but the smallest companies, June 1997 was the latest point in time that there was a reasonable opportunity to find and repair all millennium bug problems prior to the year 2000 (15). Furthermore, many systems will begin to fail earlier, some as early as January 1999. Even those companies that have the year 2000 problem under control will have severe problems if their suppliers and partners do not (16). Most companies have data processing dependencies upon suppliers, customers, financial service providers, insurance carriers, government agencies, telecommunications networks, and even competitors. Failures could occur in heating and ventilation systems, security systems, or PBX systems.
Many companies, when they discover that the problem cannot be solved in time, will perform a triage. They will prioritize the problems that need solving, and they will tackle the most important ones prior to the turn of the century and the less important ones later. For some companies, this will prove adequate. For most, it will not.
Millennium bug expenses will continue beyond the year 2000 -- some estimates run as late as the year 2005 (17). These expenses will consist of (18):
Many corporate executives and government officials have made the following statements:
Well, the millennium bug is not a fraud. When he testified before the Science Committee of the U.S. House of Representatives on May 14, 1996, Peter de Jager said (21):
The year 2000 problem is unique. Four elements of uniqueness are:
1. the deadline cannot be missed;
2. it is an immovable deadline;
3. it bears no relationship to the size of the task;
4. we share the same deadline.
The Year 2000 problem is a ticking time bomb. The Federal Financial Institutions Examination Council, a vehicle used by the Federal Reserve System, the Comptroller of the Currency, the Federal Deposit Insurance Corporation, the Office of Thrift Supervision and the National Credit Union Administration, has stated that there are substantial risks to many financial institutions who have not adequately addressed this problem (22). While it is true that most people will wake up, brush their teeth and have breakfast every morning after January 1, 2000, they may not have a place of employment. Many small businesses will be able to survive if they are not too dependent on sophisticated software. Many large companies will be able to weather the storm because they have sufficient capital to stay in the game. However, many in the middle will not be able to continue essential operations or will not be able to survive the onslaught of inevitable litigation, and they will go under. Many local, state and federal agencies have either not addressed the millennium bug at all, have not even begun to take inventory of their legacy software, have not performed any risk analysis, or have not been allocated adequate funds to deal with the problem (23). And people will die. One manufacturer recently recalled a shipment of heart defibrillators after learning the devices could not handle the century change. The defibrillators had a clock that calculated the time since the last maintenance check. Once the date passes, the device will not work (24). There are severe problems with the software used by air traffic control, rail systems, life support control and navigation systems. The wrong date could compute the wrong medication dose for a patient (25). WE DO NOT HAVE PLENTY OF TIME TO MAKE THINGS RIGHT, AND, UNFORTUNATELY, THE SKY IS REALLY FALLING.
By now, you should be convinced of the magnitude of the problem from a technical and business viewpoint. But, what are the legal implications of the millennium bug? Clearly, given its scope and impact that the millennium date change may bring, a large number of businesses and individuals will likely suffer large damages, both financial and technical, at the hands of this problem. Whenever such damages occur, litigation is usually not far behind. In fact, litigation costs associated with this problem are projected to potentially far outpace the costs to correct the problem (26). Potential defendants include:
Capers Jones indicates that potential types of litigation include (27):
Potential causes of action or defense could be:
Most hardware and software purchases/licenses are covered by Article 2 of the UCC as a transaction in "goods". Under Article 2, certain warranties, unless specifically disclaimed by the parties to a contract, are implied. These implied warranties are the warranties of merchantability and fitness for a particular purpose. In brief these implied warranties provide that the "goods" will be suitable for their ordinary purpose and that they will be suitable for the particular purpose that the buyer may so express to the seller. Therefore, it is conceivable that an argument may be made that as a result of the millennium bug, the computer system does not work in a reliable, trouble-free manner. Also, if the buyer expressed an intention of using the system after the date change period, then the seller is on notice of the buyer's particular purpose of having the system function after the Year 2000, and thus, there may be a breach of an implied warranty under the UCC (28). However, problems of recovery will probably exist with this type of performance litigation (29). Section 2-725 of the UCC provides for a statute of limitations of up to four years. Contractually, the parties may reduce this to not less than one year. This seems to indicate that a buyer would not be able to file an action related to Year 2000 performance problems for hardware and software purchased prior to 1996. Depending upon the written agreement between the parties, this statute may affect purchases made prior to the Year 1998 or 1999. However, should the seller make an express warranty of future performance, the statute of limitations, with a duration of one to four years, will most likely not begin to run until the breach occurs. It remains to be seen how this rule will affect the implied warranties of merchantability and fitness for a particular purpose.
There may also be other breach of contract issues that arise as a result of covenants made in a particular contract. Legal precedent has held that even the purchase of custom software is covered under Article 2 of the UCC. However, where a vendor performs services that are under complete control of the buyer, such acquisition would give rise to contract issues. In most states, the statute of limitations for actions brought for breach of contract is six years.
An interesting defense that vendors may attempt to use involves a vendor's documentation of a known or potential millennium problem and the buyer's real or constructive awareness of the same. In some cases, vendors have actually provided information on the Year 2000 problem and as it relates to their systems in trade articles, specifications, and other documentation to which the buyer could have access. The question may arise as to whether this prior notice is enough for a buyer to be considered aware of the defect or potential defect and have chosen to waive any right to have such problem corrected or to reject the computer system at the time of delivery or discovery of the potential millennium problem. These vendors may also rely on the fact that competitors and other companies aware of this problem with their systems took no action and no reasonable precaution, and did not advise customers of the potential problems (29). While this may be a creative defense on the part of vendors, it will likely be one that arises in litigious situations.
Currently, companies are engaging large numbers of consultants to make their code Year 2000 compliant. While this business is extremely lucrative because of the necessity of companies to take Year 2000 corrective action, these consultants may be the parties taking the greatest risk. In the event that a consultant allegedly corrects and tests code that is subject to the Year 2000 problem only to have such code malfunction as a result of a date data problem, such companies, unless their liability was limited by the contract, will be subject to claims of breach of warranty/contract as mentioned above. In addition, a copyright infringement action could stem from unauthorized modification of the code to make it 2000 compliant (30). Further, if while correcting each line of code for the particular client, a consultant inadvertently changes, deletes or adds to the code and causes the system to malfunction, then a negligence action may be brought against the consultant if the damages to the company are other than solely economic. Finally, what if a consultant that is hired to fix the millennium bug finds other errors in the code? Is the consultant obligated to fix such errors? Is the consultant obligated to notify the client of this non-Year 2000 issue or at least document the problem (31)? These individuals and companies will very likely be in the middle of any litigation between the original software vendor and the customer.
In a transaction covered under Article 2 of the UCC where computer hardware or software is purchased, there is considerable precedent holding that the negligence tort cannot be claimed in performance litigation where the losses are solely economic. This does not hold true in cases of personal injury. This also does not hold true in matters covered strictly by contract between the parties. However, the negligence tort might be utilized in actions against corporate officers who fail to act in a reasonable and prudent manner to avert economic disaster to a company arising from the millennium bug. The Year 2000 problem has been so widely publicized and information disseminated so frequently, that corporate officers and officials will likely have little luck in claiming that in their capacity as an officer/official, they were unaware of the potential problem or did not have time nor resources to take the necessary action to address and correct the problem with their company's computer systems.
There is also considerable precedent holding that computer professionals cannot be held to the high standards that would permit tort actions to be taken against them claiming professional malpractice. However, attorneys, who do not exercise sufficient care in the drafting of agreements so as to take the millennium bug into account, and accountants, who do not adequately account for future millennium bug economic consequences in their audits, can be held liable using this standard. As mentioned above, officers and directors acquiring other companies between now and the Year 2000 should be aware of the millennium bug and must ask the right questions, ensure that certain steps are taken prior to the acquisition and document their requirements or they could be held negligent. Of course, if the company being purchased does not disclose its Year 2000 efforts or lack thereof or fraudulently misrepresents such status then action against that company may be available. What is definite is that a careful due diligence is required.
Where a complaint of breach of warranty cannot be effectively pursued, a complaint of breach of maintenance agreement might prevail. Most expensive hardware and software is sold either bundled with maintenance agreements or such agreements are sold separately. Under a maintenance agreement, the vendor usually promises to maintain the system to an acceptable level of functionality or to maintain the software in "good working order". Unless problems with the millennium bug are specifically disclaimed within the contracts, vendors may be required to fix such problems within a reasonable period of time or within the time frame specified in the agreement, and this responsibility would continue past the Year 2000. As was previously discussed, such a reasonable period of time could be deemed to be as short as twenty-four hours. Under these circumstances, the vendor could be liable if it proves unable to restore functionality within this time frame.
So, with all of this liability in mind, now picture this scenario. January 2, 2000 has arrived. You and your client are confident that both have done all that is necessary to become Year 2000 compliant. The millennium bug can no longer have an effect on company operations. You now have nothing to fear -- right??? Well, imagine that your client is dependent upon receiving data from an outside source transmitted either via telecommunications or a disk, tape or CD sent through the mail. Further imagine that this outside source is either non-compliant for Year 2000 or has implemented a solution to the millennium bug that is incompatible with your client's solution. For example, one company converted to a full four-digit year format, and the other converted to a two-digit year/sliding window format. The manner in which either company handles the residual two-digit years may be incompatible with the other's method. The result -- re-infection (32)!!! Most of the money already spent to insure Year 2000 compliance could be wasted. Under these circumstances, whom does the aggrieved party sue?
A number of insurance companies are beginning to offer coverage for millennium bug problems. Currently, the premium costs are so high that they equate to a company actually suing itself. Apparently, no "first party" insurance will cover the costs of the Year 2000 problem (33). The "third party" coverage issues can be divided into several categories:
Existing policyholders may find restrictive endorsements proposed at renewal (34).
Fiduciary duty is the highest standard of duty implied by law. Where a trustee or guardian acting in a fiduciary capacity causes harm to persons or corporations in whose behalf he acts, there is liability. However, the fiduciary shield doctrine protects corporate officials from liability even for tortious conduct provided that they acted in behalf of the corporation and not for personal gain (35).
It is also anticipated that the force majeure defense will be used in many actions brought by aggrieved parties. The vendor or corporate officer will say that this is a hidden defect that could not have possibly been anticipated (36). Such a defense might have been possible in the early part of this decade. Damages from the millennium bug as it affects legacy software could not have been reasonably anticipated at the time of creation or purchase. It is only with hindsight that we here and now understand the magnitude of the problem. However, the existence of this problem has been well publicized over the last few years (37). There certainly has been sufficient time to address the problem. The fact that many corporate executives chose to ignore the problem or not to understand its severity is no excuse. It is not expected that the force majeure defense will be able to protect the defendants (38).
A business decision not to disclose information regarding the millennium bug, which is known to the vendor, could give rise to fraud claims by customers (39). The statute of limitations for fraud claims also exceeds that for breach of warranty claims, therefore the time frame for a plaintiff to assert the claim is longer than the time frame mentioned above for a breach of warranty/contract claim. Therefore, vendors could have potential liability beyond the warranty period (40). Some vendors may attempt to limit their liability to prior customers by advising them how to obtain Year 2000 functionality. The risk is that some customers, especially those who are otherwise dissatisfied, may use this notification to initiate legal action against the vendor, prior to the expiration of their individual statute of limitations for breach of warranty, breach of contract or fraud (41). However, a claim of fraud will not prevail unless a customer can prove that the vendor did not intend to perform before they signed the contract (42).
Finally, litigation involving employment issues may result from the millennium bug. Most Year 2000 projects will be labor intensive and must be accomplished within a finite period of time. Companies will be required to staff up and then staff down within a relatively short period of time. Any company that has experienced significant short term fluctuations in work force knows the inevitable result: labor and employment claims (43).
Capers Jones published a study estimating the litigation potential for failure to repair the 2000 problem (44):
The types of claims brought as a result of the millennium problem and the magnitude of damages sought by and awarded to plaintiffs will likely be astronomical. The creativity of the actions and defenses will be very interesting to watch. What is clear relating to the Year 2000 issue is that individuals, consultants, companies and corporate officials must prepare for the worst and hope for the best.
The Role of Technical Experts in Year 2000 Litigation
As with all computer litigation, the technical issues are so complex as to elude the understanding of most judges and juries. Most attorneys have the same problem. Some arbitrators can be chosen so as to have an adequate technical understanding. However, the solution is simple. In order to prevail in litigation, use of a forensic expert will be required.
The technical discovery is different depending upon whether the client is a plaintiff or defendant. Simply stated, most plaintiffs will claim that the defendant either knew or should have known that the millennium bug would cause damage. When representing a plaintiff, the expert will seek to discover the following:
When representing a defendant, the expert will seek to discover:
These are general areas of discovery by experts whether the matter is a performance dispute, a shareholder dispute or a personal injury dispute. Although the emphasis of the expert's investigation is slightly different based upon whether the client is the plaintiff or defendant, the questions asked are basically the same. In fact, a careful expert will seek to answer all of the above questions whichever side is represented.
As in most computer based lawsuits, a forensic expert should be retained as early as possible. The best time would be when litigation is contemplated. Prior to filing, the expert's services should be used in selecting and securing evidence and in preparing the technical basis for the lawsuit. Most of an expert's services are performed prior to trial. In most Year 2000 cases, the expert will need to conduct interviews and to examine source code. This can be very expensive. Therefore, specific goals must be set for the expert, and time estimates must be obtained. A forensic expert will also assist with discovery requests and interrogatories.
Summary and Conclusions
The Year 2000 Problem is the most significant event ever to affect the computer industry. Since computers are used for most global transactions, the impact of the millennium bug is enormous. In some manner, this problem will affect virtually every person in every industrialized country in the world. National and global economies will suffer from the Y2K effect. Many businesses will cease operations within a short time following the turn of the century due to faulty computer performance. Others will cease operations later to avoid the inevitable consequences of litigation. For others, the costs of survival will be well beyond expectation.
The Year 2000 Problem has a solution. Unfortunately, it is too late for most companies and government agencies to implement the solution. Furthermore, most corporate executives and government officials either do not believe that a severe problem exists or are unwilling to make the commitment to solve it. The Year 2000 Disaster is coming and while some are taking steps to prepare for it, the results are inevitable.
Year 2000 related litigation is also inevitable. The end result will likely be that by adding together the cost of fixing the problem and the cost of subsequent litigation, so much money will be drained from the economy that everyone will suffer. True, companies must do whatever is necessary to survive. Attorneys must also protect their clients' interests. As you can see, the collision course is set.
Hopefully, in the future, those who create our mechanical and electronic servants will look beyond short term goals. Maybe, the Year 2000 Disaster will serve as a wake-up call to those who design and sell for profit. To quote an old adage: "Those who will not learn from history are doomed to repeat it."