Still More Y2K – Is It Real?

I promise to get back to some jokes, but Y2K is sufficiently important I thought we should give it one more day before moving on (temporarily).

Have you begun making harmless contingency plans and laying in an emergency supply of essentials you probably won’t need — but just in case you do? Now, when it’s easy, is the time to do it.

From Brian Schiel: “I’m working as a contractor on a Y2K project at the University of Michigan. This is my second Y2K project, and you can count me among those in the Y2K alarmist camp. You’ll find an excellent paper about the embedded systems Y2K problem at www.tmn.com/~frautsch/y2k2.html. It explains, better than anything else I’ve read, why embedded systems are going to cause more and more problems as we approach the Year 2000.”

From Craig Hagstrom: “All programmers agree the Y2k problem is simple. I recently worked for a company that went broke waiting for companies to flood in to us, bearing code to fix, but they never came because fixing the code is too easy to need outsourcing. It’s not the fix, but the testing that kills you.

“It’s grimly funny to hear a computer science major tell you how simple it is to fix, when their system consists of perhaps 4 programs running against a database of 200 test records spread over half a dozen tables and using 3 record definitions. That’s the kind of sample database you get when you buy Microsoft Access, or similar PC databases tool. They can patch their 4 programs, write and run a quick program to expand a field in their database, and they’re ready to go again. And they can shut down their little application any time they want to, to do such a restructuring.

“The problem gets big when you have 500M records spread over 200 tables using 150 record definitions, all on a system that cannot be out of action for more than 30 seconds at a time. The FAA … law enforcement … the phone company. Scaling up from the preceding paragraph, such a system might take (say) 5 weeks of pure run time to restructure the database and load new versions of the programs. But if the system has to keep running at the same time, then you’re looking at perhaps 6 months just to PLAN the changes, another 4-6 months to plan how to test the thing, and two or more years to implement. The problem is exponential, which is why the IRS has tried 3 or 4 times to rewrite its systems and failed every time. It’s too darn big.

“We are about to hit panic mode in the world of commerce. As the first big failures hit unprepared companies, the rest will get religion real fast. (Go read Cory Hamasaki’s description of the Jo Anne effect at www.kiyoinc.com/current.html) Since there isn’t enough time left, you’re going to see hurried fixes that are not tested at all. You are going to see an amazing amount of fear in the next year, with managers grasping at any possible escape. The major disruptions from year to 1/1/2000 will come from (1) Y2k errors involving forward-looking date calculations, and (2) simple programming errors from rushed and untested Y2k ‘fixes.’”

From Jerry Holsinger: “While you claim that there are intelligent and knowledgeable people on both sides of the Y2K problem, the only ones that I know of on the ‘it’s all hype side’ sound pretty naive when you read what they write.

“For what it’s worth, I have a Ph.D. in E.E. from MIT and have been involved with hardware and software development for over thirty years, though I am not a programmer. I have software that I developed to manage my own investments which has severe Y2K problems. As a result I have enough background to understand why Y2K has the potential to be a severe worldwide problem, which I believe it will be. I also know from first hand experience how hard it is to get non-technical people to understand and believe that Y2K is a serious and real problem.

“Please do not spoil your outstanding effort on the Y2K problem by publishing further information that only makes the work of people who are serious about the problem that much harder.”

From Ken Shirriff: “Interestingly enough, my bank’s online access is not Y2K compliant. Their web code is written in JavaScript and can’t be more than a year old, but they didn’t deal with Y2K. The web page asks for the date as 6 characters MMDDYY and rejects any request that has YY < 70. The code has the comment: ‘check that year is not before 1970.’ Obviously this will break in 2000 if they don’t change the code by then. (The bank, by the way, ignored the email I sent them about this.) The two points of this example are: a) It’s easy to write non-compliant code in any language, not just Cobol. b) People are still writing non-compliant code for applications such as banking, even with all the attention on the Y2K problem lately.”