IEEE Y2K Chairman's Personal, Pessimistic Take on Y2K and Yourdon's End Game Papergreenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread |
Hi,http://ourworld.compuserve.com/homepages/roleigh_martin/whatsnew.htm
Added new guest author paper by Dale Way, "IEEE Y2K Chair Personal Critique of Ed Yourdon's 'End Game' Essay";* updated list of books (including many more novels including one of the most fun and fascinating reads of the decade--Darwin's Radio by Greg Bear!**)
* http://ourworld.compuserve.com/homepages/roleigh_martin/end_game_critique.htm
** http://www.amazon.com/exec/obidos/ISBN=034542333X/theyear2000compuA/
Dale Way's paper narrows the focus of what we must worry about regarding Y2K beyond what Yourdon writes about but in my opinion, Dale Way is more pessimistic about the successful outcome of what's left to worry about than what Yourdon appears to convey in his End Game Essay.
Personally, I do not consider Way's paper, which is his individual assessment, not an official assessment of the IEEE (Institution of Electrical and Electronic Engineers), so much a critique of Yourdon's position as it is using Yourdon's paper as a stimulus, a springboard, to launch his complementary take. In other words it is not so much that Yourdon is considered wrong but that there is so much more to consider from here out regarding Y2K.
This is a very long, very important paper. If the media was to read this paper and give it notice, it would be considered very big news. This is from the Chairman of the most reputable USA engineering group Y2K committee.
By the way, I want to make it clear, that the UK peer group, the IEE, has been much more on the Y2K forefront than any other national engineering group and was out there very early on. See http://www.iee.org.uk/2000risk/
However, the IEEE Y2K papers are very blunt, honest, and critical of the pollyanna position on Y2K. The IEEE Y2K papers are significant reads in the category of great contributions along with the IEE, the Naval War College Y2K Papers and the Dept. of Commerce, International Trade Administration Y2K papers (see my Open Letter to Jesse Ventura for the links to these two papers).
http://www.wbn.com/y2ktimebomb/Tip/Lord/rmart9926.htm
--Roleigh Martin Westergaard Year 2000 Columnist, Tip of the Week (Alternate weeks)
-- Roleigh Martin (marti124@tc.umn.edu), October 30, 1999
Can some here give a direct link please?
-- Rasty (Rasty@bulldoggg.xcom), October 30, 1999.
http://ourworld.compuserve.com/homepages/roleigh_martin/end_game_criti que.htm
-- Linkmeister (link@librarian.edu), October 30, 1999.
RoleighI will check out the articles mentioned but I am just posting to say how much the information you have provided is important. You are also one of the originals on this forum to if I am not mistaken eh?
The "Whats New" link on Roleigh's site
and the IEEE Article
Subject: IEEE Y2K Chair Message to EY
Here is one of the great essays on Y2K
And a pointer towards Roleighs Y2K message board
imager@home.com), October 30, 1999.
Blew the Message board linkroleigh_for_web messages 1407-1415 of 1415
Worth checking out
-- Brian (imager@home.com), October 30, 1999.
Mr. Martin,Kind thanks for this information. I have always considered the infamous IEEE litigation report on y2k to be one of,-if not the most inflammatory pieces of documented information available to date. If anyone were to take the time and research the credibility of the IEEE and then read their reports, they would be very, very concerned at what we are ALL about to face.
In my view statements like--"100% compliance was never possible". along with,--"the interconnectedness is almost a COMMANDMENT for failure" Does not give one a feeling of----NO Problems!! quite the opposite. How anyone can refute or turn their nose up at the information that the IEEE provides is----Totally illogical!!
One can only be mystified as to the lack of concern over this technically obvious Debacle that is upon us. Totally mystified!!!
-- D.B. (dciinc@aol.com), October 30, 1999.
D.B.,I believe that its possible for one to examine Mr. Day's or the IEEE Y2k committee's report with a critical eye...I do not question the statments listed within his letter - but its important to realize that the IEEE does not perform an exhaustive search for staffing their committees. Committee members at the national and local level are selected through elections and do not necessarily represent the leading researchers or practicing engineers in the particular field. Its very similar to the debacle seen within our state and federal election process i.e., the best and brightest are not always ones who run for the govnt offices (just the ones who are motivated out of public service or self-serving reasons). Regards,
-- joe thomas (jthomas@excite.com), October 30, 1999.
Wow! That Dale paper is not written in an easily readable manner. Can't wade thru it. Sounds sorta like a big CYA, tho: do NOT, NOT, NOT blame the techies! They're only .001% of the Disaster and their miniscule part will be forgotten in the long hurricane of Y2K effects ...
-- still too sleep-deprived for serious thinking (allaha@earthlink.net), October 30, 1999.
This guy Dale just doesn't get it regarding any of Y2K. Forget his woeful misunderstanding of the Embeddeds problem...forget even business apps...
Go to the Library (as I will today to pay some late charges) and look at the Card Catalog. There isn't any. There is a computerized database. And that is it. No backup. When the system goes away, efficiency drops to a small fraction of what it used to be. And that is the County Library, a monopoly if ever I saw one.
Project this massive reduction in efficiency across the Infrastructure and it is easy to see the hit we will take.
There will be a dieoff next year.
-- K. Stevens (kstevens@ It's ALL going away in January.com), October 30, 1999.
the Cull Cometh
-- cure for overpopulation (won't@be.pretty), October 30, 1999.
Good people,I woke up refreshed and ready to focus on big reads today. Mr. Dales read is Ominous,ominous,ominious,ominous.
Anyone that does not read the entire article is unfortunately missing out on the most technically sophisticated,concise,disturbing,disturbing,did I say disturbing articles that I have ever read regarding the outcome of Y2K. Push yourself---push yourself------!!! go read the whole thing but not until you have the ability to focus and put the entire puzzle together. It is brilliant in Scope.
"". (Some agencies of the U.S. government were not being fallacious when they first said they would be ready as late as 2014. They were just being honest. Of course, that "politically unacceptable" response was quickly squelched.) It would be better for the whole world if this could be admitted. Then non-technical contingency planning would have the urgency at all levels of society it deserves""
Push yourself to read the whole thing!!!!!!! Do it!!! Not just the first couple paragraphs!!!
He specifically addresses the interconnectedness of the system that will be the death knell. Wow.
-- D.B. (dciinc@aol.com), October 30, 1999.
The author seems to be criticizing Yourdon for having arrived at the correct bottom-line conclusion by using incorrect thinking with the Y2K compliance paradigm. Looks to me like they agree on the most important thing: we face great danger, but collectively we are pretending otherwise. Re: one comment above: it could be a dangerous psychological retrenchment to hope the Y2K chairman of IEEE doesn't know his ass from a hole in the ground.My criticism of this paper (I'm not an engineer or IT person, just an observer): Way's statement, "Collectively, we are going to drive the ship right into the iceberg and not say anything until the screaming starts and then claim we did all we could to make everything compliant. We will burn in hell." seems inconsistent with his assertion that there is nothing fundamentally different about the century date rollover, relative to other phases of the Y2K continuum. For if look-ahead systems have caused little harm to this point, at what point do we begin to feel the impact of the iceberg? My guess would be within a few weeks after rollover, but that implies that I am imbuing the rollover with "magic." Although Way's paper turns my level of concern up another notch, it still fails to satisfy my search for the elusive explanation of the difference between 1999 failures and 2000 failures, as all polly, doomer, and in-between explanations I've seen have failed to do.
-- Bill Byars (billbyars@softwaresmith.com), October 30, 1999.
Mr. Byars,I agree with you somewhat,
He goes specifically into the up to, point of, look back aspects of the systems. Very technical reading and I fear that most reading it will not be able assimilate the intricacies that he obviously wishes to convey.
But reading the Statement about hitting the iceberg did it for me also as well as his critique towards the powers that be.
-- D.B. (dciinc@aol.com), October 30, 1999.
Thanks Linkmeister I really appreciate all your hard work and effort.
-- Rasty (Rasty@bulldoggg.xcom), October 30, 1999.
Excellent essay! While I am not a tech kind of person my artistic type attitude has drawn me to look at Chaos theory, Systems theory, quantum physics and Taoist beliefs. All deal with the passage of time. All have hardly been touched in the great Y2K navel gazing of the last few years.
2.2 Why We Fell Into the Independence Fallacy of Y2K
Western culture has a natural tendency to reductionism, the approach of breaking a complex problem down into smaller, simpler pieces and addressing them one at a time, handed down to us from Descartes and Newton. It is deep in our bones. How do you eat an elephant? One bite at a time. The unspoken and implicit assumption being that the pieces themselves are most important things and the relationships between the pieces are simple, uniform, consistent or not really important; in a Clockwork Universe the meshing of gears is a given and F = ma is always true. Relationships tend to go unconsidered and unexamined. (In the East, of course, it is different. The whole is considered primary and Confucian inductionism (formalized in the West by Francis Bacon) is more the norm. Harmony of the parts TOGETHER is the highest value.)Actually that is not Confucian, he tried to order social behavior without the understanding of Natural systems. That is exclusively a Taoist pursuit. But the meaning that Mr. Dale is still trying to impart is the same.
Chapter 101
In the Way there is no correct, and yet it can be used for correctness. For example, you need forests for lumber, so lumber is secondary to forest, forest is secondary to clouds and rain, clouds and rain are secondary to negative and positive energies, Positive energies are secondary to harmony, harmony is secondary to the Way.
And considering that pure Taoist beliefs are over 2000 years old it is suprising that the message they promoted is still relevant in this day and age. As Mr. Dale noted above, mankind seems to get stuck in a intellectual rut. Reductionism and determinism aren't applicable to natural order. We have core beliefs in western society which are not flexible. And natural order breaks that which isn't flexible.
Chapter 160 P. 160 -161Those who know where laws come from adapt them to the times, those who do not know the source of ways to order may follow them but eventually wind up with chaos. Scholars nowadays practice their work routinely, holding books in their hands and watching out for rules of grammar, wishing to effect social order by this means, Is this not holding onto a prescription that has failed to cure, or putting a square peg in a round hole? It will be hard to get the right fit.
To sustain the imperiled and bring order to chaos is not possible without wisdom. As far as talking of precedents and extolling the ancient is concerned, there are plenty of ignoramuses who do that. Therefore sages do not act upon laws that are not useful, and do not listen to words that have not proven effective.
We will hope that Mr Dale is wrong. But I doubt it.
Chaos demands respect whether we like it or not.
-- Brian (imager@home.com), October 30, 1999.
That should be Mr. Way not Mr. Dale.
-- Brian (imager@home.com), October 30, 1999.
As a card carring, dues paying member of the IEEE I wish that the National Board would endorse this essay and post it on their web site. It has a unique and forboding findings worry me alot.Clearly we will not be through the worst of it at the Roll Over, it will just be the begining. I just hope enough systems make it through to make a core to rebuild from.
Things will get worse before they get better......
-- Helium (HeliumAvid@yahoo.com), October 30, 1999.
Taking a break from working and decided to browse the forum. MR MARTIN -- THANK YOU!!! for posting this essay. I would probably have missed it otherwise. An excellent read.Mr. Way -- Should you read this, thank you for the essay. Your analysis of the time problem *alone* was worth the effort!
All -- READ THIS ESSAY! I am going to take the time to go back and insert the title of this thread into each post I have made, in hopes that some who might not otherwise hit upon this thread are made aware of it and may take the time to go over it.
Be aware, this essay is not a 'slam' at Ed Yourdon, or I, at least, do not see it that way. At worst, he is taking Yourdon to task for not going far enough and for eliding over certain aspects of the situation as they do not pertain to the 'purely technical' side of the issue. For instance, he mentions the policies, people and processes as parts of the whole which are being woefully neglected. And he is 100% correct. We in the industry all have a tendency to believe that if we could just make the hardware, firmware, clocks, software, systems, databases, or whatever our little piece of the pie is work right we could get by it. We are blinded by our own tasks to the point of ignoring the things that go into it.
While reading this article, I was dumbfounded to realize that a piece of a process that I was instrumental in defining *WILL* fail come next year. AND I WAS BLIND TO IT! And this is if all the equipment works! I guess it is proof of the old saying 'There are none so blind as those who WILL NOT see.'. I suspect that a whole lot of us suffer, to one degree or another, the arrogance which is what annoys most of us on this forum about individual posters such as 'The Engineer', or Shuggy, or Cherri. It is endemic to our profession, they simply evince it to a greater degree than others. (There are reasons why our profession attracts this sort of personality type.)
This essay expresses many things which I knew peripherally, and others which I suppose I should have realized, but did not, whether because I chose to ignore that which I didn't think I could affect, or I didn't want to think about them.
One other point. As to the 'burn in hell' remark, if you think back, you will likely realize you have heard that sentiment expressed, in one form or another, by many of the more thoughtful technical posters to this forum. In particular some of the ones whose experience goes back aways. This is one area where I am ambivalent toward the essay. In retrospect, there really wasn't anything positive that most of us could have done to have prevented this mess. And taking a load of personal blame for that which we might have, could have, should have done, in the face of overwhelming opposition, is probably counterproductive, at least.
But again, I emphasize, READ THIS ESSAY!!!
-- just another (another@engineer.com), October 30, 1999.
I don't have time to give the Way critique the treatment it deserves, as this is a working weekend for me. I will say this much:1) This is a perfect companion piece to the IEEE Open Letter to Congress, in that it seeks to defect criticism/responsibility from the engineering community for problems related to Y2K. As an engineer myself, I suppose I should support this position, but, truth told, I find it a little unseemly. But that's just me.
2) By my reading of Way's words, he is of the opinion that all remediation efforts have been a waste of time, and that all efforts should have been directed towards contingency planning. This, frankly, strikes me as foolish. Way believes that, because of the interconnectedness of systems, remediation of independent chunks of a given system won't work. That might be true if Y2k required significant redesign of the interfaces between the chunks - but it DOESN'T! Each chunk merely needs to process its little '00' correctly (yes, INDEPENDENTLY), then pass it on THRU THE EXISTING INTERFACE to the next chunk. And, as I've said before, those interfaces are being field-tested RIGHT NOW. Anyone wish to debate this?
3) A quote from Way: "Y2K problems or failures do not necessarily mean system failures. System failures do not necessarily mean business function failures. Business function failures do not necessarily mean business or economic failures. There are many levels of containment that work to keep any problems from becoming things that actually impact people in a way that matters to them."
As I've always said. As Mr. Flint has been saying on this board for months/years.
4) Another quote from Way: "After that point, the Forward-Only looking applications WILL ALL BE INTRINSICALLY BE SAFE. This includes the operational control of virtually all of the dreaded, Chicken Little-ish "embedded chip" world.
Apply this to recent embeddded chip discussions...
-- RC (randyxpher@aol.com), October 30, 1999.
RC - I suggest you go back and read Way's atticle again. You are like all pollies, can't see the forest for the trees.
-- ReadingClosely (1234@788ii.com), October 30, 1999.
RC --I believe that the essay stated that we are looking at the problem ONLY from the 'let's fix the hardware' perspective. And in that, I think he is probably right. Not saying that all remediation was foolish or futile, just that we should have realized it wasn't enough in and of itself. (Think process, policy, and the people involved.)
And the point about containment levels is correct. There are several. However, if you give your statement about 20 seconds of thought, you will realize that a lot of organizations are not doing interface testing. (Remember that AT&T tested their stuff in isolation, saying it would be too difficult and time consuming to test with all the third party add-on folks.) I can attest to at least one other segment that isn't concerned about interface testing. And I have worked for all too many organizations who felt that Interface Control Documents were a waste of time, and even if one was created, it wasn't kept up. (I know this for a fact, in that I got later contracts with them, and even though ICDs were created on the initial project, their last entry date was the last time I looked at them. Most bore no relation whatsoever to reality as it existed at the time of the new contract.)
Now, lets do apply it to the dreaded, chicken-littlish discussion of 'embedded chips'. As I pointed out in a reply above, his discussion of date applications is well done, and probably as good as can be made without bogging down in technical jargon. And yes, embedded chips, for the most part, resemble a discontinuous event, i.e., one that occurs once, all at the same time.
But even he pointed out that there were exceptions. True, mostly older chips, many no longer manufactured, all obsolete, (although, I saw an application just recently that was using chips from 21 years ago, shipped as new, even though I cannot imagine where in the world they could possibly be getting a supply of these). And these are some of the ones that really bother me. I do not know, NO ONE knows, where all of them are. And no one can say what applications they are used on. Or how good their programmers were. Or even how much anyone really cared, since the chips themselves would be obsolete in 4 or 5 years and we all KNEW this, KNEW IT FOR A FACT! We were told this by our managers, by the vendors, by the clients, and by each other. Even if EVERYTHING else where the high-end 'embedded' applications that Shuggy was talking about on an earlier thread, these 'older' chips would be the wild-card. And, as I said, I saw a new 'low-end' app being shipped with stuff I thought was gone 15 years ago.
-- just another (another@engineer.com), October 30, 1999.
Very technical article. But a "must read". I'm about speechless.
-- Pam (Yikes@omigod.com), October 30, 1999.
I'm not trying to be critical, but I'm curious as to why you people put so much stock in the opinion of someone who is from the electrical engineering/embedded systems side when he speaks about mainframe problems.Certainly we don't hold Cory Hamaski's opinion on the fate of embedded systems as the standard for things to come. Heck, Mr. Hamasaki himself plays down his knowledge on the issue. What makes everyone think Mr. Way has special knowledge when it comes to mainframes?
And wasn't the IEEE criticized heavily for being late on taking an official stance on Y2k? I believe both Dick Mills and Rick Cowles had concerns about their tardiness in taking a public position on Y2k.
-- Buster Collins (BustrCollins@aol.com), October 30, 1999.
OK, I have read Dale Way's paper now, real slow, darn near every sentence, and I think I "got" 65 percent of it. Not a techie here AT ALL. Plan to go back and read it all over again, twice as slow.Could somebody please explain to me in a concise and clear way (number them, maybe?) what are some potential scenarios that could arise when considering the problem from Mr. Way's perspective? How, for instance, might refineries, utilities, supermarkets, delivery systems, etc. react under these circumstances, considering this theory, and how long might it take to fix what...?
Someone please translate this into real life strategies and dilemmas. As best that can be done, in theory, of course.
-- (normally@ease.notnow), October 30, 1999.
PS With this theory, I am having trouble trying to fit the Titanic in with the icebergs ...
-- (normally@ease.notnow), October 30, 1999.
Buster,As I sit here getting ready to respond to your post. I find myself at a loss for words in grasping how anyone could read that essay with the pertainent information and not come to the most profound conclusion that this technical problem of Y2K is alot more serious than 99% of our society even realizes.
Why would anyone hold suspect the messenger of information as informative and enlightening as Mr. Mays??
Just curious!!!
-- D.B. (dciinc@aol.com), October 30, 1999.
Yes, D.B., Y2k is a profundly serious problem. No, I do not necessarily doubt Mr. May's treatise. But I can remain suspect at the same time. It seems that he shifts the ubiquity of the problem away from embedded systems and towards mainframes. Some have concluded that mainframes are in fact the real bugaboo of Y2k, along with databases. Maybe, maybe not.But does not IEEE's primary focus and task center on embedded systems? And if it does, cannot this be viewed as a deflection of sorts? I think it can, but I'm not certain. So, I suspect the source until I'm satisfied to the contrary. It's the product of a skeptical mind. It's not meant to be a put-off.
To me, embedded systems have always been the issue. We are told they are difficult to find; therefore it's reasonable to conclude they are also difficult to replace. So Fix on Failure become a challenge, even for the few that cause problems. This is the danger to me. But then, danger is danger, no matter the form.
-- Buster Collins (BustrCollins@aol.com), October 30, 1999.
This essay has given me a sense of clarity. The pieces were there but were never fitting properly. I "knew" but did not fully understand.I hate being dragged, kicking and screaming, back to reality. The trouble is that the reality may be worse than I thought.
-- frog (stillhere@waiting.com), October 30, 1999.
It was refreshing to see someone kick the embeddeds in the ass and proceed to the real problem, which is the interconnect-edness and the interfaces of the large systems. Unfortunately, I am more worried that before.dave
-- dave (wootendave@hotmail.com), October 30, 1999.
2) By my reading of Way's words, he is of the opinion that all remediation efforts have been a waste of time, and that all efforts should have been directed towards contingency planning. This, frankly, strikes me as foolish. Way believes that, because of the interconnectedness of systems, remediation of independent chunks of a given system won't work. That might be true if Y2k required significant redesign of the interfaces between the chunks - but it DOESN'T! Each chunk merely needs to process its little '00' correctly (yes, INDEPENDENTLY), then pass it on THRU THE EXISTING INTERFACE to the next chunk. And, as I've said before, those interfaces are being field-tested RIGHT NOW. Anyone wish to debate this?RC,
If by "independently" you mean that the two sides of the interface do not need to come to explicit agreement on how to represent the year 2000, that I would debate. Adding the treatment of the year 2000 to an interface is a change to that interface, even if this changes neither field size nor type. How to treat the year 2000 has to be explicitly discussed because there are several options, such as doing nothing (i.e., fix on failure), using "00" to represent the year 2000, or using 4-digit representation of year.
With regard to interface testing, the biggest concern I have is with virtual interfaces. (By "virtual interface," I mean where two systems that do not interface directly, still pass data to each other via a series of interfaces involving other systems. Example, if System A feeds System B, and it in turn feeds some of this data to System C, System A would have a virtual interface to System C.) The greater the number of systems in between the the ultimate source and the ultimate destination, the less likely that the two parties are even aware of each other's existence. A manager is unlikely to have the breadth and depth of expertise to recognize that designating System A as non- mission critical may hose a mission critical system to which it has a virtual interface. I have not read Way's paper, but perhaps he visualizes a scenario like this.
-- David L (bumpkin@dnet.net), October 30, 1999.
This one is a keeper. The article in effect demonstrates that the computer industry did not have adequate standards in the beginning and it grew like topsy. Where would we be if the manufacturing industry did not standardize thread dimensions and wrench sizes for bolts and nuts, wrenches etc.? It would be a disaster trying to build or fix a car. Simple things like month, date year, or date month year, year, month day, 2 digit or 4 digit year were not though through and standardized.One point in his article that is easy to grasp is the fact that the only real problem is when a date critical function has to cross the century boundary either way and for example a home computer will work fine if you reboot it January 2000 and never look back to dates prior to 2000. The flip side is that efforts to fix code could have made the problem worse if they created other problems and there was no date critical function. He also explained how fixing some code could cause problems interfacing with other programs in the same company or in other interconnected businesses (BANKS COME TO MIND). That part is scary. The banks are compliant but this does not mean anything as compliant or non compliant does not address the main problem which is whether or not both ends of the computer connection can correctly process date functions (SUCH AS INTEREST RATES). Why did it take the industry so long to figure this out and to spend 5 years trying to get compliant when being compliant will NOT solve the problem?
He also clarified another concern about embedded systems. If there is no date calculation across the century boundary, the embeddeds will work fine. This causes a new worry on pipelines, natural gas transmission facilities, electrical power distribution systems where product flows per second will be measured to help calculate billing for the quanity of product delivered. This could be a one time problem for each system at the rollover and then it would be O K if there is no lookback into 1999. What happens if many of these systems shut down at the rollover? There is some logic to the fix on failure plan if they can survive the rollover and identify and obtain the needed parts with the systems shut down. If they know that there are date calculations that will cross the century line, this strategy appears somewhat foolish.
Thank you Mr. Way for an outstanding article. I did not interpret this as an attempt to defend or criticize anything, he was attempting to present a new analysis that would try to explain some of the problems that have not yet been identified and fixed. His comments that compliant computers could still screw up calculations and that noncompliant computers could work O K depending on whether or not the calculations crossed the century date were especially enlightening. I wonder how many computer experts realized that before his article was written?
The whole industry is built on a foundation of sand in my opinion.
-- Larry (Larry@3stooges.gom), October 30, 1999.
if I may, please:1) well done! MUST reading; cogent and concise
2) slightly sarcastic, but Ed is a big guy - and any can take their own tangent on things
3) it IS the 'interconnectednesses' that may do us in
4) looks like Infomagic may have had it right all along! I'm not surprised
5) makes Cory H. sound like a poly!
6) apparantly, the code CANNOT be fixed; or WILL not be fixed [in time]
7) if one ever had any doubt as to the reality of this mess, this essay should remove that doubt
8) more beans and Spam...
9) to all, those whom I know and those whom I do not, 'believer' and 'unbeliever' alike, my best to each of you
-- Perry Arnett (pjarnett@pdqnet.net), October 30, 1999.
Thanks Perry,I got the same feeling after the read.
Very sad indeed.
-- D.B. (dciinc@aol.com), October 30, 1999.
If you can honestly read this and still NGI then....snip-
by Dale Way Chairman of IEEE Y2K
If an organization goes off half-cocked, without complete, detailed knowledge of how its system of systems works altogether in all normal and possible abnormal situations, as the vast majority of remediators have done, yet make wholesale changes as if it did have that knowledge, they are doomed to failure unless it had many more years than the three of four most organizations have been at it. (Some agencies of the U.S. government were not being fallacious when they first said they would be ready as late as 2014. They were just being honest. Of course, that "politically unacceptable" response was quickly squelched.) It would be better for the whole world if this could be admitted. Then non-technical contingency planning would have the urgency at all levels of society it deserves. But technical management and the Y2Klatura collectively do not have the brains or the guts to do that DEFINITIVELY. We will hew to our baseless confidence or pussyfoot around the obvious until the end. Collectively we are going to drive the ship right into the iceberg and not say anything until the screaming starts and then claim we did all we could to make everything compliant. We will burn in Hell.
3. EPILOG
If this sounds harsh, it is only what history has in store for us, the self-appointed Y2Klatura. For we have taken it upon ourselves to define the problem and the solution. We have allowed or encouraged civilians to believe we knew how to handle it. We have buried our own doubts or mealy-mouthed them to the extent we allowed others to believe what was most comfortable for them. Though we have often ranted, we have allowed apologists and scare-mongers to each have their audience. We have given little to leaders that they can use on their terms in their world. We ourselves have been wrong about much. We have not examined ourselves nearly as much as we are demanding others examine themselves. We, too, have believed our own PR. It is time to make amends and do more to undo the damage we have inflicted. Until we do that we cannot expect others to trust us. Rollover/End is a dangerous anthropomorphism that mischaracterizes and misdirects, Compliance the siren song that calls us to the rocks. Other concepts more firmly grounded must be embraced. Other things more firmly grounded must be done.
FOOTNOTES
* By Senator Slade Gorton (R-Washington). He also said of it : "The memorandum is so good that rather than simply have it printed in the Record, I will read it," and he read almost all of it in its four-page entirety on the floor of the Senate. You can find Sen. Gortons comments and the complete memorandum at the IEEE site: http://www.ieee.org/organizations/tab/Y2Kfocus.html
** By Marc Pearl, General Counsel of the Information Technology Association of America (ITAA).
*** Y2Klatura is a take-off on the parasitic Soviet Nomenclatura, the upper-level apparatchics of the Communist Party who acquired power, status and privilege in a ideological, non-merit system where loyalty to the Party was the highest value.
END
Well then....
60 days
"The end of the beginning" - Churchill
The tertiary phase.
Realization, acceptance and panic.
God help us all!
End well my friends!
Respectfully Michael
-- Michael (mikeymac@uswest.net), October 31, 1999.
A very impressive paper. The BIG PICTURE. My take on what this paper represents: many,many,many,many years of Y2K problems, no end in sight kind of problems.I think instead of thinking in terms of a problem that will be intense and then eventually go away, we probably should start thinking of Y2K as a problem that will never go away.
Practically speaking, in light of this paper we should become as self-reliant as possible ( food, electricity, water ) and always have a good stockpile of neccesary items.
-- Stanley Lucas (StanleyLucas@WebTv.net), October 31, 1999.
Execellent essay, thank you Dr. Martin. I agree that this paper is a furthering of Ed Yourdon's essay. What struck me here was the literate discussion of the process to discover and fix and test, the interconnectedness of systems hardware, software, database, new and old all of the above. It gets back to the issue of a chronic, long term malaise that Bill Ulrich, Lane Core, and on and on have written about.Blaming someone would be nice and I expect we will be rounding up the usual suspects before this calms down. (I am in the 4-6 category with my fingers crossed). When you take this essay with some of the work written by Capers Jones, it is clear we are in for quite a ride. The hardest thing for me to deal with is the continued lack of clarity on the part of public and private institutions. Naive fool that I am.
I attended an investment conference on Friday in San Francisco (received freebie tickets due to Investors Business Daily subscription) and attended a Y2K luncheon with a panel discussion whose members ranged on the doomer polly scale from Howard Ruff to Harold Brown, the former Libertarian party candidate for president (I may have mis written his name due to an intentional effort to dump that piece of information from my brain). I also found myself a lot closer on the continuum with Mr. Ruff.
I kept hearing this Mr. Brown talk about the high mindedness of corporate America and how they would not intentionally deceive the sheeples. Guess I am getting cynical, but after seeing what happened to IBM from Gerstner's comments about a delay in orders, the lying/misinformation etc will continue in earnest to segue into fingerpointing.
thanks for the article
-- Nancy (wellsnl@hotmail.com), October 31, 1999.
From Mr. Ways' letter:"(This is why a PBS television show in October on Y2K to which I contributed will be called 'The Winter of Our Disconnect.')"
I didn't follow the names very well in Robert X. Gringely's show. Was this the IEEE fellow Gringely was interviewing? If so, then "very interesting."
-- Buster Collins (BustrCollins@aol.com), October 31, 1999.
Nancy,I do believe there was a minor error in your post - Roleigh Martin does not possess a PhD. His CV lists an Masters of Arts - cannot remember the related field that he earned the degree in...Regards,
-- James Anderson (janderson12@yahoo.com), October 31, 1999.
Another comment on Way's statement, and some comments on comments:1)"If an organization goes off half-cocked, without complete, detailed knowledge of how its system of systems works altogether in all normal and possible abnormal situations, as the vast majority of remediators have done, yet make wholesale changes as if it did have that knowledge, they are doomed to failure..."
This is the central point of Way's essay, and I disagree with it totally. For starters, "complete, detailed knowledge" of the workings of the macro "system of systems" in all possible situations is impossible. That Way correctly dismisses the concept of "compliance" (which is, after all, complete, detailed knowledge of the workings of INDIVIDUAL COMPONENTS in a system in all possible situations), and then demands the same understanding of the macro system is inexplicable.
Secondly, I don't see how Y2K remediation fits the description "wholesale changes". Individual Y2K code changes are, by definition, trivial. Further, all the collective Y2K changes are aimed at making the system component work EXACTLY LIKE IT DOES TODAY. Systems are not being redesigned - I don't think this qualifies as "wholesale change" by anyone's definition.
2) "I believe that the essay stated that we are looking at the problem ONLY from the 'let's fix the hardware' perspective."
Well, I'd say it's 'let's fix the software', but OK.
"However, if you give your statement about 20 seconds of thought, you will realize that a lot of organizations are not doing interface testing. (Remember that AT&T tested their stuff in isolation, saying it would be too difficult and time consuming to test with all the third party add-on folks.)"
Outside interface "testing" is another practical impossibility for most organizations. But nobody's waiting until December 31 to field their remediated software - ours has been in the field for over a year. That's what I mean when I say that interface testing is going on now - if an interface gets screwed up, it'll be evident long before rollover.
3) "If by "independently" you mean that the two sides of the interface do not need to come to explicit agreement on how to represent the year 2000, that I would debate. Adding the treatment of the year 2000 to an interface is a change to that interface, even if this changes neither field size nor type. How to treat the year 2000 has to be explicitly discussed because there are several options, such as doing nothing (i.e., fix on failure), using "00" to represent the year 2000, or using 4-digit representation of year."
An interface is the definition of the data layout for information being passed from one system to another. The "treatment" of "00" by a given system is immaterial. The interface only changes if you expand from 2 to 4 position year, or move the location of the date field within the layout. Do either of these without consulting with systems downstream, and you richly deserve the consequences.
4) "He also clarified another concern about embedded systems. If there is no date calculation across the century boundary, the embeddeds will work fine. This causes a new worry on pipelines, natural gas transmission facilities, electrical power distribution systems where product flows per second will be measured to help calculate billing for the quanity of product delivered. This could be a one time problem for each system at the rollover and then it would be O K if there is no lookback into 1999."
Well, embeddeds are hardly my strong suit, but I'll ask a couple of questions for anyone who might know:
A) When you're talking about a flow measurement system, is there a reason why the embed's internal clock would need to be synched to EST, or whatever? It would seem to me to be unnecessary, plus a giant pain in the ass to adjust if it drifted off real time. And if it's not synched, then the embed's eventual rollover has no relation to Jan.1, right?
B) Onetime rollover problems can be missed entirely by shutting down the sytem during rollover, which is exactly what a lot of companies are planning to do. Is there a reason I'm missing as to why this won't work?
-- RC (randyxpher@aol.com), October 31, 1999.
Regarding Dale Way's discussion of "time-shifting" or "time emulation":"If all the components are "non-compliant" or simply unremediated, incoming date data can be captured and "time-shifted" back into a virtual 20th Century (with and clock settings reset back compatibly) and output data time-shifted forward into true calendar time for data storage and export, keeping the system "current" relative to others."
(snip)
"Time emulation is a faster approach to Y2K safety than traditional methods that seek "compliance" at the component and subsystem level because it mostly takes place external to operational systems themselves, no matter how widespread, encompassing or inclusive is the definition of what constitutes the "system.""
(snip to end)
Such an approach would appear to be problematic with any system which includes data bases which retain date information which is used in conjunction with incoming data.
Jerry
-- Jerry B (skeptic76@erols.com), October 31, 1999.
An interface is the definition of the data layout for information being passed from one system to another. The "treatment" of "00" by a given system is immaterial.Are you saying it's OK for the sending system to populate "00" to represent the year 2000 and for the receiving system to interpret "00" as representing the year 1900 (or any other year but 2000)? I don't see how considering semantics to be outside an interface definition precludes having to understand what the data being passed means.
-- David L (bumpkin@dnet.net), October 31, 1999.
I read the article twice! Great job.My take on it as a simile
A guy goes to the doctor. The Dr. asks what's the problem. He says I've got a fever...the Doctor says quick take these asprin. He does, then says I also have a stomach ache. The doctor gives him some medicine for that. He says but I also have high blood pressure, the Doc gives him medicine for that. The man gets dizzy, falls on the floor dead.
The nurse comes in and says "what happened?" The doctor says "He died..I think it was something he ate. He should have came to me sooner"
Evaluate the patient thoroughly before prescribing medication.. you might be the cause of his death.
of course, maybe I'm wrong.
-- bob brock (rbrock401k@aol.com), October 31, 1999.
Pam: Do you like to mudwrestle?
-- King of Spain (madrid@aol.cum), October 31, 1999.
Like some others have said, this paper requires a second read, it is not written in an optimum fashion, but I think I get the gist of what Mr. Dale is trying to convey.K. Stevens said: "This guy Dale just doesn't get it regarding any of Y2K....Project this massive reduction in efficiency across the Infrastructure and it is easy to see the hit we will take."
From what I get K., I disagree with your statement that he doesn't get it, on the contrary. What you seem to be telling us by what is "getting it" is what I would term Infomagic's bird eye-view, i.e. "Macro-interconnectedness". Mr. Dale's paper appears to me as a complimentary in-depth bird's eye view to Infomagics at the "Micro-interconnectedness" level.
Infomagic and Mr. Dale both seem to grasp this "harmony of the parts together" that Dale refers to in his essay, each complementing one another in their understandings of interconnectedness.
To me, this paper is as facinating and as depressing as Infomagic's. I can't believe I'm really awake sitting here discussing it. It feels so unreal.
-- Chris (#$%^&@pond.com), October 31, 1999.
K. Stevens:I gotta go with Chris on this one. Dale is a super-doomer, just as you are. At the end of section 2.2, he states, quite clearly: "Collectively we are going to drive the ship right into the iceberg and not say anything until the screaming starts and then claim we did all we could do to make everything compliant. We will burn in Hell." Pure doom.
I do agree that he gives the embedded issue short shrift. Essentially, he says that they will only have problems right at their rollover, if they do a forward and backward looking calculation. This seems to be at odds with much else that we have heard, especially Frautshi's work (http://www.tmn.com/%7Efrautshi/y2k2.html). On this score, you may be right. He brushes it off with nary a word about what the consequences might be, even if he is right .
Other than the above, I think you and I are in complete agreement.
Godspeed,
-- Pinkrock (aphotonboy@aol.com), November 01, 1999.
I said - "An interface is the definition of the data layout for information being passed from one system to another. The "treatment" of "00" by a given system is immaterial."David said - "Are you saying it's OK for the sending system to populate "00" to represent the year 2000 and for the receiving system to interpret "00" as representing the year 1900 (or any other year but 2000)? I don't see how considering semantics to be outside an interface definition precludes having to understand what the data being passed means."
I say - No, I'm not saying that's OK, I'm saying it's not an interface problem. And more importantly, I'm saying that it's a problem that can only be solved by the remediation of the recieving system, which is just the sort of micro-solution that, according to Mr. Way, won't work.
Frankly, the more I read over the Way essay, the more I disagree with what he's saying (his conclusions, at least).
-- RC (randyxpher@aol.com), November 01, 1999.
http://www.garynorth.com/y2k/detail_.cfm/6663 Gary North's Y2K Links and ForumsCategory: Noncompliant_Chips Date: 1999-11-01 05:47:49 Subject: Big Problem, Continuing Problem, Not Merely a Technical Problem, Says Expert Link: http://ourworld.compuserve.com/homepages/roleigh_martin... Comment: Dale Way is the chairman of the Year 2000 Technical Information Focus Group, Technical Activities Board, The Institute of Electrical and Electronics Engineers (IEEE). His organization has published many items on y2k and embedded systems. Generally, these reports have been possimistic, though not apocalyptic. Here he responds to an essay by Ed Yourdon, "End Game." He explains that the chip problem areises when two dates must be compared across the centuries. This is not all the time. Sometimes the repair can be done manually be re-setting the system's clock. But because there may be (will be) reprated cross-date comparisons, one fix is not enough. The key issue of embdeded chips, he says, is duration, not simultaneity. ". . . this intrinsic risk will last a long time across a wide swath of our information system infrastructure." When considering the real concerns of Y2K to society as mentioned above, it is not so much the number of system element failures. It is their duration that poses the largest threat; their Mean Time To Repair (MTR). It is in longer duration failures that the breach of containment and the probability of cascading failures of other elements, technical and economic, rise in an exponential-like fashion. We could tolerate a lot of failures if they lasted only a short time. If your phone service is out for a minute, you might not even notice it. If for an hour, it may be an inconvenience. (If it was out for a critical hour when some important call was supposed to take place, that could hurt, but again, thats a probability game.) If it was out for a day, that could very well hurt your business. But if it was out for a month or six months, you would be in serious trouble in many ways, and if the outage was widespread, so would many other people and institutions. He thinks the problem will continue way beyond the first weeks of 2000. These problems will not be merely technical. They will be institutional. Y2K problems or failures do not necessarily mean system failures. System failures do not necessarily mean business function failures. Business function failures do not necessarily mean business or economic failures. There are many levels of containment that work to keep any problems from becoming things that actually impact people in a way that matters to them. And most of these containment layers and efforts are outside of the domain of Y2K remediation efforts. As this non-technical realm is a battleground that will engage many employees in almost all organizations directly or indirectly, and most people as individuals and families, not just us techies, and because the battle is likely to take many years to be decided, it is the ultimate reality of Y2K. So, business managers and other "civilians" (he uses this word) who take heart on January 1 that systems have not shut down will be playing a fool's game. Jamuaty 1 is "the end of the beginning," as he quotes Churchill. I am not technically competent enough to say whether his assessment is correct, although I think it is. I will say this: if he is correct, then business efficiency will drop next year. Operations will become unpredictable. This will affect corporate earnings negatively. Cash flow will drop from firms experiencing difficulties, and net revenues will drop ever more. This will have negative effects on the stock market, which is driven today by a combintation of fiat electronic money, wild investor optimism, and an expected stream of earnings to support this optimism. He ends with this grim assessment -- rather like a biblical-era prophet: If an organization goes off half-cocked, without complete, detailed knowledge of how its system of systems works altogether in all normal and possible abnormal situations, as the vast majority of remediators have done, yet make wholesale changes as if it did have that knowledge, they are doomed to failure unless it had many more years than the three of four most organizations have been at it. (Some agencies of the U.S. government were not being fallacious when they first said they would be ready as late as 2014. They were just being honest. Of course, that "politically unacceptable" response was quickly squelched.) It would be better for the whole world if this could be admitted. Then non-technical contingency planning would have the urgency at all levels of society it deserves. But technical management and the Y2Klatura collectively do not have the brains or the guts to do that DEFINITIVELY. We will hew to our baseless confidence or pussyfoot around the obvious until the end. Collectively we are going to drive the ship right into the iceberg and not say anything until the screaming starts and then claim we did all we could to make everything compliant. We will burn in Hell. 3. EPILOG If this sounds harsh, it is only what history has in store for us, the self-appointed Y2Klatura. For we have taken it upon ourselves to define the problem and the solution. We have allowed or encouraged civilians to believe we knew how to handle it. We have buried our own doubts or mealy-mouthed them to the extent we allowed others to believe what was most comfortable for them. Though we have often ranted, we have allowed apologists and scare-mongers to each have their audience. We have given little to leaders that they can use on their terms in their world. We ourselves have been wrong about much. We have not examined ourselves nearly as much as we are demanding others examine themselves. We, too, have believed our own PR. It is time to make amends and do more to undo the damage we have inflicted. Until we do that we cannot expect others to trust us. Rollover/End is a dangerous anthropomorphism that mischaracterizes and misdirects, Compliance the siren song that calls us to the rocks. Other concepts more firmly grounded must be embraced. Other things more firmly grounded must be done. Because this is a long essay, I have placed parts of it under other categories: "compliance" and "testing." But it can and should be read as a unit. This is a very important essay. My one complaint for Mr. Way, who wrote another lengthy important essay in early 1998, is this: he waited to long. This should have been available in 1995. I will await the response of Mr. Yourdon, to whom it is directed, and Mr. de Jager, for whose new-found pollyanna position -- not supported by either facts or logic -- this essay seems fatal. I suspect that Mr. Yourdon will offert some version of "thanks for the clarrification." Mr. de Jager, I prredict, will not say a word, and if he does, it will not deal with the points raised by Mr. Way's essay. Go ahead, Peter. Respond. Make my millennium. This is posted on Roleigh Martin's site. It has an October 28 date. * * * * * * * * * * * * This critique attacks some of the most sacred pillars of Y2K orthodoxy. As the century comes to a close with there being very little sense of success in the air, Im hoping that the minds of people in the Y2K industry and other interested parties may be open for new insight. It is not too late to make adjustments. Unfortunately, Y2K is not about to be over. At best, to paraphrase Churchill, it is the end of the beginning. . . . 1. THE USE OF THE END GAME METAPHOR AND THE ROLLOVER FALLACY OF Y2K While useful to convey your sometimes illuminating ideas, the metaphor of the End Game implicitly identifies the pre-2000 TECHNICAL PREVENTION PHASE of Y2K as the WHOLE game. Although the end-game metaphor sometimes refers to a project at the application level, sometimes to an organization and sometimes to a multiple-entity super-organization like GM or the U.S. government in the essay, it seems to always mean the end of "Y2K projects" for that entity or level. The technical prevention phase (such as it is) is not by any means the whole game. It is not even the most significant, I contend. Making it so distorts reality in a fundamental manner, puts technologists alone on the hook (a place we really do not want to be, trust me) and invalidates and undermines the greater efforts facing society as a whole. When looking back from twenty years in the future, Y2K will be seen to have been much more about this succession, this chain of events: 1. The effects of any system failures (founded on the inability of the people involved to prevent ALL Y2K system failures) 2. An organizations ability (or inability) to contain the effects at the intra-organizational level with manual procedures (or procedural/technical hybrids) or policy workarounds 3. A group of organizations ability (or inability) to contain the effects of their inability to do the above and any resulting economic impact at the inter-organizational industry sector- or horizontal supply chains/vertical support service chains-level by adapting policies, procedures and relationships effectively 4. A group of organizations and governments ability (or inability) to contain the effects of our inability to do all of the above at the inter-organizational, international, governmental and private global institutional-level by adapting procedures and relationships effectively 5. The resulting direct and indirect economic and physical damage due to societys collective inability to do all of the above. 6. The recovery of the information system infrastructure 7. The recovery of the economic and social infrastructure Y2K problems or failures do not necessarily mean system failures. System failures do not necessarily mean business function failures. Business function failures do not necessarily mean business or economic failures. There are many levels of containment that work to keep any problems from becoming things that actually impact people in a way that matters to them. And most of these containment layers and efforts are outside of the domain of Y2K remediation efforts. As this non-technical realm is a battleground that will engage many employees in almost all organizations directly or indirectly, and most people as individuals and families, not just us techies, and because the battle is likely to take many years to be decided, it is the ultimate reality of Y2K. Y2K technologists self-centered definition of "our" part as the whole thing is misleading and is likely to allow the subsequent dropping of the whole thing into our laps as the scapegoats/fall guys when that is by no means deserved. Your metaphor encourages this misunderstanding. There will be failures. No doubt about it. A code verification consultancy I am familiar with is saying that the code that they get that has noticeable problems (about 75% of the total of 800 million lines they have reviewed with their tools; only 25% is clean) they are finding about 28% more dates than their clients thought were there; a frightening statistic when considering this is only the most basic task of any kind of remediation. There are many levels of tasks and challenges beyond this that can go wrong. If the foundation is so weak, what the state of the structure standing on it? The failures will nonetheless be mostly intermittent. The wholesale and permanent collapse of significant systems, although possible, is unlikely for a number of reasons. The failures will most occur along the boundaries of organizations and what are generally considered separate systems, although due to data sharing are actually not, the convenience of humans not withstanding (more about this later on). . . . 1.1 What It Really Takes To Create A Y2K Problem" No unremediated two-digit year system will experience ANY "Y2K problem" unless it is asked by its logic (mostly software, mostly application software) to operate on TWO or more dates in a calculation, comparison, sort, etc., where at least one date is on one side of the century boundary and at least one date is on the other side, or when the result of an operation creates a date representation on a different side of the boundary than the operands. . . . Looking then at the intrinsic problem of Y2K (independent of remediation, which, as we will see in the next section has its own issues) a number of Forward-Only looking and Forward/Backward looking applications encountering their event horizon began and starting rising many years ago. The rate will grow to a peak around the calendar roll-over. After that point, the Forward-Only looking applications WILL ALL BE INTRINSICALLY BE SAFE. This includes the operational control of virtually all of the dreaded, Chicken Little-ish "embedded chip" world. (Although reporting for off-line management purposes may be affected across a relatively narrow domain of applicability.) But all Backward-Only and Forward/Backward applications looking applications will then be intrinsically at risk. The number of those exposed will fall off as the ending end-point of the domain of applicability of more and more elements sweep across the now-past century boundary. The width/length of any elements domain of applicability determines its intrinsic period of vulnerability it has to damage from Y2K and, overall, the relative number of those elements with the widest/longest determines the intrinsic period of vulnerability society has to direct damage from Y2K. But the length of human lifetimes, various terms of eligibility, mortgages, car loans, drivers licenses, etc., this intrinsic risk will last a long time across a wide swath of our information system infrastructure. In any case, Y2K, the Y2K Problem or the Y2K Crisis does not "end" at any discrete point in calendar time, nor will the efforts at prevention; they must continue for elements whose domain of applicability is entered as time goes on, as todays date moves forward. . . . The only portion of Y2K that actually concerns time, a point in intrinsic calendar time, midnight December 31, 1999/January 1, 2000 or the year 2000 (for a given Time Zone) is that of CLOCKS at the hardware or operating system (OS) level. (Clocks at the application level tend to be specialized for extreme resolution or accuracy for measurement or synchronization and rarely concern years.) The dangerously incomplete idea of Y2K as being about time or a point in time, what I call the Rollover Fallacy of Y2K, neglects the fact that clocks and things that depend on clocks have an intrinsic vulnerability only ONE TIME; they work only in realm of the instantaneous and have a domain of applicability of AN INFINITELY SMALL DURATION. . . . But even for the vast majority of the comparatively rare cases when clocks will fail in some way, they can almost always easily be reset ONE TIME and be reliable from there on. . . . 1.2 Frequency versus Duration When considering the real concerns of Y2K to society as mentioned above, it is not so much the number of system element failures. It is their duration that poses the largest threat; their Mean Time To Repair (MTR). It is in longer duration failures that the breach of containment and the probability of cascading failures of other elements, technical and economic, rise in an exponential-like fashion. We could tolerate a lot of failures if they lasted only a short time. If your phone service is out for a minute, you might not even notice it. If for an hour, it may be an inconvenience. (If it was out for a critical hour when some important call was supposed to take place, that could hurt, but again, thats a probability game.) If it was out for a day, that could very well hurt your business. But if it was out for a month or six months, you would be in serious trouble in many ways, and if the outage was widespread, so would many other people and institutions. Clock failures will be rare, containable, easily detectable and quickly remedied in comparison to the variety-width/length domain of applicability and complexity of things based on software, specifically application software and data; all Y2K failures are not equal. . . . The simple-minded media, always eager to dramatize, has seized on this spurious "deadline" and multiplied the effect. This situation has not only led to the waste of vast resources . . . but also served to blunt or paralyze the mobilization of contingency planning efforts so vital to the actual outcome of the crisis. The Rollover Fallacy, and its misbegotten spawn -- the idea that Y2K will be a sharp but short-term phenomenon once it "happens" -- has given solace to those who believe the best thing to do is to sit back and wait for failures to materialize and then address them and their impacts as they come up. . . . 2.3 Why Traditional Software Remediation Based on Compliance Will Often Fail TRADITIONAL SOFTWARE REMEDIATION BASED ON THE GOAL OF SYSTEM COMPLIANCE WILL NOT WORK in most cases, if the goal is protection from Y2K failures. It means NOT that remediation can fail because it can be done badly, which of course also happens, it means it is FATALLY FLAWED by its very nature no matter how competently done. Traditional software remediation is invasive, involving code modification of a working system. It is based on the Independence Fallacy of Y2K. By the actions taken and not the words said, it assumes the thing being remediated is an independent entity such that changes in its logic need only be considered as to their effect on the thing itself. This is the basis for much, if not most, in-house efforts, and all outside "Y2K factory" code scanning and repair services: "You send us code, we find dates and inject windowing code or modify code to account for data expansion and send it back to you." In neither case is knowledge of all other "systems" that share data, and therefore could be affected by these modifications, considered in the modification process. In most cases SUCH KNOWLEDGE IS NOT AVAILABLE as hardly any organizations have traced data flows among and between their systems at the atomic level required, especially those flows that cross platform, language and organizational boundaries. (The atomic level required is all the paths that every single data element follows through all programs, databases and presentation services. It is not the physical communication paths and interfaces snaking through and between systems, but the logical paths independent of the physical media used that dynamically ride upon the physical.) This is because organizations do not have the tools to do so. And they do not have the tools because they have never really needed them for doing the normal, incremental, piecemeal modifications applied all along the way in the long, essentially additive evolution that has made our infrastructure as hideously large and complex as it is and exposed us to Y2K in the first place. (You know, you were there, programmers in the 60s and 70s that may have had a choice in using two-digit years -- many didnt; the data formats were already firmly established -- never thought their software was still going to be used 30 or 40 years later. That it and the data structures that tie it together are, is the real reason we STILL have two-digit years abounding and therefore have a Y2K crisis now.) When this Humpty Dumpty is put back together again there will be many problems. . . . If an organization goes off half-cocked, without complete, detailed knowledge of how its system of systems works altogether in all normal and possible abnormal situations, as the vast majority of remediators have done, yet make wholesale changes as if it did have that knowledge, they are doomed to failure unless it had many more years than the three of four most organizations have been at it. (Some agencies of the U.S. government were not being fallacious when they first said they would be ready as late as 2014. They were just being honest. Of course, that "politically unacceptable" response was quickly squelched.) It would be better for the whole world if this could be admitted. Then non-technical contingency planning would have the urgency at all levels of society it deserves. But technical management and the Y2Klatura collectively do not have the brains or the guts to do that DEFINITIVELY. We will hew to our baseless confidence or pussyfoot around the obvious until the end. Collectively we are going to drive the ship right into the iceberg and not say anything until the screaming starts and then claim we did all we could to make everything compliant. We will burn in Hell. 3. EPILOG If this sounds harsh, it is only what history has in store for us, the self-appointed Y2Klatura. For we have taken it upon ourselves to define the problem and the solution. We have allowed or encouraged civilians to believe we knew how to handle it. We have buried our own doubts or mealy-mouthed them to the extent we allowed others to believe what was most comfortable for them. Though we have often ranted, we have allowed apologists and scare-mongers to each have their audience. We have given little to leaders that they can use on their terms in their world. We ourselves have been wrong about much. We have not examined ourselves nearly as much as we are demanding others examine themselves. We, too, have believed our own PR. It is time to make amends and do more to undo the damage we have inflicted. Until we do that we cannot expect others to trust us. Rollover/End is a dangerous anthropomorphism that mischaracterizes and misdirects, Compliance the siren song that calls us to the rocks. Other concepts more firmly grounded must be embraced. Other things more firmly grounded must be done.
Category: Compliance Date: 1999-11-01 06:43:25 Subject: The Misleading Definition of Compliance -- Isolated Components -- and the Reason for It: Government Purchases Link: http://ourworld.compuserve.com/homepages/roleigh_martin... Comment: In this long essay, Dale Way provides an illiminating discussion of the common definitions of compliance and why they are misleading. The error began because of large-scale purchases of computers by the U.S. government, beginning asround 1995. The definition ignores this: Said another way, if any one of the relevant components of an operational system is not only compliant in and of itself, but also compliant AMONG THE OTHERS AS A WHOLE, the possibility of error and failure is still present or even likely; a system made up entirely of totally compliant components COULD STILL COLLAPSE in the face of Y2K. If the U.S. government really is the culprit in promoting a misleading definition of what constitutes a successful repair of y2k, this is altogether fitting and proper, because the widespread adoption of the two-digit century date was the result of a decision in 1967 by the U.S. Defense Department to accept it. Having gotten us into this mess, government bureaucrats then adopted a false method to get us out. There is balance in the overall process. This is from Roleigh Martin's site. The essay is dated October 28.
Category: Testing Date: 1999-11-01 07:05:18 Subject: Why Entire Systems Must Be Tested, and Why This Is Not Being Done Link: http://ourworld.compuserve.com/homepages/roleigh_martin.
-- ed portillo (magnacarta00@aol.com), November 01, 1999.
after reading Mr. way's essay 3 times now, there is something really bugging me.Mr. Way
You aren't really saying anything much different than has been said by many. You are someone, however, that will not be accused of doing this to sell books, newsletters ,etc. Why would you risk your position with IEEE to come out and buck the trend? Why bring this up with only 2 months to go? You said it's not too late, but you really know it is. You basically said that we have so messed up the systems with all the changes that we are toast.
Mr. Way what do you know? and more importantly WHEN did you know it. You're phrase "We will burn in Hell" tells me why. GUILT!!!
The establishment, (YOU TOO), knew the problem looong ago, but were under pressure to keep quiet. You really feel guilty, don't you?
Mr. Way, you know what you need to do. Please do it.
God bless
-- bob brock (rbrock401k@aol.com), November 01, 1999.
Gary North's Y2K Links and Forums Category: Compliance Date: 1998-03-02 19:35:13 Subject: The Challenger Shuttle: A Model for Y2K Repairs (Unfortunately) Link: http://ourworld.compuserve.com/homepages/roleigh_martin... Comment: This essay by Dale Way raises the problem of large-scale projects. He is a member of the IEEE Technical Advisory Board Year 2000, and on the Technical Information Ad Hoc Committee (Y2K Committee). Way argues that the extreme complexitry of y2k programming, the exreme complexity of the systems the programs are a part of, and the lack of any historical precedent in program remediation on this scale all point to enormous uncertainty. This uncertainty indicates that there will be mistakes. But managers de-emphasize mistakes. They overestimate the likelihood of success. That was whay NASA's management did prior to the shuttle disaster in 1986. Managers can be fooled, mainly by themselves. Nature cannot be fooled. Get ready for a ride on the Challenger. * * * * * * * * Nature Cannot Be Fooled What The Challenger Space Shuttle Disaster Can Teach Us About Year 2000 Remediation Efforts What can be said in a quantitative, scientific way about the reliability of any Year 2000 remediation efforts? Not much, it appears. We would first have to say something about the reliability of our existing systems. Most of us who have had anything to do with long-running software know it is not so much that it works, as that it hasnt broken yet; that is, it has not yet seen the right combination or sequence of inputs to knock it into some unanticipated error space. But to quantify its reliability in some way seems very difficult if not impossible to do. The scale is vast, our detailed knowledge thin and the application of reliability theory to our existing information systems is virtually nonexistent. On top of that base reliability figure would then have to be added the reliability of all of the corrective actions to be taken in the Year 2000 remediation efforts difficult to the tenth power? Yet we are betting all of our money and effort on the reliability of the net effect of our Year 2000 remediation efforts. We are betting on those efforts to actually protect our existing information system infrastructure from the century data-change while still operating in the manner we expect. (And, I might add, we are betting on the correct operation of a threshold number of the right systems, in a threshold number of the right organizations thresholds and rightness we cannot predict for the continued smooth functioning of our economic and political institutions.) What we are really interested in is the inverse of reliability: the probability of failure. It is upon that that we must base both our technical remediation decisions and our economic or political decisions about the contingency planing we may need to moderate the negative effects of such failure. There is, however, an historical precedent for reliability/failure analysis of a large, complex system that did not survive a significant challenge to its integrity from which we may be able to draw some useful lessons for the Year 2000 crisis: the January 28, 1986 Challenger Space Shuttle disaster. In the days after the tragedy, a commission headed by former Secretary of State William Rogers was appointed. Asked to sit on the Rogers Committee was Richard Feynman, Nobel Prize-winning physicist and universally acknowledged "most brilliant mind on the planet." He reluctantly agreed (he had terminal cancer at the time and died a short time later a great loss to us all). Feynman not only discovered the now-famous O-ring failure point and the chain of interconnected events that led to the explosion, he also uncovered serious flaws in the way NASA conceived of and managed reliability assessment and control. In the end, his discovery resulted in an almost complete overhaul of the way NASA operated and put the agency on the road toward eventual partial privatization. The first lesson we can learn is that even NASA, a heretofore paragon of technology and technical management, can misjudge fatally. Not a comforting thought. First, Feynman found a wild disparity between NASA managements assessment of reliability of the Shuttle and that of the working engineers. All of the following quotes are from his appendix to the Rogers Committee Report. He wrote, "It appears that there are enormous differences of opinion as to the probability of a failure with loss of vehicle and of human life. The estimates range from roughly 1 in 100 to 1 in 100,000. The higher figures [0.01] come from the working engineers, and the very low figures [0.00001] from management. What are the causes and consequences of this lack of agreement?" . . . . "What is the cause of management's fantastic faith in the machinery?" . . . "An estimate of the reliability of solid rockets was made by the range safety officer, by studying the experience of all previous rocket flights. Out of a total of nearly 2,900 flights, 121 failed (1 in 25). This includes, however, what may be called, early errors, rockets flown for the first few times in which design errors are discovered and fixed. A more reasonable figure for the mature rockets might be 1 in 50. With special care in the selection of parts and in inspection, a figure of below 1 in 100 might be achieved but 1 in 1,000 is probably not attainable with today's technology. (Since there are two rockets on the Shuttle, these rocket failure rates must be doubled to get Shuttle failure rates from Solid Rocket Booster failure.)" But NASA management did not like those figures. They took a different tack. . . . What was the evidence that this optimistic view had any basis in reality? Feynman went on to explore this question and his findings were not flattering to NASA. . . . Why NASA management was, in the end, so determined to "fool themselves" emerges in Feynmans understated conclusion to this part of his analysis: mutually-reinforced wishful thinking in the face of external pressure for an "acceptable answer." . . . "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." Restating, what are the lessons that could be drawn from this tragedy, and Feynmans astute analysis of it, for our effective remediation of the Year 2000 computer software crisis? Let us start from the most obvious and move to the more subtle. The most obvious lesson is that wishful thinking must be recognized for what it is. Management of our institutions large and small should be careful to differentiate between what is and what they would like it to be. Simply stating that effective Year 2000 remediations WILL be complete in time does not make it so, especially when the reality of the situation is not clearly understood. Taking this tack is most prevalent in the US federal government and military; the military because they have been ordered to complete their "mission" on time and they WILL do it, the government for more or less the same reasons. When talking with some well-placed government employees (I cannot mention names) who say it will be done about exactly how it will be accomplished, their response to me has been, "That is the responsibility of each individual organization to do themselves." I then ask, "Yes, but HOW are they going to do it?" "That is their responsibility to figure out." "But what if those people dont know how to figure it out?" I ask, given that nothing of this scale, scope, complexity and rigid deadline has ever been done before. Same answer. "But if everybody is responsible, isnt nobody responsible?" I ask. No answer. I was left with the distinct impression these people had no idea how it was going to be done but that it was their job to say it would be. Obviously, business and technical management would dearly like Year 2000 remediation to be simple or easy. They are under a great deal of outside pressure from Wall Street or their superiors in government for the answer to be somewhere between "we dont have a problem" and "we can fix it in time for relatively little money." When they feel like they want to say that, or want to say "It WILL be done," they might want to reconsider and examine whether it is really wishful-thinking at work, a desire or need for it to be that way. In estimating the reliability of Year 2000 remediation efforts, it may be useful to look at history as did Feynman. That is not very encouraging either. Research reported generally at Year 2000 conferences says 90% of all programs in a commercial organization have dates in them. How many organizations of any significant size have reengineered anywhere close to 90% of all of their software in one continuous project, not merely porting it to another platform, but actually changing logic and/or data formats in an wholesale manner? Probably none. How many have done it in three years? Assuredly none. . . . If the history of large projects is not very promising, then let us examine the success rate in normal, everyday large-system maintenance projects. The renown software management statistician Capers Jones Software Productivity Research firm says that in 1995 over 70% of all software development projects failed outright or were late or under-featured when they did come out an on-time, on-spec success rate of less than 30%. So, normal, minuscule (in comparison to the whole) projects fail 2 out of 3 times. Not much help there, either. History is telling us, at a very minimum, not to be overconfident, as it did NASA. Hopefully we will listen this time. . . . The reasons for this phenomenon originate as much in the laws of nature as anything that affected the Challenger. This has to do with the number of connected elements that must be coordinated. Here the laws of chaos or complexity theory tell us that when a system gets to be large, has many interconnected elements, then even small changes can have very large and unpredictable, non-linear effects on the system as a whole. One failed switch in upstate New York can black-out New York City and much of the region. One bad line of software can bring down AT&Ts North American long distance network for a day. And we still do not know what little thing is causing wholesale shutdowns of the western power grid from Mexico to Canada; nothing big is observable. The magnitude and unpredictability of the effects stem from the fact that as the number of elements gets large, the connections between the elements come to dominate the results. . . . Testing then can take a long time, often the single longest phase of the maintenance project; not the testing of the changes themselves, but the testing to make sure that they did not adversely affect other elements in some unforeseen, "unintended consequences" way. Savings in incomplete impact analysis must be paid back in testing (or in failure in production). As the number and extent of the changes gets bigger, the rework/retest efforts grow faster than that, again as a result of interconnective complexity. . . . In the 1950s and 1960s when the first computer system went into an organization (or whenever the first computer system went in a given organization), it was usually some kind of an accounting system (scientific computing is not included in this discussion, but the ideas may hold). Once installed, the system began to acquire, create and accumulate data. When subsequent applications were desired, this first system was, to some degree, "cloned" and its code modified to address a new task. Useful subsets of the data from the first system were also raided or "extracted" and used in and by the second. This went on over and over. Sometimes some non-obvious trick played by a creative programmer to get something to work in the limited space and slow times of those old hardware systems, instead of being "cleaned up" in later systems, was used by those later systems, in fact, came to be depended upon by those later systems. The data format used in those early systems, because it was shared, quickly became entrenched; to change the data format would have required the modification of all the programs that used that data, a politically and economically unfeasible proposition. (By the way, some believe that this is the more realistic view of why two-digit dates were used as long as they were data format entrenchment. Of course, the short-sighted habits of programmers is all that could account for that practice in even some brand new "modern" systems.) As this clone-and-raid process went on for decades, literally hundreds of these systems were built this way in large organizations, almost all in some or many ways connected to each other. . . . And because most documentation, to the extent it was done, was focused on the maintenance of a particular program or set of programs and not the connections between programs, these interdependencies were not often captured or maintained as an organizational asset. And then, over time greater complications were introduced as organizations were acquired and merged by and with one another, eventually sharing data between their information systems which often survived in overlapping redundancy. This is the world faced by larger, older organizations in addressing the Year 2000; a huge numb
-- ed portillo (magnacarta00@aol.com), November 01, 1999.
In defense of Mr. Way, (I'm replying to Mr. Brock here), Mr. Way published similar concerns at my web site on 1/3/1998, in a paper that was dated 1997 but not accepted unedited by the publisher in 1997. Mr. Way did not wait till the end; his voice has been around since 1997 on Y2K and strongly. Now the IEEE moves slowly, too slow for my comfort--but that is not Mr. Way's fault.See Way's 1998 paper at http://ourworld.compuserve.com/homepages/roleigh_martin/chalnger.htm
Roleigh Martin http://ourworld.compuserve.com/homepages/roleigh_martin Westergaard Year 2000 Columnist
-- Roleigh Martin (marti124@tc.umn.edu), November 01, 1999.
Mr.MartinThank you, I will certainly look-up Mr. Ways prior articles. As I mentioned previously, his essay seems very remorseful, as if he was taking Personal blame. When he would say "we", I sensed more of "I". I in no way intended to imply that he "should" take that on himself, but if he feels like there is more we should know, please tell us.
with 2 months to go, what would Mr. Way tell a family with young children? How much should we prepare for?
It IS a heavy burden that we put onto people of his position.
Again...thanks Mr. Martin...and Mr Way God bless
-- bob brock (rbrock401k@aol.com), November 01, 1999.
RC: No, I'm not saying that's OK, I'm saying it's not an interface problem. And more importantly, I'm saying that it's a problem that can only be solved by the remediation of the recieving system, which is just the sort of micro-solution that, according to Mr. Way, won't work.I think I understand your point, having belatedly read the essay. You're saying (I believe) that if an enterprise determined that none of its systems cared about any year prior to 1935, it could establish a standard that for any two digit year field in any interface, the values from 00 through 34 would convey 2000 through 2034, while the values from 35 through 99 would convey 1935 through 1999. This would enable systems to be remediated independently, in that the value of a two-digit year field would not need to be negotiated. Perhaps more important, it would assure that any downstream system would interpret the two digit year according to the sender's intent, even if the sender was unaware of that system's existence.
If an enterprise has the resources to enhance every system in accordance with the above, it might be a viable strategy, but many organizations are compelled to try to distinguish critical from non- critical systems, and remediate only the former. This is where Mr. Way's data flow discussion comes into play.
If System A neither performs any mission critical functions nor feeds data to any mission critical system, does that mean System A is non- critical? It would if, for example, the systems fed by System A are each non-critical and had interfaces only among themselves. But if the systems fed by System A, fed a third set of systems, and any of the latter were mission critical, then you have to determine whether the mission critical systems' critical functions used any data derived from what System A generated.
So I agree with Mr. Way on the need for data flow analysis. Though the need might not quite be universal, it is too close for comfort.
-- David L (bumpkin@dnet.net), November 01, 1999.
November 1, 1999 Read This Essay http://ourworld.compuserve.com/homepages/roleigh_martin/end_game_critiqu e.htm (Dale Way, Y2K Chair, Institute of Electrical and Electronics Engineers) This paper was published on Roleigh Martin's site. I had found it over the weekend and read it Sunday evening. I strongly recommend you read this entire paper. At first, I started to excerpt some of numerous interesting (to say the least) points that Mr Way makes. But I ran the risk of possibly taking a comment or two out of context, so I decided against it. You really should read this paper. See why he says Y2K tech experts will "burn in Hell" (yes, that's what he says). Read about what really is and isn't compliancy, and the essential issue of integration. Much as I dislike to do it (and I really do), I do not intend to post anything else until at least Wednesday, to give you the time to read this paper. It's not that long, and it is well worth it. You may not agree with his conclusion or views, but you should be aware of them. Drew Parkhill
-- ed portillo (magnacarta00@aol.com), November 02, 1999.
Gary North's Y2K Links and Forums Summary and Comments (feel free to mail this page) Category: Noncompliant_Chips Date: 1999-11-03 06:58:29 Subject: The Middle Way: Dale Way Now Says He Is an Optimistic Realist Link: http://ourworld.compuserve.com/homepages/roleigh_martin... Comment: Read Dale Way's original article. Then read the November 1 Postscript. Disconnect. He thinks accounting systems can be fixed on failure. ACCOUNTING AND ADMINISTRATIVE COMPUTING IS NOT LIFE-CRITICAL, at least not in anything like real-time. We can tolerate delays and disruptions there much better than in primary production systems. We can even fudge there for a while, if we have to. Think two words: "bank run." Think three more words: "cascading cross defaults." Recall the scene in It's a Wonderful Life when Uncle Billy takes the currency to Potter's bank. He misplaces it in the newspaper. But the government's auditor is due to finish his work that night. Without that missing currency, Jimmy Stewart cannot settle the accounts. Now think "Uncle Alan." Or "Uncle Kenji." Let's all imagine a Frank Capra ending. Everyone in town takes up a collection and hands Jimmy Stewart $200 billion to tide him over for a day. Will the all of the world's bank computers be fixed the next day? (And why isn't Citibank's fixed today, after four years of work and $900 million?) The international currency market is well over $1 trillion a day. The computers had better work properly. We haven't discussed banks yet -- just currency trading. Errors must be fixed. By whom? At what price? How fast? Engineers look at physical systems. They do not look at social systems. That's why they adopted a 2-digit century. But, I here reprint Way's remediated y2k statement. (It still lacks end-to-end testing.) Laymen have trouble sorting out y2k because programmers and engineers do not agree. It's even tougher to sort out when a single programmer or engineer does not appear to agree with what he wrote four days earlier. On October 28, he wrote: Collectively we are going to drive the ship right into the iceberg and not say anything until the screaming starts and then claim we did all we could to make everything compliant. We will burn in Hell. What he meant to write was: Collectively we are going to drive the ship right into the dock in Puerto Vallarta in July with the air conditioning system broken, and not say anything until the griping starts, and then claim we did all we could to make everything compliant. We will burn in Miami Beach. Mr. Way suffers from the y2k malady: he is continuity-challenged. * * * * * * * * * * * * * * * * * POSTSCRIPT - November 1, 1999 by Dale Way Y2K is the most complex thing we have ever encountered. It involves the existing fifty-year old accumulated information system infrastructure that itself is technically complex in many dimensions. It spans so many different areas of human activity on many different dimensions of human thought and behavior, and yet the way it lays out does not conform to any one institution, set of institutions or any superinstitution. Nor does it line up with their control, accountability and responsibility boundaries. It does not even fit within the boundaries of their worldviews (which they have evolved very successfully while confronting totally different challenges). Y2K cuts across, tramples human-derived boundaries. We often mistake the map for the territory. To be understood sufficiently for anyone who would like to make predictions they can base their allocation of mental and material resources on, it has to be looked at, seen and comprehended to some degree AS A WHOLE, in as many of its real dimensions as can be dealt with -- technical, human, and time -- to attempt to gauge how all the parts, or at least the big important ones, are going to act in response to the behavior of all the other parts. This is very hard to do. When presented with a wide swath of it, most people want to zero in on some small part of it that conforms to their experience and skills, or interest of the moment, and ignore the rest. This is natural. (It is also the root of the Independence Fallacy of Y2K.) But when they do, they can miss more central ideas and forces at work. In your introduction, you focused in on me being more pessimistic than Ed Yourdon about a piece of the whole picture and ignored the whole in the process. You said I had "narrow[ed] the focus of what we must worry about regarding Y2K beyond what Yourdon writes about" but did not say I was highly optimistic about the unmentioned rest. With "pessimistic" the only loaded word there, it is not surprising someone e lse, having not read either your or my words carefully, would jump on that word and over-emphasize it. I illuminated, or attempted to illuminate, many positives about the things MOST people are MOST worried about: 1. The dreaded "Embedded World" that undergirds so much of the process control systems that undergirds the primary functions of the utilities and manufacturing infrastructure is going to be pretty much OK. (Whatever problems there will be there, and there will be some, will be short and if not sweet, at least over quickly.) 2. The basic integrity of the transaction and processing flow (albeit with delays we are unused to) will be maintained, even though the data and information processing systems in the backroom doing accounting and administrative computing may be sputtering and performing intermittently in the process. 3. Most two-digit year systems will cure themselves, given enough time, even without remediation. That should be good news for late starters and for all of us that depend on them. (Or are some of us angry they might get away with ignoring our pleas all this time and without paying a penalty for not becoming "compliant?") It is also good for people who mindlessly "fixed" everything with a date in it, where those cures might be worse than the disease. Two-digit year systems are only at risk for specific and at least approximately knowable windows of time. With that knowledge we can focus our workarounds and stop-gap methods only where needed and know (approximately) how long those intermediate methods will be needed. After that, we can bring back the old, (mostly) working code, if that makes sense. This would allow us a huge increase in the efficiency and effectiveness of those vital activities, minimizing waste of limited resources. But I9m not a Pollyanna, as in someone who wants to believe and pretend things will be all right. There will be disruptions in many areas, areas many people are not paying attention to. For instance, those mostly in accounting/administrative computing that goes on in backrooms on mostly old technology (perhaps emulated on newer platforms), or old and new technologies side-by-side, interconnected/interdependent but non-integrated (the worse of both worlds), ignored by the citizenry, management, the media, the industry (nothing more to sell there), academia and much of the engineering and software professions. This is bad -- this area is where the money is kept and managed -- but not as bad as if the disruptions were in physical control systems that directly produce utility output and manufactured goods. ACCOUNTING AND ADMINISTRATIVE COMPUTING IS NOT LIFE-CRITICAL, at least not in anything like real-time. We can tolerate delays and disruptions there much better than in primary production systems. We can even fudge there for a while, if we have to. But I am not even sure I qualify as "more pessimistic than Ed" even in this other part. That is because I am not sure where Ed really stands on the subject. Like many, he expresses, on the one hand, generalities about firms and industries being more or less "ready," but takes it back on the other hand by pointing out the general and sometimes obvious flaws with the underlying processes upon which this confidence is supposedly based. He, like most, is not being definitive on much of anything. He was certainly not optimistic in his subsequent letter to Alan Greenspan, wherein he occasionally sounded down right alarmist in this area. But unlike many (including Alan Greenspan) I do not subscribe to the notion that "nobody knows what is going to happen." We do know some things about the overall shape of the curve of how things will go ON THE WHOLE. We do know the stages of how the crisis will eventually resolve itself. (See the IEEE Technical Information Statement on my committee9s website for some in-depth work on this subject. But it is not for surfers, the lazy or attention span-challenged. You have to roll up your mental sleeves and get to work, if you go there.) We can, with some mental work, understand the underlying technical realities in far more depth than generally passes for expertise in the field and make decent predictions regarding RELATIVE PROBABILITIES of one thing versus another happening. The idea that because we cannot know everything, we know nothing, is false. We may not know how every micro-event will unfold in such a highly coupled, complex "system of systems" (i.e., the techno-economic system), but we do know some things. In that domain, I am an optimistic realist. I sit half-way between the imaginative but detail-challenged Chicken Littles and the hear/see-no-evil Pollyannas. Right where one would expect an engineering perspective, something too often missing is this greatest of engineering challenges. END Link: http://ourworld.compuserve.com/homepages/roleigh_martin...
-- ed portillo (magnacarta00@aol.com), November 03, 1999.
Gary North's Y2K Links and Forums Summary and Comments Category: Noncompliant_Chips Date: 1999-11-03 08:37:54 Subject: Paula Gordon's Anecdote on Water Systems: Not Good News Link: http://www.gwu.edu/~y2k/keypeople/gordon/part6.html Comment: In an October 25 paper, Dr. Gordon reproduces this exchange. In May of 1999, I had a lengthy discussion with a French electrical engineer who works for a multinational corporation based in France. The company focuses on water purification plants, water distribution systems and the like. I talked with him at length about embedded systems and sought his perspective on why it is so many people in the United States, including many engineers, do not seem to understand date sensitive embedded systems and the subtleties of embedded systems that are connected to real time clocks. (More about this exchange will be discussed in another part of this White Paper.) My key question to the French electrical engineer, was the following: "What do you say to a person who will not accept as fact that malfunctioning embedded systems could in and of themselves cause major problems?" He said, "Oh, that's easy. I just tell them that if you have an (automated date sensitive) embedded system that controls a valve that in turn controls the amount of chemicals that flows into a water supply (in a water purification plant), and, if that embedded system malfunctions, you can end up with no chemicals, not enough, or too much." I said, "That's all you tell them! That's just common sense. We don't use common sense in America." We both laughed. It's a lot funnier if you have a well, four solar panels, and a water filter. Link: http://www.gwu.edu/~y2k/keypeople/gordon/part6.html
-- ed portillo (magnacarta@aol.com), November 03, 1999.
This letter is to Mr. Way about his post on Mr. Martins site:Let me start out by letting you know who I am. I am a 42 year old housewife and mother of 3 kids. I have no background in computers, but I have been following the Y2K problem since Jan. 1999.
I just read your letter to Ed Yourdon and I just had to write you and also post this letter on this board.
First of all, you came across like you feel that everyone is blaming you or your people for the problems that are possibly going to occur come 2000. Why do you feel this way? This is bigger than anyone has control over! People such as myself, just want the truth to be out to the public. It doesn't matter who is at fault with the problem now, it is past that point.
From what I understood of your letter, you don't even know what to expect. Although, using the Titanic and iceburg theroy, does scream, BIG TROUBLE! The problem that I saw you were missing, is the fact that all of the things that could happen (forget why they happen) will affect this country period. It will affect the world as well, but the world is not completely reliant on computer technology as this country is....
Even though you seemed to be saying, "it is not our fault", who is blaming you in the first place? My problem is the fact that this has not been taken serious by the public! I am not really sure who is to blame for that. But I do know, that the government, industry and media had the chance to get the public to prepare for this unknown situation and instead, they down played it! BIG MISTAKE!
I am not a computer savy person, so your explaintions or statements in general went over my head a few times. But, I do feel I got the jest of what your were saying as a whole. You have no idea what is going to happen, but you think that it will fix itself over time. What with all the work that has been done so far.
Now, let me say this. Are you looking at the Y2K problem from a view inside the computer world? How about taking a look at the computer failures from outside the systems, where the effect is going to be the most devastating!!!
What are we suppose to do? Who is this going to affect? Will it hit my area where I live, affect my life style, my family, my friends and neighbors? To what extent could it be? Will it be little or BIG problems? Will I be paying $5.00 a gallon for gas in this area? Will I be standing in line for food and find there isn't anymore left? Will I be out on the streets with everyone else trying to figure out what in the world we are suppose to do now? Will I have to locate shelter because our home can't provide the protection we need as a family? Will this happen here or somewhere else??? (those are retorical questions, because I am one of not so many, who is preparing).
You seem to be so worried about how you and your people are going to look, that you are not seeing the big picture. No one is blaming you! And you do sound like there is going to be problems, so your rebuttal, didn't impress me much. You know the ins and outs of the computer systems, but do you know the ins and outs of LIFE?
The point I am trying to make, is that we all must prepare for Y2K period! None of us know who it will affect. It may affect a few, it may affect many, it may affect all! Either way, there will be an affect from this. The domino effect is bigger than all of us! So, think past just the tiny problems of computer failure and think on the lines of the human race! Of which you and your family are part of.
You hold a big position and your words can help many believe that they should prepare!!! You have taken a stance to defend yourself when it comes to blame, instead take a stance to helping others, like myself, who are determined to get the public to prepare, not knowing what the out come will be from Y2K. I look like an "idiot" everyday when I talk to people about Y2K.
So, you feel "guilty", and people think I am a "idiot".
Our efforts are going unheeded because people of your status won't commit, the government won't commit, the industry won't commit!
We are dealing with people who don't want to hear there is a problem and as long as everyone is saying "we are y2k ready" the "but if's" will continue to be ignored by most of the public! You know the famous saying....we are "y2k ready" and then immediately following that statement,"but if"....
By the way, is "y2k ready" the same as "y2k compliant"? Why do they keep changing the term?
So, if you want to help, do another letter, in laymens terms!!! Come right out and say...the public should prepare! It doesn't look good and preparation is the only alternative to dealing with this problem. You can say, everyone is doing their best and some are doing nothing. Preparation by the public, is the only answer now. Do it now, while there is still some time left. Do it before the media has a hay day with this come Dec.99. Help the ones who are trying to spread the word that preparation is the key to surviving through any of this! We have to be prepared! Otherwise, the good and the bad are going to be out on the streets causing more problems on top of problems!
I sure hope you read this letter and take the time to understand it. I realize it is in laymens terms, and I know that great minds have the ability to understand only great things and this is such a simple letter. So, please, read it carefully as I read your article carefully. I did my best to understand it, and I hope you have the same respect to do the same with my letter.
-- Susan Carter (runnidoe@knology.net), November 03, 1999.
dear Susan Carter: What a great letter, and great thought. We will make it through whatever storms and darkness we may face by the grace of God {only!) I agree with you wholeheartedly-come forth, Mr. Way, and redeem yourself by speaking plainly and without compromise! Fear none but God. Jeri Tanner
-- jeri tanner (alatopkid@aol.com), November 03, 1999.
Mr. Way,Why did you backtrack on your original statement? Are you taking precautions? How about your family?
If you are truly worried you should make public waves now. That could save some people pain and suffering.
Ray Hildenbrand Sr.
-- Ray Hildenbrand (Crazynick@MSN.com), November 04, 1999.
While I'm sure Mr. Way could influence some to prepare, I truly believe that his voice would be drowned out by TPTB, and he would be summarily smeared as a fear-mongering/extremist/alarmist/squirrel-loving-enemy-of-the-people.Seriously, does anyone honestly believe that warnings from ANY source (short of a "burning bush" perhaps) will have the SLIGHTEST impact on a nation which is already convinced that Y2k is/will be a dud?
-- I'm definitely (not@tro.ll), November 04, 1999.
I recommend readers of his Oct/Nov 1999 paper also read something that Dale Way wrote in 1997 about Y2K:http://ourworld.compuserve.com/homepages/roleigh_martin/chalnger.htm
Nature Cannot Be Fooled -- What The Challenger Space Shuttle Disaster Can Teach Us About Year 2000 Remediation Efforts
by Dale W. Way
DBStar, Inc.
Member of the IEEE Technical Advisory Board Year 2000 Technical Information Ad Hoc Committee (Y2K Committee)
(as of 1999, Chair of the IEEE Y2K Taks Force)
Copyright 1997, Dale W. Way. All rights reserved.
Webmaster's note: this paper was added as a link to the page, Sociological Observations On Why It Appears There Will Be a Year 2000 Crisis. It is the full-length contribution that Dale Way made to Leon Kappelman's edited book, Year 2000 Problem: Strategies and Solutions from the Fortune 100. Only a small portion of this paper--less than one published page--was used in the book due to the editor's discretion. It is reprinted here in full via written permission of Dale W. Way. In granting permission, he wrote "Look at NASA's failures and you will see that collectively we have fallen into every one of the traps they did. I tried to let the reader draw his or her own conclusion, but this turned out to be a very pessimistic document. No wonder Leon chopped it down for his 'best practices,' 'experts show you how to do it' book."
[snip]
-- Roleigh Martin (marti124@tc.umn.edu), November 05, 1999.
Must readNature Cannot Be Fooled
-- Brian (imager@home.com), November 06, 1999.
Time to look at this again.
-- (Public@service.announcement), January 16, 2000.
When I copied and slowly read this essay I was reminded of the kind of puzzles you do on holidays when you get really bored, or need a challenge.The kind that you find in given words of 3,4,5,6, letters in the right spot and then the interlocking words should all come out right. But if you put one word in the wrong space, even though you could add a couple of other words which fit, if that was not the correct word for that place, then everything else has to be erased and started all over again.
This is what I understand from this essay - that everything single system within the whole system must work correctly (fit in the puzzle) or the other applications will not work either.
Very simplistic - but very worrying....this beast could go one interminably, until it affects the lives, economy, direction of the civilised world. Back to counting TP - this takes a lot more considering, after the easing up the last couple of weeks. Thanks Mr. Way (I think!).
Good comments Susan - just what I was wondering too - it will still be the same panic if we are not prepared for anything...I am so tired of this whole thing, anyone know of a desert island where they don't have computers????
-- Laurane (familyties@rttinc.com), January 16, 2000.