From Dan Mincavage: "As a computer programmer in the early sixties, plugging up the "year" fields with ’99’ to designate ‘End of File’ and ’98’ to designate special processing for a transaction was common practice with an 80 column punchcard. [Note to young readers: punch cards were actual, physical cards, about three inches by seven inches, with actual little holes punched in them. An operator fed them into the computer, and it ‘read’ them and executed the programs. — A.T.] After all, that problem was over 30 years away, and we had a deadline to finish the programs within that year. We certainly weren’t too concerned with a problem at the end of the century (y2k). I’m aware how well the banks, insurance, and brokerage legacy programs are running since that time; however, starting next month (1998), a few ripples may appear under the surface. [Note: a legacy program is one that dates way back to when your dad went to college, like 1966.]
"Eventually I gained a little respectability in the computers and communications fields. I became a computer Systems Manager and Auditor with a Big Six accounting firm. I’ve had a firsthand look at the conditions of the systems and program documentation of many, many of these fine institutions around the world.
"Because of time-saving patches to machine language programs by computer vendors and in-house programmers, many of the programs’ documentation doesn’t match the program running on the computer. [Note: This is not a good thing. "Documentation" is the English explanation that’s meant to explain what each line and section of computer code is for, and why it was done the way it was, so someone years later could sort of "read through" the program and make sense of it. Imagine being called in to fix a wildly tangled system of phone wires and having an inaccurate diagram to work from.] In addition, many upgrades and much obsolescence have occurred within the program assembly languages, compilers, and operating systems over the years. Substandard documentation was commonplace, and the attitude oftentimes was that if the big major system was running and we don’t have a problem now, why fix the tie-in to documentation if it ‘ain’t broke.’ Automated systems have been working somewhat to fix the y2k [Year 2000] problem with about 30% success. Testing, integrating, interfacing systems enterprise-wide and also with outside vendors cannot be automated. This will take much longer than fixing the y2k computer program glitch.
"I love your attitude that the problem will get fixed since people are aware they have one. But I’m not as sure as you that the problem is really understood. And then when financial institutions start having problems with their records and the public realizes that problems are occurring, the ‘run on the banks’ and the impact on stocks will be heard around the world. I really hope that you’re right, and I’m just another fuddy duddy."
Sorry I didn’t "print" that response when it first arrived — it got lost in the shuffle. It is kind of astounding to think that something as simple and basically silly as this problem could have such devastating implications. It reminds us what a fragile and interconnected world we live in, and how dependent most of us are on things we can’t control — or even understand. How long would most of us last without electricity?
I heard some other smarter-than-me people discussing the Year 2000 problem at a gathering over New Year’s. One said an insurer on whose board he sits had budgeted $4 million to solve this problem when he first asked about it, then $40 million when next he asked about it, and now — well, it could be vastly more. Another member of the group said he thought U.S. financial institutions had this pretty well in hand, but that when he asked folks in Europe about it, they just stared at him blankly. This scared him, as all the world’s financial institutions are more or less interconnected. A third said that, well, the European and especially the Asian institutions may actually be at much less risk, because they came to computing more recently, and tend to be working from more modern systems not rooted in 1960s technology. A fourth said that the huge shift to software maker SAP’s installations, greatly pumping up the revenue and success of that German firm, was largely fueled by the Year 2000 problem. Many companies have realized it’s actually cheaper to install entirely new, albeit highly complex, SAP systems than to try to fix the systems they’ve got. So for less money they (a) solve Year 2000 and (b) get a much better, brand new system. Only problem: it takes at least two years to switch from the old to the new . . . and two years from today, if you were just starting, would be — oops!
So Dan is right. I probably underestimated the potential problems here. And I certainly hadn’t realized that ’98 and ’99 were used by some early programmers in creative ways, too. So the Year 2000 problem may actually begin showing up in odd ways even before the Year 2000.
Will this be the end of the world? In my experience, the world doesn’t usually end. But could there be enough glitches, contained panics, and general wariness to slow world growth? Yes, I suppose there could.
Yet another reason to look askance when someone tells you he expects 20% annual growth in the stock market, and sloughs off bear markets as either a phenomenon of the past or else something easily ridden out, akin to a squall.