I just noticed that they are reporting another computer snafu. This time on NASDAQ. With the 56 minute shutdown on the NYSE on monday or tuesday (forget which) and another today, it's tough to chalk it up to coincidence. My guess is that Y2k remediated code has some bugs that were produced when the programmers were adjusting the date fields or using other types of fixes. If we're seeing this level of bugs in October '98, shouldn't January '99 be worse than even the pessimists have forcast?

-- Roger Altman (rogaltman@aol.com), October 29, 1998

Answers

Roger, If you are correct about the failures being related to Y2k remediation efforts then you have drawn the wrong conclusion from that premise. If they are experiencing failures in production systems in 1998 due to Y2k repairs that means they are already putting repaired code back into production. Repaired code back into production in 1998 would obviously be good news. Jack, I'll save you a few key strokes... Jacks reply is "no securities firm can claim Y2k compliance,Yah dah Yah dah...........

-- Woe Is Me (wim@doom.net), October 29, 1998.

Woe is Me: ha ha, that's funny. The fact that they are having Y2K remediaton-related failures (if that is the case) is a GOOD thing? Your assumption that this is because they are putting FIXED code back into production is ludicrous. Obviously it's not fixed or it wouldn't cause such failures. Your logic is confounding. If you mean that it's good because this means they are taking the process to the next level (testing) you are still wrong. All it would mean is that they tried something that didn't work. That might have been a good start back in '94, but now... sheesh. Scott

-- Scott Johnson (scojo@yahoo.com), October 29, 1998.

Well Woe is Me is right on this one. If they're putting remediated code into production now, it means they have 13 months to work out the bugs. The sooner they do this the better. Get ready for a lot more of those snafus, as the banks, insurance and infrastructure companies do the same.

It's been said over and over by many experts to expect these problems as "remediated code" is put back into production in the months leading to 2000. Remember, for every 100 line of new code, there'll be 7 bugs on average. When Win95 was put into production, it was (still is) riddled with bugs. That's the nature of programing. The more complex the program and the more pressed for time to release it, the more bugs you'll get. Better that those snafus happen spread out intermittently over 13 months than all at once in December '99.

-- Chris (catsy@pond.com), October 29, 1998.

Woe is me-- Keep in mind you can't post anything positive here. The nay sayers will jump all over you. Have a good day..oops I mean have a BAD day. Don't want to sound too positive

-- Believer (OYe@littlefaith.com), October 29, 1998.

I have to agree with Woe. I keep reading, what good is it if it isn't tested? Well, testing is a good thing. We were already sure that nothing could come up without a hitch. I guess I would rather see intermittent interruptions as testing takes place rather than the world crashing down around my ears in14 months.

-- margie mason (mar3mike@alo.com), October 29, 1998.

Woe, I agree. It's hard to spin this as bad news. If I were a project manager, I would be introducing remediated code one step (program) at a time. And even that has undesirable consequences - non compliant code communicating with compliant, for instance. But as each element is cycled into production I would expect the crashes to become more frequent.

-- Elbow Grease (Elbow_Grease@AutoShop.com), October 29, 1998.

The problems could also be caused by "look ahead" to 99, a kind of pre Jo Anne effect. If it is "remediated" code, the errors probably originate in the routing software. Is it good, Is it bad? Who knows at this point? Thats being neither pessimistic or optimistic. I can tell you that if they re-install the old code on top of newly modified data production streams, things could come to a screeching halt. Is that good, is that bad? Who knows? I would love some big event to happen soon to shock more serious preparation at all levels. Lastly, the most damaging errors can be initially hidden. If a system halts thats great! You KNOW you have a problem and you whip (or for the Christian Right,flagellate) the pagan codeheads until they get it right. But what if the errors are not immediately evident? What if the production files gather cummulative errors? You may NOT be able to fix those quickly (if at all.) As Alice said, "its getting curiouser and curiouser."

-- R. D..Herring (drherr@erols.com), October 29, 1998.

IF this is Y2K related, I'm glad they're getting it out now.

I'd rather they tested it correctly first - so this is also an indication of interelated problems not directly due perhaps to y2K - we don't know what programs were affected to what degree by what process - but notice that that:

if a process (and the people in that process) are strained by deadlines and a painful lack of support in one area (like Y2K may be in many companies) then the symptoms may show up elsewhere.

For example: this was a routine fix or improvement (or even a routine data backup) that got screwed up because the person formerly doing it had been transferred to Y2K work. The "new guy" goofed.

Or this "new program" would have been checked by the senior programmer, who had been up all night testing (and fixing a Y2K crisis so the doors could open today), and he didn't get a chance to check it himself.

-- Robert A. Cook, P.E. (Kennesaw, GA) (cook.r@csaatl.com), October 29, 1998.