Software Quality Journal, 10, 281–283, 2002© 2003 Kluwer Academic Publishers, Manufactured in The Netherlands.

Editorial: The Y2K Legacy—The Time Bombof Tomorrow

I feel that the Y2K problem is in part responsible for the recession in the computingindustry. Rather than the steady, worldwide annual spend on new software, hard-ware and systems enhancements, many organizations, due to the Y2K bug, broughtforward their plans for computer spending by one, two, or three years. These pur-chases were made for installation by 1999, rather than fix the old systems.Also, organizations decided that while making a Y2K fix, they would make minor

modifications at the same time, which had been originally scheduled for the nextfew years.If this analysis is correct, within two years there will again be a heavy demand for

computing expertise; but it could take several cycles of four or five years’ duration,to remove the peaks and troughs for demand for computer equipment, systems andservices.But what of the other more serious aspects of the Y2K Legacy—the “buried Y2K

bugs”? Due to pressures to make the systems Y2K compatible, decisions were madein many highly respected organizations to use “windowing techniques,” which, asyou know, involves in effect, putting the clock back within the system, then addingthe appropriate number of years to any output.Some organizations, I feel made better judgments for the choice of the number of

years, taking twenty-five or fifty years (possibly as nice round numbers?), whereasI consider those that used twenty-eight or multiples of it, simplified the day and theleap year issues. In itself windowing is safe, effective and efficient, particularly as ameans of “buying time,” when you have an immovable deadline, such as Y2K; andmore permanent solutions can be undertaken at leisure after 2000.An alternative option that has been used, is to utilize a fixed window, whereby

if the last two digits of the year is above a fixed number, it is assumed to be inthe 20th Century, otherwise it is taken by the system to be in the 21st Century.These options have been widely considered, prior to Y2K, in publications such asthe British Computer Society’s Year 2000 Series of Practical Guides (Volume 1, ISBN0901865974; Volume 2, ISBN 0901865982).This is where the danger lies—have these delayed permanent changes been under-

taken? What is the quality of the documentation about windowing on these sys-tems? Ideally the documentation should have been very thorough. But what aboutchanges to the system in the future, over say the next twenty-five, twenty-eight, orfifty years, in that section of the system that has not been replaced? Will docu-mentation, for possibly an ever-ageing system, be kept up-to-date? Today, and sayfor the next five years, the effects of possibly missed Y2K problems should be inthe minds of computer professionals. But what of the computer of professionals

282 ROSS

of five or ten years hence? During a discussion on quality with final-year degreecomputing students, I was rather shocked to have to remind a few of them aboutthe implications of Y2K. Their view was that the Y2K bug was a computer problemin the past, and so it was felt to be irrelevant, now and in the future.Unfortunately, it is easy to see various, hopefully unlikely, but possible, scenarios

where the Y2K legacy has been forgotten or hidden intentionally. On purchasinga company, a due diligence search should be undertaken on behalf of the pur-chaser, that should uncover any risks. This could include a system that might stillbe using windowing techniques. This system might not currently have any problem,and should be perfectly safe for now.If there was no prior knowledge about the use of windowing techniques within

a purchased company’s system, extra-unexpected cost and time can be spent inamalgamating systems. This could involve replacing some, or all, of the old system,which again would be an unexpected high expense to be met eventually by thepurchaser.Another modification of that scenario, are the unexpected problems that surface

later, in a few years, one hopes during the testing phase, when the old code thatinvolves windowing, is modified or combined with another system. The computerprofessionals of tomorrow might have inherited poor or missing documentationabout the legacy system. Considerable unexpected time, and hence expense, couldbe wasted in identifying and fixing the problem.Returning again to the issue of a due diligence search, prior to the purchase of

a company. Identifying the use of windowing techniques can be difficult, certainlyin the UK, as there is no specific requirement to declare in the Company Accountsor in the Quality Audit (under ISO 9000 or TickIT), that windowing techniquesare still in use in certain systems. Despite future time and cost implications to anorganization, if windowing techniques are still in use, it could be viewed in onesense, as a future risk, but on the other hand, at this moment in time, there mightbe no risk in using this technique (unless of course a change is required!).It would seem to be an ideal solution if all auditors were required to ask whether

windowing techniques were in use in any of the computer systems. If the answerwas yes, the answer should be recorded on their report—not as major, or even asa minor, nonconformance, but as an aid to future purchasers, and as a reminder tothe organization’s senior management, that the legacy from the Y2K bug is alive,but currently, dormant in their organization.There are other key years ahead, depending on the systems used, but not with the

potential risks of 1st January 2000.To end on a more positive aspect of the Y2K Legacy, at least for organizations

with a commitment to quality, considerable effort was undertaken to create anup-to-date Asset Register of all hardware and software in preparation for Y2K.The organizations which have kept these up-to-date, especially those in Europe,will find the adherence to the various European legislation regarding recycling ofelectrical and electronic equipment, should be considerably easier, both from theviewpoint of the organization, and from future auditors/investigators that wouldpolice this legislation.

EDITORIAL 283

Another positive benefit from the preparation for Y2K, was a revaluation oforganizations’ contingency plans. Again I hope that these plans have been keptup-to-date, and also regularly tested, which, in days of uncertainty, brings a degreeof confidence for the future functioning of organizations, and can be used, viewedas an added positive legacy from Y2K.

Margaret RossProfessor of Software Quality