I have been involved in designing and building electronic systems for three decades.

Today I made a little change in a system which everyone agreed should be just right with no testing. At some cost I threw everyone off the system and made the test, right in its native environment. Yep. There was no problem -- this time. But I have enough experience to know -- IF IT HASN'T BEEN TESTED IN ITS NATIVE ENVIRONMENT IT HASN'T BEEN TESTED -- and is PROBABLY flawed and still needs some tweaking.

The native environment of the worldwide interdependencies of computer systems is: everything fully integrated and up and running -- your "systemic" issue. Which is to say -- IT DOESN'T MATTER HOW "COMPLIANT" or "TESTED" ANY COMPUTER OR PLANT IS. IF IT HASN'T BEEN TESTED IN ITS NATIVE SYSTEM -- everything up and running in the year 2000 -- IT HASN'T BEEN TESTED -- NOT EVEN CLOSE! So, it is IMPOSSIBLE to really finish testing until the year 2000 -- there is no such thing as 100% compliant until everything has been integrated in the year 2000.

And there is the lost word of y2k theory -- integration. Here is an example of a typical design/test cycle for an electronic system.

Three things need to be designed --

The programmable chips

the boards

the system

You design the chips and test them.

Then they need to be integrated together on the board.

You test the boards.

Then they need to be integrated into the system.

The integration steps are HUGE. They are way more complicated and time consuming than designing and testing the component parts. ANY DESIGNER KNOWS THIS.

And that last step -- system integration in the live and final environment -- is the critical one. It ain't done till that's done. AND FOR Y2K THAT FINAL STEP CAN'T EVEN BE BEGUN SYSTEMICALLY UNTIL AFTER THE TURN OF THE YEAR!

So, I keep hearing that this is 98% compliant, and that is 100% compliant, and I just sneer. They're testing the individual parts. Integration is still ahead and it can't even begin until 2000. So that is the lost word of y2k. No one is talking about the integration in the live, final, environment. Unfortunately, everything may have collapsed before we even get there.

And that is why you are right. It can't be fixed, it's systemic. And the system can't be integrated until after the year 2000.

-- owl (new@new.com), September 02, 1999

Answers

Owl,

I know you're right about this. I'm not a programmer or systems designer I'm just an end user and I've lived with one for 17 years. He has 30 years of experience spread over a wide range of possible applications. Systems operator on mainframes, in large shops and Universities. He has been hired by banks to teach programming to their employees. He has taught college level programming courses. He has set up and used large networked SGI workstations, running complicated graphics software, here in the U.S. and in Central America. And we have 3 computers here in our home, networked together and loaded down with just about every toy you can hook on. The list of his experience goes on and on.

He started out on IBM mainframes. I've heard all of the stories. He's told me how while working in one large shop that it could take as much as six months of running a new system side by side with the old one, working out the bugs and that was just to port the same software to new hardware.

I've listened to the curses and watched as he futzed for days working everything out when he hung another piece of hardware to an existing system. Every new upgrade had it's bugs, some didn't show up until he was using the system for months and then, bamb! I've watched him absorb new languages and manuals the size of "dang near the entire encyclopedia", he's not dumb, it's just the nature of the beast. And I've seen that you are right, you have to have everything installed and up and running in the intended environment to see if the system will hold together.

-- Mrs. R (not@thistime.net), September 02, 1999.

Mrs. R. right on! We are getting to the heart of this 'mystery'. Its no mystery at all. Can we all say 'system' 'systemic' 'systematic'. We are dealing with a real big, interrelated operating system. By the way, I don't have 30 years of programming. I posted that message from another site. But I will say this much, after a year debating and researching the 'mystery' of Y2K, I now understand computers very well indeed, in some cases it seems, better than the progammers themselves. Either that, or the DGI live in some form of denial.

Owl

-- owl (new@new.com), September 02, 1999.

Owl,

Just a note about forum etiquette. VERY important to credit original author of post. It is also good to provide a URL to where the post came from or at least the name of the board.

It is a great post though and is a topic that certainly needs to be looked at. Integration is vital to any process and has been amazingly glossed over.

-- R (riversoma@aol.com), September 02, 1999.

Sorry I can't pass this up "after a year debating and researching the 'mystery' of Y2K, I now understand computers very well indeed"

ROFLMAO, What???? You understand computers because you can type???? This has nothing to do with Y2K remediation. You're talking about installation of new systems, not remediation, totally different animals.

-- Maria (anon@ymous.com), September 02, 1999.

Besides the rather obvious and apparently overlooked fact that these "integration" issues have been occuring when systems are placed back into production, not being "stored up" for 1/1/2000.

-- Hoffmeister (hoff_meister@my-deja.com), September 02, 1999.

Note that BOTH Maria and Hoffy have COMPLETELY IGNORED the main thrust of owl's post: That come January 1, 2000, we will at best be using systems that have (hopefully) been remediated, and (hopefully) unit tested, but not tested as an entire, cohesive system of systems. (You know, like the way we use this stuff in the real world?)

-- King of Spain (madrid@aol.com), September 02, 1999.

Aah, Maria, you see, even many computer geeks are DGI. Sad isn't it. What Y2K has revealed is the inability of individuals to see the forest from the trees. I have gone from intuitively believing that Y2K will be a mess, to assembling the understanding necessary to prove that it definitely will be a mess. I've had to listen to all the BS, the factoids, the uncertainty, and then paint a completely pragmative picture. No small task, judging from the BS that computernoids continue to express. But by making the right assumptions, then asking the right questions, I've proven the following: testing for the most part is taking place in simulated, not real, environments; the first live test will take place on 01/01/00, and being the 'first' test, will undoubtedly fail (unless all programmers are superhuman geniuses - not); new systems that are tested live are failing, which doesn't bode well for the rollover simulants; rewriting code is laborious, frought with error, boring, and rushed; and final conclusion:::: Y2K cannot be fixed, not now, not ever. It was designed with 2 digits in mind. Can't be reworked into 4. Not bad for a neophyte eh? I'd like to see come of your 'experts' draw these same conclusions.

Owl

-- owl (new@new.com), September 02, 1999.

Really, Your Highness?

I thought I was addressing exactly what you say is the main thrust.

These systems will have been running in production as a cohesive unit. And have been. The integration issues have been and are being addressed now.

-- Hoffmeister (hoff_meister@my-deja.com), September 02, 1999.

Good find, Owl.

That is why Infomagic and several others point out that it took over 40 years of INTEGRATION to come to this point (think of all the headaches, sweating and cursing that happened over that time), and that it is impossible to cram the same in 5+/- years, no matter how fast the entire world's population of techies spin their wheels. Either you understand this or you don't.

-- Chris (%$^&^@pond.com), September 02, 1999.

Sir Hoff, yes the units have been tested and placed back into production. BUTTTTT, they have NOT been rolled over. Therefore, therefore, therefore, THEREFORE, you don't really know if the integrated units will all talk to each other, do you? You have a bunch of systems that have been 'fixed' individually, but not tested together using the 01/01/00. Now, who really understands systems?

Owl

-- owl (new@new.com), September 02, 1999.

Hoff: "These systems will have been running in production as a cohesive unit. And have been. The integration issues have been and are being addressed now."

Where? Here in the US? What about the systems of the rest of the world? What about the global banking system? That IS a single system. Systemic. The entire earth's technological culture is systemic.

-- Chris (%$^&^@pond.com), September 02, 1999.

Hoffy, maybe its a matter of semantics. OK, let me try to put this as simply as I can.

1) Lets say that I have two systems, which we will call A and B.

2) A and B exchange data; they depend on each other; a change made to one without a corresponding change to the other will cause problems.

3) I make a change to system A. I test it as a standalone unit.

4) I make a change to system B. I test it as a standalone unit.

5) I then test A and B in unison.

It is, under the optimistic scenario that we are working under, step 5) that is not being accomplished for Y2K problems. At least, not until January 1, 2000. And therein lies the problem. (You DO see the problem, right Hoffy? Tell me you see it. Pleeeaaase?.... OK, you give up? I'll tell you, then: BECAUSE ITS TOO DAMN LATE!)

-- King of Spain (madrid@aol.com), September 02, 1999.

Owl, your premise is these have been tested individually, and have been rolled over.

They are "talking" to each other now. Problems encountered in getting them to function together have already been addressed.

If the individual units handle the rollover, and are "talking" with each other now, what will change on rollover to "stop" them from "talking" to each other?

-- Hoffmeister (hoff_meister@my-deja.com), September 02, 1999.

For those who have been knocking the Gary North site of lately, for not submitting verifiable info, this just shows that common sence doesnt need an author bio. Owls posting was an open e-mail to GN.

-- Les (yoyo@tolate.com), September 02, 1999.

Common sence? Isn't that when you share a doobie?

Sorry, gotta take time to laugh:)

-- CygnusXI (noburnt@toast.net), September 02, 1999.

Hoff -- And your premise, merely an assumption, however much the gods of Gartner weigh in with their secondhand data and opinions, is that the vast majority of U.S. systems have been put back into production. ROFLMAO. Not to mention worldwide.

-- BigDog (BigDog@duffer.com), September 02, 1999.

Owl and his highness, you think you know about this but you don't. You're not that intelligent. Tell me how many systems you've tested and I'll tell you how much you know about integration. Just because you're able to spell out a "testing approach" doesn't mean you understand what it takes to test and what's neccessary and sufficient. Owl the quote above that says you know because you've researched for one year is so funny. How does that compare to my more twenty years in the IT world of programming, testing, and project management? I'll answer for you, it doesn't, no way, no how.

-- Maria (anon@ymous.com), September 02, 1999.

Owl, You make alot of sense. I HOPE that the people who are working on this y2k problem understands it.

Remediation is done differently with different systmem. Work arounds, windowing, ignoring meaningless output might not be "understood" by other dependent systems after the "cutoff" date.

the year 2000 might be represented as 00, 2000, 1972, 1972+28, 1900, 100, etc. and that convention understood by that system alone.

-- serio (survival@y2k.com), September 02, 1999.

Ah Ve Maria, please read:::

Remediation is done differently with different systmem. Work arounds, windowing, ignoring meaningless output might not be "understood" by other dependent systems after the "cutoff" date.

As far as my intelligensia goes, guess what, programming does not automatically make you 'smart'. Who got us in this mess, anyway :)

Owl

-- owl (new@new.com), September 02, 1999.

All hail Troll Maria!

Goddess of knowledge, queen of the putdown, princess of pollydom!

What would we do around here without your valuable input, your highness?

-- mci (goddess@troll.maria), September 02, 1999.

Owl am I to understand you correctly: programming doesn't make you smart about programming but researching for one year does. My comment on your intelligence was not absolute, that is, you may have an enormous intellect but that can not make you understand testing and integration, if you have no experience. No one is that smart to completely understand a topic without hands-on experience.

And no, mci, you will never benefit from my valuable input because you see my signature and ignore the message. Unforturnately you think there's nothing you can learn from me. How sad for you! Now if you have something that may help me learn, by all means share it.

-- Maria (anon@ymous.com), September 02, 1999.

OK, for the benefit of Hoffy (I've given up on Maria), lets continue from our previous A and B example, and see if we can discover what might "stop" A and B from correctly interpreting the data that they exchange, come Jan 1, 2000....

Programmer Alfredo Alpha is the programmer for system A. Upon performing his Y2K remediation, Alfredo originally thought that he would just do the old 2-digit to 4-digit year trick. However, after seeing how much work would be involved, how much time it would take, etc., he instead chose a windowing type scheme as follows: If the (2-digit) year is less than 50, assume that the year falls in the 21st century; otherwise assume that it falls in the 20th century.

Programmer Betty Beta is the programmer for system B. Like Alfredo, her preference would have been to do a nice clean 2-to-4 digit conversion, but ended up implementing the following instead: IF the (2-digit) year is less than 50, represent the value by using scheme whereby the leading digit becomes a 21st century decade indicator, and the final digit is the decade offset -- 2000 is "A0", 2001 is "A1"; 2009 is "A9", 2010 is "B0", 2011 is "B1"; and finally, 2049 is "E9".

Alfredo tests his system, A, and finds that it flawlessly handles Y2K. Betty does the same for her system, B, and likewise finds that it handles Y2K flawlessly. However, on January 1, 2000, it all goes down the tubes.

Hoffy, do you see why? (Maria, I told you to go to the back of the class and put your nose to the wall! And stop using foul language, young lady!!)

Quotable quote: "Y2K is not rocket science. In fact, its barely computer science."

-- King of Spain (madrid@aol.com), September 02, 1999.

Hoffy's argument that the systems have been integrated and tested and are running together now is valid, but he totally ignores that fact that this new system of programs is not doing anything the old system wasn't. In truth, the old and new systems are (or should be) indistinguishible from one another up until 1/1/2000. After that boundary, the old system is expected to be inoperative and the new system is expected to continue to function without error. However, Owl's point that the program or system of programs has not been tested in it's new environment is valid. Not until after 1/1/2000 will all of the programs in the system be operating "in their native environment." It seems likely that there will be _some_ residual errors that are not and cannot be detected until the systems are in operation after 1/1/2000. My experience has been that it is these "unexpected" bugs that are the most difficult to find and fix. Because of this, I expect a very bad time for computerized systems beginning Q1 of 2000, and I expect a worse time for data integrity throughout all of 2000 and 2001.

George

-- George Valentine (georgevalentine@usa.net), September 02, 1999.

Err, leaving the details of your actual example aside, Your Highness, we are talking of interfaces. So, over and above the details of your example, System B must make this change, knowing it is to an interface being passed to someone else, and also not inform the other party.

BigDog and Chris, the original post and premise of this thread is for systems remediated and tested. At least that's my impression.

Yes, there could still be a residual error in a windowing routine. But the main point is that the overwhelming majority of integration issues that arise will have already been encountered. Steve Heller and I spent quite a bit of time on this in his Debate #2 thread.

-- Hoffmeister (hoff_meister@my-deja.com), September 02, 1999.

Just remember that the teams of professionals that created these computing systems and world wide applications are still here, still on earth and still tweaking the system, improving it and so-on. The process of certifying everything is only a function of time. Everything else is in place.

-- thinkIcan (thinkIcan@make.it), September 02, 1999.

Who knows, Maria, maybe I'm a genius, eh? What amazes me most about this discussion is that Sir Hoff believes computers will talk to each other after the rollover. What is 'remediation' anyway? That a computer can recognize 00 and interpret it correctly. OK. So individual computers can do this. My question - when computers talk to each other, what are they really saying? In other words, what does the date field have to do with it? Hoff, please explain...

Owl

-- owl (new@new.com), September 02, 1999.

Owl, I've been coding, integrating and testing large systems for almost 20 years, and you make more sense to me than Hoff or Maria.

Hoff's problem is that he sees the world as a homogenous network of SAP R/3's smoothly interacting with fully tested data. Nothing could be further from the truth.

Maria's problem is that she thinks it takes a programmer to understand the interconnectedness of the world's digital infrastructure. Again, nothing could be further from the truth.

Programmers usually deal with compartmented information on systems within only their company or industry, and until they research the systemic nature of the y2k problem, they can be just as clueless as anyone. What programmers do have however, is a keen understanding of how long it can take to fix a complex system problem. And that is why a lot of them are scared of y2k, not necessarily because they can see the Big Picture.

-- a (a@a.a), September 02, 1999.

Hoffy, you are begging the question. OF COURSE programmers need to inform others when changes are made. Whether the "interface" to which a change has been made is between one procedure to another procedure or from one system to another. And once so informed, re-coding is necessary to handle said interface change. But to make sure that the re-coding is accurately reflecting what is actually going to happen, it is necessary to TEST!!

In fact, if I take what you said to mean what I think you are saying, even within a single computer program, one never really needs to test it IN TOTAL. Merely unit test each single procedure, and if those individual tests check out, the testing is complete, surely nothing could go wrong. (LOL!)

Gosh, why stop there. If you individually test EACH LINE OF CODE, why ever bother to unit test a procedure?

Hoffy, unless you are able to test the whole she-bang, as in ALL OF IT, you don't know what is going to happen when you "go live". And that is one of the BIG problems with Y2K, until we "go live", we won't have any confidence that things will work reliably.

(Sayyyy, you don't suppose THATS the reason everybody last year kept saying, "Yes, we will be done with our piece by Dec 31, 1998, which gives us a full year for testing"....)

-- King of Spain (madrid@aol.com), September 02, 1999.

Would any programmer that has fixed a system without actually running it please raise their hand?

Owl

-- owl (new@new.com), September 02, 1999.

'a', I can honestly say, of all the interfaces I've written none have been R/3 to R/3. All have been connecting to other systems, mostly the "old, legacy, mainframe" systems.

Your Highness, of course you need to test. Again, my point is that, for systems reimplemented into production, that testing has either already occurred, or is occurring in production. The only thing that changes on rollover is whether or not the two systems can handle year 2000 dates. The format won't change, outside of your, umm, interesting example. Both systems are either now handling expanded dates, or windowing them.

Owl, computers "talk" to each other in a variety of ways.

Most prevalent is the use of an interface "file". These take standard forms (i.e., EDI), or non-standard, customized forms. But in almost all cases, a physical file is passed.

The records in the file contain date fields. Date field formats can be in many forms. But the important thing is that, for any given date field in any given file, only one date format is used.

That's why, for example, it doesn't really matter if one system expands dates, and another uses windowing. The interface definition will use either an expanded date or a 2 position year date format. And both systems must be able to process that format now.

-- Hoffmeister (hoff_meister@my-deja.com), September 02, 1999.

(Gawd!) OK, Hoffy, returning to my "ummm" interesting example:

1) A is Y2K compliant.

2) B is Y2K compliant.

3) A and B are working together just fine right now, merrily processing current (i.e., 1999) dates.

4) Come Jan 1, 2000, THEY WILL NOT WORK FINE, EACH SYSTEM HAS A DIFFERENT METHOD FOR HANDLING 21ST CENTURY DATES. THE WHOLE SHE-BANG IS DOWN THE TUBES. STOP. IT HAS CROAKED. THINK. TESTING THE TWO, T-O-G-E-T-H-E-R, WOULD HAVE CAUGHT THIS AHEAD OF TIME. LISTEN. BUT NO SUCH TESTING WAS DONE. KAPUT.

-- King of Spain (madrid@aol.com), September 02, 1999.

a, it would be nice if you could read. My point was that you should talk about topics you know something about, like maybe aliens. If you know nothing about testing and integration, you can comment all you want but you are talking BS, nothing more.

"What programmers do have however, is a keen understanding of how long it can take to fix a complex system problem. And that is why a lot of them are scared of y2k, not necessarily because they can see the Big Picture." Aaah, so you see the interconnectedness, my little grasshopper. But Y2K is not a complex system problem; it's a complex management problem. Programmers can easily make their fixes, not a difficult task in their world. Managers, OTOH, need to make sure the test and integration work well. Another point, remediation not the same as new development, no comparison, so don't compare them. Y2K is an easy job compared to new development. Can't compare the life-cycle of new development to Y2K, in Y2K many steps are not necessary and can be skipped. Some of those steps include testing, not needed to lower risk. You continue to draw analogies here when they don't apply. Y2K needs more regression testing than any other kind of testing. When all functionality stays the same, regression testing is required. There's nothing to integrate, when functionality stays the same, no new systems to integrate, just the old ones with expanded date fields or bridges, no new technology, no new design, no new language, no new hardware (except maybe some replaced pieces with same functionality), no new anything.

Yeah, owl, you're right about the test conducted in the lab environment. We won't roll the clock forward until 1/1/00.

-- Maria (anon@ymous.com), September 02, 1999.

Sir Hoff, I assume the interface interprets the meaning of the date- field, making it 'palatable' for the computer on the receiving end. So, it would seem that a lot of date-field 'translation' is going on, so that computers can interpret each other. But my point is this: aren't there almost an infinite number of ways to encode a date field, some of them archaic? And how well does an interface really work, ie first time lucky?

Owl

-- owl (new@new.com), September 02, 1999.

Again, owl, the point is that any given date field will use only one date format, out of the many possible available. System A doesn't just decide to use YYMMDD, allowing System B to just decide MMDDYY.

Ana again, for your example, these systems are already reimplemented. If there was a mixup, it would be caught now.

-- Hoffmeister (hoff_meister@my-deja.com), September 02, 1999.

What the hey, let me even take the A-B example one step further and get down to the nitty-gritty data. There is really nothing left after that.

1) On December 31, 1999, system B passes a data record to system A, with one of the fields being the current date in the form of YYMMDD. The date field appears as "991231". It is accepted and processed without problems by system A.

2) On January 1, 2000, system B passes a data record to system A as defined in 1). The date field appears as "A00101". This is not valid for system A, and the results now depend on how the exception routine (if any) for system A was written. Some possibilities: the entire record might be outright rejected; the year may be misinterpreted due to the way it is numerically processed; the application on system A that is processing the record may abnormally terminate.

And that is really it. I can't be any simpler than this, can it???

Maria: ALIENS??? Gawd!

-- King of Spain (madrid@aol.com), September 02, 1999.

"Owl, computers "talk" to each other in a variety of ways."

To quote my friend "Man created computers in his own image, he didn't know anything else for model."

Both quotes above are so true. And the proof is this thread; each one of the contributer's brain functions and "talks" differently.

We're experiencing a brakedown in communication.

(I don't expect you to understand what I mean Maria, because this has nothing to do with "hands on experience", merely comprehention.)

-- Chris (%$^&^@pond.com), September 02, 1999.

KOS maybe that's a topic you should start discussing because it's obvious, even to the casual observer, that you know nothing about Y2K testing.

-- Maria (anon@ymous.com), September 02, 1999.

I have 2 systems that have to work together. One supplies me with real time data. The other reads it and analyzes it. These 2 vendors are among hundreds available. Everytime there is an upgrade in either system, I have to do alot of troubleshooting to get it working and still I end up losing some functionality that I was accustomed to.

Although the upgrading vendor announces months in advance of the

So, Hoffy and Maria, let me get this straight. You both are saying that there will be no problems in y2k because everything has been tested? changes, maybe due to proprietary nature of the code, the transition has never been smooth nor timely.

-- Serio (survival@y2k.com), September 02, 1999.

You may be right, Maria, but give me some credit: I lay it all out, very simply so that it is easy to follow, so that a knowledgable person like yourself can point out the error of my ways. But somehow, for some reason, pollies never seem to be able to.

Things that make you go Hmmmmm. (Or, "Ummmm".)

-- King of Spain (madrid@aol.com), September 02, 1999.

No, Serio.

Again, I read the original premise here to be systems remediated, tested, and reimplemented into production individually.

Upon reimplementation, any functional changes and problems will surface. Not in any way saying these don't exist. Just that they have and are happening, and are not sitting there waiting to happen on 1/1/2000.

-- Hoffmeister (hoff_meister@my-deja.com), September 02, 1999.

Sorry ,weird editing in previous post:

I have 2 systems that have to work together. One supplies me with real time data. The other reads it and analyzes it. These 2 vendors are among hundreds available. Everytime there is an upgrade in either system, I have to do alot of troubleshooting to get it working and still I end up losing some functionality that I was accustomed to.

Although the upgrading vendor announces months in advance of the changes, maybe due to proprietary nature of the code, the transition has never been smooth nor timely.

So, Hoffy and Maria, let me get this straight. You both are saying that there will be no problems in y2k because everything has been tested?

-- Serio (survival@y2k.com), September 02, 1999.

Hoffy, I just laid it all out: the problems between A and B cannot POSSIBLY show up prior to Jan 1, 2000, even though A and B were indeed remediated/tested individually. Until Jan 1, 2000, both systems were in agreement on how to handle the current date. Starting Jan 1, 2000, due to a MISTAKE on the part of either Alfredo (system A's programmer") or Betty (system B's programmer), this could not be caught in 1999. UNLESS testing was done with the two systems TOGETHER, which was not done.

It is that simple, dude. If my logic is wrong in my A-B example posts above, I would love to know where.

-- King of Spain (madrid@aol.com), September 02, 1999.

Chris, what profound thinking! Did you think of it just because of this particular thread or did it come to you after reading just about any other thread on this forum. Duh. BTW, feeling a little small because of my experience and your lack thereof.

Sorry your highness, your assumption that interface testing is not being conducted is just another example of doomers not knowing what's going on in the world of remediation. Just because the details of testing is not reported to the world, doomers should not conclude that interface testing is not being done. It is being done to a degree that it has never been done in the past.

Serio "You both are saying that there will be no problems in y2k because everything has been tested? changes, maybe due to proprietary nature of the code, the transition has never been smooth nor timely"

No I'm not saying anthing close to that. I'm not concluding there will be no problems in y2k, never have. I'm saying that this kind of integration testing is not needed for Y2K. Regression testing is needed. There is a difference. Again, Serio, you are drawing the analogy between new development and Y2K when it doesn't apply. Transition for new development and new systems has never been smooth nor timely. Y2K has a totally different nature, one cannot extrapolate the statistics as easily as Eddie Yourdone as done.

a, do you want to discuss more about your experience in testing.

-- Maria (anon@ymous.com), September 02, 1999.

Your Highness, nothing wrong with your "logic", per se.

The example, however, is a different matter. Is this made up, or have you actually seen a system that a) stores dates in this manner, b) uses these dates unchanged in an interface and c) did not inform the other system this format was to be used.

Seriously, Your Highness, your example shows the lengths one must go to, to come up with an example that will fail on rollover.

Yes, using the "1000 monkeys typing for 1000 days" theory, this may actually occur. But certainly not to a degree that would cause undue concern at rollover.

-- Hoffmeister (hoff_meister@my-deja.com), September 02, 1999.

Time to bore down on the nitty-gritty. Hoff, Maria, you are involved in remediation, that is obvious. You are front line, right? So tell us, and keep it simple please - what failures have you encountered during testing, AND, projecting this experience forward, what failures do you see upon rollover. Thanks...

Owl

-- owl (new@new.com), September 02, 1999.

Hoffy:

This was a very contrived example. It had to be to keep it so simple. If I had tried to make it more real-world, then it would have been harder to follow. (And I would have never been able to pin you down!!!!)

If your basic point is that the logic is sound, but the example per se is so artificial that it has no relevance whatsoever to the real world, that may be a valid point. I am in no position to make that kind of judgement, and would defer to others.

Maria:

You are a complete dither-brain. If there is world-wide testing of interfaces being done, then surely that means there is also world-wide testing of what is being passed via those interfaces. If true, then we would be hearing nothing but reports about testing, not remediation, patches, etc.

I'm not saying its not possible to only test interfaces, but that becomes so artificial (some might call it "contrived"), that you are still left with the same basic problem: going "live" on January 1, 2000, with for all intents and purposes, systems that have not been tested ALL TOGETHER.

-- King of Spain (madrid@aol.com), September 02, 1999.

KOS huh? Maybe you hit your head one too many times in mudwrestling.

Owl, from my experience few problems will happen on 1/1/00 (we didn't experience any during testing of the rollover) and a few more later with downstreams, maybe a month or two into the new year. But also in my case, there will be ample time to find and fix the problems. Can't answer for other organizations.

-- Maria (anon@ymous.com), September 02, 1999.

Maria, Each upgrade has been due to a 3rd party change in the way it formats data. Adding a extra demimal, going from fractional to decimal, etc. These changes are publicly announced ahead of time but there is nothing the second vendor can do but sit on their hands until we see the new output format.

Y2k is also a data format change very similar to what I have encountered except in a much larger life impacting magnitude.

In science and management we learn that the whole is not equal nor equivalent to the sum of the parts. We are conditioned to think that their being equal as the exception rather than the rule.

[testing the whole is not equal to testing the individual parts]

We live in a dynamic, complex, and interacting world!

-- Serio (survival@y2k.com), September 02, 1999.

In January of this year me and a co-worker just finished writing some code and we decided to test it.

The program: Type in number of days from now and it will show the date in 1-Jan-1999 format. An example it is the 2-Sep-1999, type in 2 days and it will return 4-Sep-1999.

What we tested: We just put all sorts of numbers in, checked to see if it would display dates in 2000, 2001, 29-Feb-2000, 2020 all displayed flawlessly and we regarded it as a success. We even compared against a calender in some cases to double check.

What do we do this date that is output?: Well we use it for several things and other programs do process this date for its own calculations.

So you would think this little program was ok right? It was Y2K Compliant but it had another flaw. It was by pure luck that we discovered it and come December of any year there would have been a lot of data that would have been really screwed.

The Dec in 1-Dec-1999 was coming out as garbage.

Regards, Simon

-- Simon Richards (simon@wair.com.au), September 02, 1999.

Maria, you are the most arrogant person who has ever posted on this forum. It wouldn't matter if you were the most intelligent person in the world. No one would know it, because they couldn't hear you above the noise of your love for yourself.

-- (none@none.none), September 02, 1999.

Hoff:

A) No one said there aren't examples of well maintained or sufficiently remediated systems. Its the ~20% that don't fall into that category we're concerned with.

B) There has been insufficient time for adequate testing

C) True, some interfaces are simple and well defined as you mention. But some are really f*cked up and cause constant problem NOW with 2 digit dates

D) See Cory's post today. The geeks are talking about taking vacation over the rollover. Not a good sign.

Maria: Honeybuns, I could integrate & test circles around your sorry bahunkus. Maybe you'd like to see some of the MIL-STD test plans and procedures I've written and reviewed, hear about some of the FATs, DT/OTs and OPEVALs I've managed, or see why they used to pay me six figures for my integration skills (now they just pay it to keep me "on tap"). I'll drop you a resume some day.

Oh and Maria - I've noticed that you have had more to say about aliens than me (seen you mention it 10 times now compared with 6 for myself) You're just fascinated with them aren't you space girl?

-- a (a@a.a), September 02, 1999.

I'm not a programmer but I play one on television (just kidding). I note that the general conversation on this thread deals with two hypothetical systems which may or may not have been tested together. The problem is that we're not looking at just two specific systems that have been or are being tested together; we're looking at many thousands of them that need to be tested together, most of them offshore and of doubtful compliance.

Is it not true that even if System A and System B have been tested and are working together properly, if Systems Q23 and W84, which exchange data with Systems Z73, T01 and L 56, which exchange with System B, are not compliant, their data can contaminate the data in System A?

-- cody varian (cody@y2ksurvive.com), September 03, 1999.

a, I'd like to see you run those circles. I too have written procs according to mil std and went even further to develop a database to do the traceability automatically. So what system requirements change as a result of Y2K? How do you build the test cases and scenarios?

Cody, But you forget the most important point of the doomer meme. It's goes way beyond just computer and comm betweent them, it's the interconnectedness. The dependence on the computers that will cause failures. So even if the interfaces that you point out are fixed (that's how extrapolating KOS simple example works), we're still doomed (a misuse of extrapolation).

-- Maria (anon@ymous.com), September 03, 1999.

Maria, why are you asking questions about system requirements changing. If anyone should know, its you, right? You're supposed to have some answers for us, not questions.

a..., please bring us up to date about system integration. If a date field is everpresent in files, file exchange etc, how the hell can computers cross talk after 01/01/00? Hoff is talking about interfaces, but where's the proof? We need PROOF that it works. Lots at stake.

Owl

-- owl (new@new.com), September 03, 1999.

"...you forget the most important point of the doomer meme." -- Maria

And this is why you are not credible, Maria. You are so entrenched in this "doomer meme" BS that you cannot possibly understand the reality of bad computer code that will fail. UNTESTED bad computer code at that.

-- King of Spain (madrid@aol.com), September 03, 1999.

Great thread people, thank you. Scoff and Mare-ia are probably very good programmers, but I've known phD's who could barely drive. It boils down to hoff's intent that his world is the rest of the world.

Forget that, risk management and all the associated headaches is necessary.

-- Will (sibola@hotmail.com), September 04, 1999.

"As a net is made up of a series of ties, so everything in this world is connected by a series of ties. If anyone thinks that the mesh of a net is an independent, isolated thing, he is mistaken...."

Buddha

-- Andy (2000EOD@prodigy.net), September 04, 1999.

"The conveniences and comforts of humanity in general will be linked up by one mechanism, which will produce comforts and conveniences beyond human imagination. But the smallest mistake will bring the whole mechanism to a certain collapse. In this way the end of the world will be brought about."

Sufi Prophet Pir-o-Murshid Inayat Khan's prophecy (Complete Works, 1922 I, pages 158-9)

-- Andy (2000EOD@prodigy.net), September 04, 1999.

Great thread.

Hey owl, KOS, Andy, guys .. I'm with you but be nice to Maria.

Maria: You are brilliant and fascinating ... Your wit and humor was not lost on this great audience just witnessing a fine debate. Great performance. Maybe that's just because my dog wasn't in this fight.

doomer/sdb

-- S. David Bays (SDBAYS@prodigy.net), September 04, 1999.