I see a lot of people say it is "too late", but I have seen it used in so many ways that it is hard to understand the standard definition. Too late to get everything done (I agree with this one)? Too late for testing? Too late to get ANYTHING done? Which of the many possible answeres is it?

Rick

-- Rick Tansun (ricktansun@hotmail.com), October 19, 1998

Answers

Good question. Depends on your point of view. My opinion --

1. Too late to get everything done? YES.

2. Too late to get all MISSION CRITICAL things done? [You forgot this stage.] YES -- for most government and some industry, and that's one of the real problems. Moreover, as time goes by the definition of 'mission critical,' as reported publically, appears to change, witness the decrease in the number of mission critical systems reported by the various government agencies.

3. Too late for testing? YES -- in many cases code will probably be put into production without test. That will be another problem.

4. Too late to get ANYTHING done? NO. Every day that is spent on remediation will see SOME things getting fixed.

5. Too late to develop contingency plans? NO.

Now, this brings up a problem. Given X number of days, with X being insufficient to 'get everything done,' or even 'get mission critical' things done, should resources be devoted to:

A. Fixing everything possible, so that as little as possible must be done after 2000-01-01?

B. Doing only enough to erect a wall of 'due dilligence' between the agency or company and lawsuits?

C. Establishing the best possible contingency plan to provide maximum service throughout the period between now and the time complete remediation is accomplished?

For the purpose of answering the question I ask, assume that corporate or agency resources will only permit either A or B or C, not A plus C [which is the best possible condition.......and which recognizes that failure IS an option]?

-- rocky (rknolls@hotmail.com), October 19, 1998.

Too late to get everything done certainly. As y2k can be fixed system by system its a question of slogging your way through them. Of course there are interfaces that have to be tested when all systems in a group are ready. Though the strategy I have known is that each system has been implemented when ready with retrogressive testing and bridging where necessary. The question is what effect will the remaining non-compliant systems have on the organisation.

-- Richard Dale (rdale@figroup.co.uk), October 19, 1998.

...and it's definitely not too late to get to know your neighbors and to become less dependent on 'The Machines of Our Lives' working perfectly each and every day.

By the way, Richard, I want you to know that I hold you personally responsible for the sleep I lost last night...seems a silly little song kept going through my head ('De Yourdon posters sing dis song, Deedah, Deedah...') ;-)

Arnie

-- Arnie Rimmer (arnie_rimmer@usa.net), October 19, 1998.

Arnie, glad to be of service, join the insomniacs club!

-- Richard Dale (rdale@figroup.co.uk), October 19, 1998.

wow, Thanks to both Arnie and Richard... now I have it bouncing around in my head too.

Has anyone contemplated how early problems as a result of either bad y2k code or new errors code from fixes might hinder remediation and testing?

I haven't really seen this question addressed. I suppose, like most y2k issues, it's absolute speculation. But it does raise the quesiton of how fix on failure might be the climate soon because for many it is too late and problems can begin as early as Jan 99, if they haven't started already.

I want some really good news. Someone tell me I'm just grasping at straws.

Mike _____________________________________________________________

-- Michael Taylor (mtdesign3@aol.com), October 19, 1998.

Michael, you ask an interesting question. I've heard of quite a few pre-existing y2k bugs that have surfaced and quickly been fixed, with the public being no wiser. The real howlers reaching the news tend to involve incorrect repairs.

Many people don't realize just how reliable the big iron systems are. We're talking about hundreds of billions of high speed transations over a dog's age with nary a hiccup. Tiny errors multiplied by these transaction rates result in problems that are hard to suppress.

The feeling I get (and it's no more than a feeling right now) is that very few serious y2k bugs have actually sruck yet, although that will change in a couple of months. What we're seeing is the results of inadequate testing, remediated code being slammed into production and doing strange things. In a few months, we'll be seeing a lot of *both* kinds of errors, as y2k strike dates pop up, fixes get rushed into place, and fixup errors replace the y2k errors. Hang on tight.

I've seen several ways of looking at the 'too late' issue. From a repair standpoint, we look at the size of the task, the intensiveness of date usage, the urgency with which it's being addressed. Too late means you can't complete the entire task on time, then it means you can't finish the critical systems on time, then it means you can't get contingency plans in place on time, as the clock ticks away. From an operational standpoint, too late means the problems you're having are impossible to overcome, and you can't stay in business. This form of too late is bearing down on us, but hasn't hit yet. The good news is that, in a degraded economy, any business that can accomplish anything at all must be counted a success, and many will be able to do at least a little. The bad news is, for the population as a whole to come through this, we need a *lot* more than that, and probably won't get it. Sorry.

-- Flint (flintc@mindspring.com), October 19, 1998.