Interesting article. http://year2000.com/releases/NFinfoliant11_11_1999.html

jeannie

-- jhollander (hollander@ij.net), November 13, 1999

Answers

What are they selling?
Infoliant, quoted source. watchin the bucks...

-- Follow (the@money.com), November 13, 1999.

Good that intensive examination is finding obscure problems with some software. This information is helpful. Just don't fall into the binary thinking that this software used to be perfect, and is now suddenly unusable. Remember that NO useful software is perfect, and some useful software is pretty damn lousy.

-- Flint (flintc@mindspring.com), November 13, 1999.

Flint,

Being new to this forum, I didn't realize you were a DGI. What is difficult to understand when a product goes from a status of Y2K "Compliant" to "Non-compliant", (agreement on the technical definition of 'compliant' not withstanding)?

One can color this in countless creative ways, but it doesn't make a lot of sense to assume that the software identified is either (a) poorly designed or programmed software, or (b) that y2k defects within the software isn't important.

The other posts I have seen from you seem to be somewhat more logical than this.

TA

-- TA (ta@pacific-ocean.com), November 13, 1999.

TA:

OK, I was too brief. Full 4-part harmony this time:

In general, when software changes from compliant to noncompliant, it means that further testing uncovered a date bug prior testing had not located. It's impossible both in practice and in theory to prove a program has no bugs. Testing can never achieve 100% code coverage -- you simply can't test all possible inputs and outputs under all circumstances in all possible environments.

So OK, testing uncovers bugs. Programs are deemed "compliant" after being run through a (hopefully) representative data set, without any date errors cropping up. Think of a bathtub with the tap and drain both open. This is the "test tub". As more systems reach the initial "compliant" status, they pour into the tub. As more rigorous testing takes place (either deliberate testing or just daily use of remediated code returned to production or distributed to customers), date bugs that got past the first phase (the initial declaration of "compliant") undergo scrubbing in the tub, the errors show up, and the systems flush down the drain and back into further remediation. When the newly encountered errors are fixed and initially tested, these systems go back into the "test tub" for the next cycle.

Hopefully, this process makes the systems cleaner all the time, with the understanding that there's no such thing as perfectly clean. The Infoliant report should not be construed as implying that coders are deliberately introducing errors into clean systems. It simply means that remediation is recognized as having limits, and we're doing the best we can to validate our fixes. Also, we're being honest in admitting that our fixes are not perfect.

Bear in mind that Windows 95, widely used and highly useful though it has been, has (last I read) over 5,000 known, documented bugs. Linux is going through the same wringing-out process. Infoliant's news should not be regarded as particularly negative in light of all this, unless you are trying to "support your belief". In which case, go ahead and interpret everything negatively. Reality won't mind.

-- Flint (flintc@mindspring.com), November 13, 1999.

Flint,

You just got called a DGI! And you have prepared more than most people who consider themselves Doomers. This is starting to get interesting.

Amused Regards,
Andy Ray

-- Andy Ray (andyman633@hotmail.com), November 13, 1999.

"Bear in mind" that Windows sucks, regardless of version. I have seen POW Camps with fewer bugs than '95 of '98. God help us when Windows 2000 is rammed down our collective throats. Remeber when people actually typed in program names? Not just click, click, click.......

-- Old Programming Fart (Dreaming@dos.com), November 13, 1999.

Flint is giving it straight. Non-compliance doesn't guarantee that a system will fail on rollover any more than compliance guarantees that it won't fail in in two seconds time in normal operation.

I can give you a concrete example. I've personally seen a non-compliance in a monitoring system in a nuclear power plant. However, it's not keeping me awake, as the non-compliance was simply that some dates on reports which would only be printed and human read used two digits rather than four. That was all. The date was four digits internally, but only two were presented. So TECHNICALLY the system did not comply to the strict guidelines used by the nuke power industry, but, er, so what?

Here's the nasty bit. That same system also contained rogue pointer errors which could bring it down any time of the year, e.g. a common list deletion snafu:

while(list_ptr != NULL) { delete (list_ptr); list_ptr = list_ptr->forward; }

It's staggeringly unlikely to happen unless the OS decided to do garbage collection between the two lines in the loop, but it COULD happen. But we didn't fix it, basically because we wrote the original code, and would have to admit to the error before we could fix it.

Politics, it's all politics.

-- Colin MacDonald (roborogerborg@yahoo.com), November 14, 1999.