To begin with I find myself impressed with Mr. Ways articulation and seeming command of the intricacies involved in the Y2K senario. I've wondered where someone like this has been all along.

On the other hand I sense a conflict within his own perspective. I can't pin it down. There may be none at all; I'm not technically qualified or bright enough to extract the potential value of his view. I'm hoping others out there will pitch in with there opinions regarding his statements here. I'm not baiting anyone. I will continue to make those preparations of which I'm capable. I just feel we should take full advantage of the opportunity he has provided.

Believe me, I've been thankful for this forum, each of your efforts and contributions.

RUOK has provided a hot link to the thread in question. You'll find it shortly below this post, titled, Where is the Dale Way Question and answer thread? Thanks again RUOK. I wish I could do that.

You all have a good friday and weekend.

-- Rob Carroll (Flyingred@montana.com), November 12, 1999

Answers

I thought Dale Way was too complicated on his articulation. If he said someting important, I didn't uderstand it. Too bad, because IEEE should take a strong, clear point of view on embeddeds.

-- Lars (lars@indy.net), November 12, 1999.

What the Essay said to me:

No such thing as Compliancy---it being just a word used to market computers a few years ago! In fact remediation of computers will bring more problems. I find this interesting in that it tends to exacerbate an already ominous challenge to one of seeming impossibility (tower of babel comes to mind).

No set time of major malfunctions--a continuum that will have many layers of containment for those other than I.T people.

The impossible solution for testing the interconnectedness and how the whole system was never meant to be tested all at once. Coupled with his explanation of the banking system of systems and those intracacies. Also how the Stock market never tested to the back rooms. What keeps coming up in all of his essays and follow ups is a notion that the infrastructure will hold but not accounting,administration, etc.

All of his technical analysis drops to a moot point when you come to his obvious emotional statements about his own feelings. Which after all, If I am describing to you a problem Im having with my wife in technical terms because I am a technical guy, but then I end with statements like. "We are going to BURN in HELL" or another biggy--"When the SCREaming starts" or "We are going to run this ship into the iceberg". What exactly do these emotional statements say to you about the vision of One Mr.DAle Way when it comes to Y2K????

-- David Butts (dciinc@aol.com), November 12, 1999.

He's over the edge on theory. Here is another example of an innacurate and "theoretical?" response to my critique of his remarks. Here I try to introduce a real world example while countering his stand, and....well, you decide for yourself. Here it is:

(TruthSeeker) Comment 3: Case in point: I have written a very time/date dependent software program of approximately 45,000 lines of code.

(Way) Reply 3: Lets see. The average number of finished, tested and working lines of software a programmer generates a day is, and has been for the entire Computer Age, FIVE. So unless you are quite exceptional, that took you 9,000 days to write, or a little over 40 business-hour years. Wow! Thats amazing. Am I missing something here or are you just throwing numbers or achievements around like elephant dung on art?

You see, here is the problem with Way. His answer is not real world. He couldn't bust code for us at a rate of "FIVE written and tested lines per day", or anyone else with a real deadline. I'm certain his response to this will be that, "I (Way) wasn't trying to be literal".

My last comment to Way:

Incidently, Mr. Way, the aforementioned project was completed in just under three years - including data acquisition hardware. Have you knocked out even a single line of code in your career? Please give us a straight answer and don't you throw more dung on the painting.

-- TruthSeeker (truthseeker@ seektruth.always), November 12, 1999.

The fallacy in his screed is his contention that everything has to be 100% compliant and interoperable or the whole thing falls apart.

Computer systems have *never* been bug-free or completely interoperable. Probably never will be. And yet this does not stop them from interoperating correctly when they need to - when it's important.

So, 100% compliance is not required. Only those functions that require interoperation must function correctly when interoperating. That's what you need to test.

Computer networks drop packets and flake out constantly. Computers use different date (and data) formats and more variations in protocol you can imagine.

Systems of computers and systems of networks allow for this and error-check, resend, and generally manage to muddle through. That's why you can put a floppy into a Sun SPARCstation and tell it to write a file on the floppy in Windows format. It has a special program to do that - the UNIX format of the file on the computer does not have to match the DOS/Windows format the receiving computer expects.

Hence, no burning in hell, no icebergs, no screaming. Just the same old interoperability problems that have been going on for decades. And getting solved, where necessary, for decades.

Mr. Way set up a false standard that is impossible to achieve (100% compliance, interoperability, and complete real-world testing) and then based his prediction on a failure to achieve it. I think he's either a nitwit or he has an axe to grind. Probably the latter.

-- Jeff Zurschmeide (zursch@cyberhighway.net), November 12, 1999.

Jeff:

Your arguments sound fine until you include the fact that so many computers/networks/systems/systems-of-systems have gone through invasive changes all at the same time. The current system evolved. What we are looking at is what looks to me like a global IT project of an unprecedented (by orders of magnitude) proportion. Citigroup didn't stitch itself to 3500 other systems all it once; it evolved over decades. That can't happen this time.

As for DWay, I read him as follows:

(1) fundamentally honest.

(2) a little (too?) cerebral at times

(3) not inclined to explicitly draw what many feel is the obvious conclusion in a public setting

(4) possibly wrong on some of his conclusions (nobody's perfect)

If you were a 5-6 level GI -- this is a GI in my book -- and were interrogated for several hours about all your stated reasons for why you're not a 10, you would come off sounding like a polly. The collective wisdom and effort of the forum beat him like a rented mule by the end of the Q&A.

The only contentious statements were those that sounded too definitive. (I think his optimism about power, for example, seems a little misplaced.) Let us not forget what he DID question seriously.

-- Dave (aaa@aaa.com), November 12, 1999.

What we're talking about here is intellectual honesty. If you can't be intellectually honest and make it stick, then baffle them will theoretical bull s**t. I have contended for some time that we get too wrapped up in theory for the sake of real practical remediation.

Without the benefit of an exact definition of 'compliant', billions of dollars are chasing all sorts of Y2K fixes in hardware, firmware and software. That we might fail in even a very small percentage does not bode well for the interdependency of systems and sub systems. I don't really care who is more right in theory, Yourdon or Way, but I do care who will have a bigger impact on communicating the problem. Hats off to you, Mr. Yourdon, even if you too struggle with definitions. Even if Way is correct in some of his analogy, it won't matter if folks can't understand what he's saying! Perhaps that's the intent.

-- TruthSeeker (truthseeker@ seektruth.always), November 12, 1999.

Here is another example of theory attempting to overcome good judgment. Mr. Way, here you go again.

IEEE Y2K Chairman takes questions http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=001jnW

Your response to my critique:

(Way) Reply 5: The few BIOSs that may not smoothly handle the rollover can have their OS and RTC clocks reset ONCE and be fine again. I have to manually change the dates on my computer twice a year because of light savings time coming and going. It seems to me it would not be the end of the world if you had to change yours once every one hundred years.

TruthSeeker Response:

What do we do about a power off situation where the CPU is reset with the help of the RTC and bios (without getting mired in technical jargon)? Your argument above represents the perfect case scenario where no system will have to be reset/rebooted. Were that true in real life we would all sleep better.

You see, the poorest behaving bios and OS (and there are still plenty of them out there) will continue to see the two digit date string and will replicate the error at each and every bootup - assuming no remediation. e.g. 1980. (I emphasize the words "poorest behaving", fully realizing some "better behaving" bios will work after the date is set just one time.) When the software makes a call to retrieve the date, it's all over. Error trapping had better be very good.

In is in this context, that I would now like to point out the fallacy of this/your response to me: "It seems to me (Way) it would not be the end of the world if you had to change yours (computer date)once every one hundred years."

Mr. Way, that is precisely the problem. It well could be the end of the world for a chemical plant to erroneously believe that a solenoid controlled valve was turned on or turned off at a required date and time. Many real world systems are built to run more or less unattended, as is our data acquisition and control software and hardware. There will at times be no human operator to "manually" fix the date at bootup, etc. should the need arise. (As an aside: A watchdog timer cannot save the date problem per se'.) We do much fault determination in code using data passed by various analog sensors, and when the data is out of tolerance, we attempt to alert the 'human interface'. We trust the interface won't be taking a coffee break when the erroneous reboot occurs.

As for you "having to change the dates manually on your computer twice a year" to accommodate daylight savings time: Practically all new computer bios automatically adjust for daylight savings time twice a year. If yours does not, it implies it is probably outdated and should be checked for Jan 1 and Feb 29 date rollover. And that includes a test at each power up!

Finally. I am truly curious why no Y2K related articles have made the EE Times - yours or anyone elses. I try to read every issue from cover-to-cover, but I don't recall a single serious article about Y2K. I know you're not related to them, but it is curious how this has occurred. Perhaps someone can correct me if you've seen anything of note in the magazine.

-- TruthSeeker (truthseeker@ seektruth.always), November 12, 1999.

I found his essay, responses and *FLOP* (basketball term) to be very

thought provoking, inspiring, and akin to riding a unicycle. It

required balance, redundancy of logic, and the ability to change

direction without changing location.

-- Michael (mikeymac@uswest.net), November 13, 1999.

As I've indicated in other posts, reported field results suggest that some embedded systems, especially the large scale ones, may prove more troubling than Mr. Way apparently suspects. At the same time, he is right that there has not been enough publicized detail about these tests to permit scientific assessments in many cases.

Regardless, I think that his main point holds: the primary, longterm threat will come from the problems associated with large software systems and the "system of systems." The remediation effort has often lacked the understanding and coordination (and the national and international leadership) that it should have had. The consequences may indeed be serious.

We all owe Mr. Way our thanks for his having taken the time to post on this forum.

-- Don Florence (dflorence@zianet.com), November 13, 1999.

I tried reading two or three essays by Mr. Way and couldn't understand them because of the abstractions. I thought he was rather a snob. The Doomers are wrong, the Pollys are wrong, you are wrong; the Infractructure isn't going to fail but the System will surely go down.The problem isn't Jan 1, the problem is next year and the year after, however the farther we get beyond 1-1-00, the more the problem will solve itself (except for the part which destroys itself). Whaaaaatt? I think he is, like most engineers, full of horse puckey. Gary North I can understand. He doesn't write in abstractions nor in high techie language. He, like Shakespeare, addresses the universal human realities of life on the front lines. He doesn't spend time bickering with others about how many lines of code contain which macro-gizmo or how many virtual systems anaylists can dance on a SCADA or whether this type of system using this type of chip is date- sensitive or interval-sentisive, etc. Instead he addresses fear, greed, ego, stupidity and lying. The technical stuff is irrelevant when you have the ineptitude of government bureaucrats, corporate bosses and foreign petty despots overriding all. Think about all the political crap that goes on in your own organization--all the dickheads you have to suffer to get your job done, all the stupid memos which come down from the front office, all the morons you work with who will lie, cheat and falisify documents just to get a better parking space in the company lot. This is the stuff of a worldwide disaster. Dale Way's engineering abstractions don't mean squat! My Dad was a construction electrician who had dropped out of school after the 6th grade. He worked on much of IBM's initial expansion from a typewriter/adding machine factory in Endicott, NY to a national (later int'l) computer corporation. The daily bane of his existence was the engineers he had to deal with. Dad could run wire and connect it so that things worked. He constantly had to argue with engineers who had a lot of theoretical nonsense on paper and who couldn't make anything work. They had clean hands, white shirts with ties, slide rules and only the most vague idea of why the black wire was hot and the white wire was not. My bottom line is: I don't think Dale Way should be writing any further critiques of Ed Yourdon, nor of Gary North nor Jim Lord nor Michael Hyatt, nor Rick Cowles. These people have been on the firing line for 3 years. Who the Hell is Dale Way and where has he been all that time?

-- Edie Fast (skcusmaps@ghoti.net), November 14, 1999.

http://www.swrcb.ca.gov/html/y2ksumry.html Summary of YEAR 2000 Embedded Systems Issues There is a lot of material contained in these links. Quite a bit of it is redundant. Realizing that your time is limited, and you may not be able to visit each of the sites listed, this document is an attempt to summarize the key issues. * Based on experience, it takes 21 months to inventory, analyze, fix and test the embedded systems in a small to medium sized plant. * Testing of embedded chips must be done very carefully; there are instances where tests have damaged chips beyond repair. * Testing of embedded microchips can be very complex, requiring trained specialists with specialized equipment. * Approximately 10% of embedded chips have date functions. Approximately 4% of those may not be year 2000 compliant. That equates to an estimated 160 million non-compliant chips in the world. * Just because a chip does not perform a date function does not guarantee it will work properly after 1/1/2000 (date sensitive chips have been used in devices that do not perform date functions). * Just because an embedded chip works properly on 1/1/2000 does not guarantee that it will continue to operate properly after that. * There are over 30 tests that must be performed on each embedded system to ensure that it is year 2000 compliant. * Vendors of electronic devices cannot be certain that they are year 2000 compliant (therefore, all devices must be tested). * Just because one device is Y2k compliant, there is no guarantee that all other devices that have the same manufacturer, model, version, lot number, etc. will also be compliant (therefore, all devices must be tested). * A system containing numerous Y2k compliant embedded microchips (from different manufacturers) may not be compliant, because there is no date standard followed by all manufacturers. * It will not be possible to test all embedded systems and repair the non-compliant ones (therefore, efforts should be focused on the most critical systems). * It is possible that major utilities (electric, telecommunications, water, etc.) will be unable to operate for some period of time after 1/1/2000 (therefore, it is essential to have a contingency plan). * Businesses will be held legally responsible for damages caused by non-compliant embedded systems.

-- ed portillo (magnacarta00@aol.com), November 23, 1999.