From the QA perspective, we are playing against a stacked deck. Every factor that can negatively impact quality assurance is working against us.

1. Immovable deadline - totally incompatible with software development 2. Exquisitely Subtle (like tm_year) problems, undetected, unrespected 3. Ubiquitous problem embedded in every system on the planet 4. Date logic - exactly **the** most crucial code at the system level 5. External dependencies that cannot be controlled (vendors, etc.) 6. JIT culture has removed emergency buffer of supplies 7. Dissemination of information by Govt.(botched is a kind descriptor) 8. Accountability (a prime motivator) erased by Govt. by legislation 9. Pirated applications coming home to roost in supplier countries 10. Viruses planned for rollover en masse 11. Work culture/environment to be either distracted or disrupted 12. Last minute fixes and FOF will come in bushell loads for months 13. Vast Stupidity of unimaginable scope by 'smart' people 14. **Very** late starts, worldwide, in bushell loads 15. Pandemic lying, denial, and exaggeration of state of readiness 16. Major project leaders (eg., Atlanta) being fired at last minute 17. Millennial hacking/bombing (attacks on systems and infrastructure) 18. System age finally matters (legacy systems, 286 controllers, etc.) 19. Christmas (La La Land mentality that overtakes work matters) 20. New Years (alcohol binges on the job, worst possible moment) 21. Systems failing *before* rollover drains programmer resources 22. The Euro - a continuing and major drain of programmer resources 23. Ignoring of, "non-mission critical" systems until rollover

OK, what have I forgotten?

-- paul leblanc (bronyaur@gis.net), December 05, 1999

Answers

Excellent points Paul!!

Ray

-- Ray (ray@totacc.com), December 05, 1999.

Very good! Perhaps the only other factors are the various plagues and disease. (with or without chem trails) Taz

-- Taz (Tassie123@aol.com), December 05, 1999.

The most important one of all: it will happen when the financial system is at the peak of the largest speculative bubble in history with a debt load that would put the 30's bankers to shame.

-- a (a@a.a), December 05, 1999.

Paul- #13 is best....13. "Vast Stupidity of unimaginable scope by 'smart' people"

-- Brian Bretzke (bretzke@tir.com), December 05, 1999.

Things to consider as time slips away. Should get top billing.

-- Ron Schwarz (rs@clubvb.com.delete.this), December 05, 1999.

Will print-out and add to the rest, thanks paul...---...

-- Les (yoyo@tolate.com), December 05, 1999.

tm_year problem? The tm structure gives the
tm_year since 1900. This is easily remediated
by windowing. I've read some other claims of
tm_year problems but none that had any validity.
What exquisitely subtle problem did you mean?

-- spider (spider0@usa.net), December 05, 1999.

Paul:

What you have forgotten is any sense of perspective you could possibly eliminate.

[1. Immovable deadline - totally incompatible with software development]

Misleading. Close counts, and closer counts more. Exceedingly few cases exist of fine one day and dead the next in remediation.

[2. Exquisitely Subtle (like tm_year) problems, undetected, unrespected]

Yuk. If they're so undetected and unrespected, how do you know about them? If there's any one thing we've heard about y2k remediation, it's that it's trivial and boring. Very rarely subtle. Granted, there's too many bugs to fix them all. But tricky it ain't. Just time consuming and tedious.

[3. Ubiquitous problem embedded in every system on the planet]

False. The problem is quite rare in embedded systems, at least until you get up to the large scale systems, where it's more common but still in less than half such systems according to worst estimates.

[Date logic - exactly **the** most crucial code at the system level]

Hardly. Of all the things an OS does, date handling is probably of *least* consequence. Still serious and important, of course. But still much less critical than *most* of the things an OS does.

[. External dependencies that cannot be controlled (vendors, etc.)]

Misleading. Everything that's external to one organization is internal to another. It's certainly true that everyone is relying on everyone else to do an adequate job. But from a system-of-systems viewpoint, NOTHING is external.

[. JIT culture has removed emergency buffer of supplies]

True. JIT will make short-term problems worse. Long-term problems would consume just-in-case inventories and leave us in the same position, though.

[. Dissemination of information by Govt.(botched is a kind descriptor)]

True. The government has dropped the ball on this one. Fortunately (and of course omitted), useful information is widely disseminated in the private sector.

[. Accountability (a prime motivator) erased by Govt. by legislation]

Misleading. Even IEEE argued that swamping the system with lawsuits doesn't fix any bugs, and the fear of lawsuits distracts from the remediation effort. In any case, accountability in reality takes the form of lost sales if you don't fix your bugs, and the government can't erase that. The legislation has probably been a net benefit to everyone.

[. Pirated applications coming home to roost in supplier countries]

True, but limited. Supplier countries can download patches from the net as easily as anyone else. They can also pirate compliant versions, which they are.

[0. Viruses planned for rollover en masse]

Unknown. Those whose responsibility is to guard against such viruses have mobilized against such an eventuality. But this is a contingency plan. Virus writers don't usually announce their plans.

[11.Work culture/environment to be either distracted or disrupted]

Speculation. Hasn't happened yet and might not.

[12. Last minute fixes and FOF will come in bushell loads for months]

True. Productivity will suffer for a while as a result. But even hindsight won't tell us how badly.

[13. Vast Stupidity of unimaginable scope by 'smart' people]

Pure opinion, without any visible means of support. Using 2-digit years was indeed shortsighted.

[14. **Very** late starts, worldwide, in bushell loads]

Probably true, but this remains to be seen. If things are mild, then the starts weren't too late. But yes, indications are that late starts have been much more the rule than the exception.

[15. Pandemic lying, denial, and exaggeration of state of readiness]

Religious dogma! As of today, we have NO WAY to distinguish an accurate statement of readiness from a mendacious statement. They look and sound exactly the same. Maybe in 6 months we'll have a clearer picture of which such statements were more accurate. But today, accepting or rejecting such statements must be done purely on faith.

[16. Major project leaders (eg., Atlanta) being fired at last minute]

There hasn't been much of this, though it has happened here and there. What's been surprising is the extremely tiny percent of project leaders who have bailed of their own accord. If things were as bad as you claim, these positions would be hot potatoes nobody would want to touch. The *lack* of turnover in these positions is one of the stronger indirect indications things might not be that bad!

[17. Millennial hacking/bombing (attacks on systems and infrastructure)]

Huh? Name one. Or is this a prediction? If so, OK, duly noted. We shall see.

[18. System age finally matters (legacy systems, 286 controllers, etc.)]

Not really, or at least not much more than normal. Indeed, it's pretty common to read observations that the sheer magnitude of software and hardware upgrades stands the economy in good stead for the future. And incidentally, this massive level of upgrading hasn't even made a ripple. So this is an argument *against* problems.

[19. Christmas (La La Land mentality that overtakes work matters) 20. New Years (alcohol binges on the job, worst possible moment)]

I imagine those charged with being onsite and ready would resent your assumption that they are irresponsible drunks. By that time, we're totally out of prevention mode and into reaction mode anyway. Where in HELL do you work, where being drunk on the job is permitted?

[21. Systems failing *before* rollover drains programmer resources]

Wait a minute! That's part of the remediation process itself. We've experienced a whole lot of that so far without impact. If we've been both fixing bugs before they bite AND after they've bitten all along, without visible problems, this is another argument in favor of small problems. After rollover, ALL programmer resources can be devoted to fixing, and won't be "drained off" with prevention.

[22. The Euro - a continuing and major drain of programmer resources]

Is this true? It doesn't appear to be causing any problems. Or is this yet another "explanation" of how the Euro's difficulties failed to live up to pessimistic expectations, actually working properly?

[23. Ignoring of, "non-mission critical" systems until rollover]

This practice has not been universal, of course. And there is no clear dividing line between critical and non critical. Each organization decides how to best allocate their resources. Hopefully, they've focused their attentions on systems that are required for safety and production, and if necessary let slide those systems they can fix at their convenience. And this is bad?

[OK, what have I forgotten?]

How to build an honest case?

-- (flintc@mindspring.com), December 05, 1999.

>easily remedied by windowing

Yeah, if every other machine yours talks to is using windowing as well.

Go to the top of the thread and read Mr.LeBlanc's point about smart people acting stupidly.

-- cgbg jr (cgbgjr@webtv.net), December 05, 1999.

Flintc,

[22. The Euro - a continuing and major drain of programmer resources]

Is this true? It doesn't appear to be causing any problems. Or is this yet another "explanation" of how the Euro's difficulties failed to live up to pessimistic expectations, actually working properly?

To me it seems that your knowledge and experience regarding any Euro issues is pretty small. <>.

For next time, please study and research topice before you answer.

-- Rainbow (Rainbow@123easy.net), December 05, 1999.

You all forgot MURPHY (whatever can go wrong, will go wrong!)

-- W (me@home.now), December 05, 1999.

Flint, "Date logic - exactly **the** most crucial code at the system level]

Hardly. Of all the things an OS does, date handling is probably of *least* consequence. Still serious and important, of course. But still much less critical than *most* of the things an OS does."

Paul is refering to application systems here, not the operating system. Application systems are things like:

1) manufacturing requirements planning (MRP) 2) transport scheduling systems of all kinds 3) financial systems of all kinds (AP,AR, etc) 4) human resources (payroll, benefits, retirement, etc). 5) insurance systems (of all kinds) 6) inventory forecasting 7) point of sale systems

...shall I continue?

The point is, that date related logic is by far the most complex logic in any of these systems. The only OS date related impact is that the OS "current date-time" is sometimes used as a baseline date for processing batches, even though a better design for 'batch' processes is the use of "date control files", which avoid the use of OS dates altogether - yet introduce another level of complexity. Another use of the OS current date is date-time-stamping records as they are updated or inserted into databases. (This will become a monumental problem is the OS current date is wrong or invalid)

-- TA (sea_spur@yahoo.com), December 05, 1999.

great post. The responder, Raibow does not get it on your point 22. I took your comment to mean that the timing of the Euro conversion collided with programming resources needed for Y2K.

I would add two others. 24? Work place culture that has fewer people doing more. Multiple calamaties will stretch a tired workforce.

25. It will be winter time. Weather can add a Murphy's law element.

-- Nancy (wellsnl@hotmail.com), December 05, 1999.

FlintSpeak, as practiced at NASA:

"Well, its true we lost the last two Mars missions, but hey! Look at all the money we saved cutting corners!"

-- a (a@a.a), December 05, 1999.

cbgb jr:

Not true. If the interface protocol is unchanged (the vast majority are), then you don't really care *what* the other system does -- window, expand, even ignore. Your understanding of windowing is incomplete.

Rainbow:

I'm aware that the Euro has experienced problems. My understanding was that these problems are about as expected considering the size of the Euro project. To what degree the Euro effort has siphoned resources from the y2k effort will be difficult to determine even in hindsight. I agree that the Euro timing was as bad as possible for the y2k effort, though.

TA:

Yes, I agree date processing is complex at the application level. Perhaps when I read "system" I should have interpreted this as "application". You understand that from my perspective, the OS itself is an application program! [grin]. The "system" is in the silicon, to me.

Anyway, what you're talking about is what remediation has been addressing, isn't it? I agree with you (and paul) that at the application level, date logic is one of the worst things that can get screwed up.

To all:

My point was that paul leblanc is engaging in distortion, NOT fabrication. Many of his points are exaggerations, and he omits anything that doesn't happen to fit his viewpoint, which is the very large majority of all we know about this problem.

-- Flint (flintc@mindspring.com), December 05, 1999.

a@a.a said:

"FlintSpeak, as practiced at NASA:

"Well, its true we lost the last two Mars missions, but hey! Look at all the money we saved cutting corners!" "

The last *3*... these two and the Mars explorer about 5 years ago. Conspirators are already suggesting that they are being used as spy network satellites and were never meant for Mars anyway, but NASA (or whomever) used "Mars" as a front for funding.

-- joe friday (joefriday@xfiles.fbi.gov), December 05, 1999.

Paul, yes, a, yes. Paul, you forgot the solar flares that might disrupt communications and the earthquakes that have hit technology centers such as Singapore (okay, Singapore is the only technology center hit). But, with the bases loaded, as we see, could it be possible that our fate is inevitable and this is a set-up, planned by God?

-- Mara (MaraWayne@aol.com), December 05, 1999.

flint:

# 3 Embedded in every [software] system on the planet.

You read this as a reference to "embedded systems".

AS stated (even without my addition) it is TRUE.

Night train

who BTW NEVER posts to chat rooms. DON'T BE FOOLED by HANDLE HIJACKERS

-- night train (nighttr@in.lane), December 05, 1999.

night train:

In that case, yes, it's close enough. Certainly we should assume date problems with every system until proven otherwise. It has been a huge job, and will continue to be.

-- Flint (flintc@mindspring.com), December 05, 1999.

Mr. Flint,

Your intellectual hubris has grown tiresome, (to say the least) please allow me to suggest an affirmation for you to contemplate:

"I may be ignorant about a lot of things but not about my own ignorance" From the author of An expose on the book of Proverbs.

-- d----- (dciinc@aol.com), December 05, 1999.

Yes, it seems that fate is dealing us the worst possible cards for Y2K. Bad news is piled on top bad news; an article in Sightings states that mad cow disease has infected deer and elk in the US (so much for living off deer meat after TEOTWAWKI). A return to the stone age is in the realm of possibility.

-- Ocotillo (peeling@out.===), December 05, 1999.

As a CQE and QA Manager, many of the same thoughts have come to me as well. Excellent post!

Normal Curve Kook

-- Y2Kook (Y2Kook@usa.net), December 06, 1999.