Direct correlations-- its bigger than we can imagine- IMHO

greenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread

Having Studied Dale Ways Essay and not being a programmer I was hard pressed to imagine the extent of the interconnections he refers to, well Mr. Lane Core just assisted with the current posting on Westergaard:

This snip is from Ralph Daugherty a Westergaard Columnist:

"" DAYTONA BEACH-New computer software failed a deadline Tuesday to "go live" dates were rescheduled July 1 and Sept. 14. Software related to the city's general ledger, payroll and utility billing were city concerns going into the test Tuesday. Utility billing remains a concern...Computer programs...at a company that processes the city's utility bills have to be changed to communicate with the city's system. There will also have to be additional coordination with computers at [Dayton's] bank, which recieves utility bill payments..."We have a very complicated system with a lot of INTERACTION between all the system we have. They all must talk to each other and send infromation to other systems at other agencies.""

OK now for Dale Ways Essay (and this is a small part regarding the Independence fallacy):

""If an organization goes off half-cocked, without complete, detailed knowledge of how its 'system of systems' works altogether in all normal and possible abmormal 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, - - end snip--

DOOMED TO FAILURE

DOOMED TO FAILURE!!!

more:

-snip-

All the system involved in the affected data flow chain (which they cannot fully see) may be working "correctly" from their point of view, yet the end output is not right. Such problems live in the INTERRALATIONSHIPS between systems, in the gaps, the very place compliance thinking doesn't allow you to see. They will have to make their best guess, take their best shot, intervene someplace, AND TEST AGAIN test all the systems that are involved TOGETHER again.""

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

Answers

jsprat, where are ya when we needs ya?

Kook

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


Arguably we should alert the newcomers that "Dale Way" is the chairman of the International Electronics and Electrical Engineering (IEEE) Society's Y2K task force. What a doomer! What does he know anyway?

-- Dave (aaa@aaa.com), December 16, 1999.

Thanks David for the Clarity. By the way for newcomers here's is how the Chair of Y2K for IEEE ends his Essay, please compare to what we here from El Presidente and his Y2K Czar. (who do you believe?).

--Snip--

"But technical management and the Y2Klatura (programmers) 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 this 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."""

whoa!! and this from an computer engineer!!

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


For non-programmers, it might help to think of it in terms of "trust".

If you have two systems that were written at the same time, intended to talk with each other, it's like children growing up, learning to communicate with each other without formal rules. System A "trusts" system B to have correctly edited date information, for example, so system A does check the data files coming from system B for validity. The opposite case would be a program that accepts screen input, where you have to check every character entered, to make sure the operator doesn't put in something that will mess up your database if you accept it.

Probably 99% of all data interchanges are between "sibling" systems, that were written by cooperative teams of programmers, so trust is very high and precautions are very low. The POS system passes sales data to the inventory system, etc. Because the systems were often written in a short time frame, documentation may be skimpy (you don't need to document when you can holler over the cubical wall to get the answer you need).

The problem arises when these systems are modified years after the original programmer teams are gone. This creates an extremely high danger that a Y2k fix, which looks just fine to the temp workers maintaining system A, will cause system B (patched by another team of temps) to toss its cookies. Every single change carries this risk, so systems that communicate (the system of systems) have to be tested repeatedly as each is examined, repaired, and put back into production.

-- bw (home@puget.sound), December 16, 1999.


Think banks! More from Mr. Way:

-snip-

"" A large Bank can have 100,000 programs that run on 30 different platforms and use 50 different languages (type,vintage and compiler manufacturer). Make several thousand code changes across that base in something as ubiquitous as date processing in something like banking operations. Assume you detected ALL dates (you would be lucky if you found 90%) and made modifications PERFECTLY (have the best people been the ones doing this all along?? do you have the best tools? for all environments? do you have the best project management and configuration and version management capabilities AT THIS SCALE?). And that bank is on-line through the Fed to all other banks. How many errors will there be after making thousand of changes to a very large 'system of systems' no one really understands in detail??""

-end snip-

HOW MANY ERRORS WILL THERE BE AFTER MAKING THOUSANDS OF CHANGES TO A VERY LARGE 'SYSTEM OF SYSTEMS' NO ONE REALLY UNDERSTANDS IN DETAIL?

HOW MANY ERRORS WILL THERE BE TO A SYSTEM NO ONE REALLY UNDERSTANDS IN DETAIL??

HOW MANY ERRORS...IN A SYSTEM NO ONE UNDERSTANDS IN DETAIL??

HOW MANY ERRORS... NO ONE UNDERSTANDS

NO ONE UNDERSTANDS!

why should we prepare!!!????

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



How many errors? Nobody knows.

Why should we prepare? Because nobody knows.

-- bw (home@puget.sound), December 16, 1999.


--d---, freaky abstraction; chilling.

-- Hokie (nn@va.com), December 16, 1999.

Moderation questions? read the FAQ