Law Technology Product News Law Journal EXTRA!
Law Technology Product News
December 1996

The 'Year 2000' Problem Is Today's Headache

Law Technology Product News (p. 117, col. 1)
December 1996

Even those who admit there is a problem wrongly assume that we have until Jan. 1, 2000, to correct the problem.

By Larry Freedman

Lawyers are no strangers to the art of denial. For decades we denied, to the point of extinction for some, the fact that the practice of the law is a business. Today, thoughts of a gentlemanly profession, in which thou shall not covet thy neighbor's clients, are nothing more than a distant memory for some and folklore to others.

More recently, we had been focusing our denial on the role and importance of technology in and to our practices. Now, not only is it commonplace to find a personal computer on every lawyer's desk (even if senior partners tend to use theirs only as plant stands and occasionally to retrieve and send e-mails), but some of us also have so embraced technology that we have found we can maintain peak levels of productivity (i.e., 2,000 or more billable hours) without the benefit of an administrative assistant.

Unfortunately, by embracing technology and elevating its role to essential within our practices, we find ourselves, like all other enterprises using computers and operating on a network basis, facing the problem commonly known as the Year 2000. Yet, true to form, even while the sharks among us salivate at the prospect of the suits to be filed against those enterprises that fail to address the Year 2000 problem, the overwhelming majority of us (including, believe it or not, some of the sharks) are, once again, in denial.

We have yet to admit that we ourselves need to address the Year 2000 problem within the systems that have become so critical to our everyday practices. Moreover, even those among us who admit there is a problem, are those who wrongly assume they have until Jan. 1, 2000, to correct their technology.

The real deadline for solving this problem can be much sooner. It is whatever date the computer application fails. This is known as a "time horizon failure."

Simply stated, the Year 2000 problem is the result of software applications that were written to process years as only two digits. Typically, this means that an implicit "19" is placed in front of a two digit year value. This is not a problem when dealing exclusively within the 1900's (e.g. "54" for 1954.) However, this implicit "19" leads to ruinous results when we arrive, or attempt calculations, at 2000 and beyond. "Noncompliant" systems typically will interpret "00" as "1900" (remember the implicit "19") even if the year is actually meant to be 2000 and will miscalculate accordingly. Other systems will interpret "00" as invalid, expired or as having erroneous meanings by customers or systems end users.

Whenever a calculation crosses the century boundary errors can be expected to occur, which may be in the form of (1) an inaccurate date trigger, which may cause an event to occur that should not have, (2) an inaccurate date computation, resulting in the difference between two dates being calculated incorrectly; for example someone born in 1960 will have his age calculated as --40 in the year 2000 (00 minus 60 - remember that implicit "19"), or (3) perceptional error, whereby someone misinterprets a display involving a date.

Errors can be progressive. Calculations done this century looking forward across the boundary--resulting in time horizon failure in advance of Jan. 1, 2000. Or they can be regressive, looking back into this century when the next century arrives. To date, obviously, only progressive examples have been experienced. However, date trigger, date computation and perceptional errors have all already occurred.

So now, perhaps, we can admit that there is a problem, and understand it--sort of. Yet, as lawyers, we will not be satisfied to simply identify a problem, understand it and move to solve it. We first will want to know how and why it happened. In other words, there's got to be someone to blame.

The sad truth is that the technique of representing a date in a computer program by using only two digits can be traced back to the 1960s, when it was used as a convenient way to reduce computer memory storage requirements. Translation: Computer memory was, at the time, a very costly commodity and employing this technique meant saving big money.

Ther sad truth is that most enterprises that implemented this technique assumed the programs would not survive until the millennium. In hindsight, we, of course, would be inclined to remind everyone involved what happens when one assumes.

Most of us hearing about a problem such as this are, frankly, not impressed and, most certainly, not moved to action, especially when that action is spending money--lots of money. Even though we are familiar with a concept that is central to the Year 2000 problem --i.e., "There will be no continuances counselor;" this deadline cannot be extended--the problem itself is just too technical and seemingly too hypothetical. Perhaps if we attach some numbers, add some objective data, we will become more convinced.

Industry analysts estimate that the cost, worldwide, of fixing the Year 2000 problem will be approximately $500 billion. This figure can be broken down to $.50 to $4.00 per line of code and one programmer per year per 1,000 lines of code that must be fixed.

An organization testing 100 million lines of code is likely to find that within that code more than two million date routines exist, of which 90 percent probably will not be Year 2000 compliant. The cost to fix the Year 2000 problem for such an organization will be staggering.

The choice for the average Fortune 500 company is to pay now (approximately $25 million) to fix the problem or pay later (estimated litigation costs of $100 million) for ignoring the problem.

The bottom line: We must each quantify our risk, take an inventory, assess software risk, and develop a project plan that will identify resources to fix applications as needed, or find other ways prevent failures, such as technology replacement or retirement.

In light of the magnitude of the risks associated with denying that your organization has a Year 2000 problem and the expense involved in solutions, it is obvious that this is an issue that must be brought to the attention of and addressed by senior partners, name partners, management committees or other governing bodies or individuals within your organization.

How to Get Their Attention?

Step One: Gather data. Now that the presidential election is weeks behind us, the Year 2000 problem probably will be among the most written about topic in the media. Every issue of each and every computer industry publication has at least one article on the topic and publications from the Wall Street Journal to The National Law Journal have printed (and likely will continue to print) multiple articles on the topic. There is even a website at dedicated to the issue.

Step Two: Present real-life problems within the firm's system. Whether it be calculations of payment streams for promissory notes or settlements, processing accounts receivables and payables, or automated litigation dockets, spend time with your firm's information systems person to test your system. Undoubtedly, you will find a system failure or failures, which, if not corrected, will expose you to liability.

Step Three: Find an industry professional to be the bearer of bad tidings. It may be worthwhile to enlist the assistance of an industry consultant, they are plentiful, to deliver the message from an expert's point of view to the powers that be within your firm. Enlisting a messenger may have an additional benefit. Every now and then it is the messenger who gets shot and better him than you.

We all know that there is no good in presenting a problem without also offering a possible solution. Vendors of, and commentators on, the Year 2000 solution have action plans that vary greatly in the number of steps necessary to solve the problem (some have even proposed "12 step" programs). But all these action plans are built on four core concepts. You, however, should add a fifth for good measure.

  1. Plan It: Work with an industry professional to develop a revision plan, including a budget.

  2. Find It: Locate all date occurrences

  3. Fix It: Minimize source code changes

  4. Test It: Ensure application reliability now

  5. Leverage the Investment for Competitive Advantage: Review applications and data; enter data about mission-critical applications into a repository to allow for future, easy management, maintenance and access to vast amounts of firm data, applications and systems.

It is hoped that after the arrival of the millennium and the associated flurry of lawsuits against organizations who denied the existence of a Year 2000 problem, those of us who have championed the cause within our firms to purge this plauge from our systems will be recognized as heroes.

Of course, at that time, we best not rest on our laurels because a system can become reinfected through bad dates and bad data passed by an inter- or intra- business partner through an interface into our previously cured system. So, one final word of caution: Be sure that the solution your firm chooses includes interface compliance.

Larry Freedman is vice president and associate general counsel of Platinium Technology Inc. in Oakbrook Terrace, Ill.

Home | News | Law Firms | Marketplace| Publisher's Catalog | Practice Areas | What's New?

Copyright 1996, The New York Law Publishing Company. All Rights Reserved.
Access to Law Journal EXTRA! is governed by its Rules of Use. Send comments to