Fellow programmers - is this a FACT or not...

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

My thread Hit me with your best shot... resulted in many opinions and very few facts from the polly crowd. I ask you, based on your personal experience and knowledge of computers, do you consider my following statement to be a FACT?... <:)=

Many of you have said that you are confident because nothing has come of the predictions about 1999 failures. Here is a FACT. The number of programs that do look ahead processing is tiny, when compared to the total number of programs that have a date problem. How do I know that this is a fact? Do I have a detailed software inventory of the 50,000 mainframes? No, I do not. Do I have detailed knowledge of the thousands of PC programs on the market? No, I do not. What I do have is 31 years of programming experience. What I have done is work on well over 1,000 programs in those 3 decades. What I do have is a general knowledge of the types of systems that run on both mainframes and PCs. LOGIC tells me that this is a FACT. Logic also tells me that those programs that do look ahead processing are well known, and that these programs would be fixed first, because they are needed first. Would anyone care to refute this fact? If so, take your best shot.

-- Sysman (y2kboard@yahoo.com), April 30, 1999

Answers

I think "line of reasoning" would be more approriate. To establish the "fact", in my opinion, you would need some statistics on the categories of business logic employed in all software programs.

-- Anonymous99 (Anonymous99@Anonymous99.xxx), April 30, 1999.

Sysman, I agree with your opinion but it is not fact. I never thought that Eddie was right about the prediction on accounting software. Too little to really notice, even if it did fail. Remember insurance companies look ahead ten years. Their software failed in 1990 and no one noticed. Logic tells you this is your conclusion not fact. Additionally, you need to define the word FEW; 1%, 10%, .001%. Quantitative things can be made as fact; subjective statements are not fact, (from a mathematicians point of view).

-- Maria (anon@ymous.com), April 30, 1999.

Anon,

I agree, but since no one person knows all the business logic, I'm relying on the experience of those involved in the business. In your opinion, is this a fact? <:)=

-- Sysman (y2kboard@yahoo.com), April 30, 1999.


Sysman,

Got REAL lonely on that Thread.

As Anon implied. Without numbers it becomes a judgement call.

Facts? Numbers?

Who has them?

No. Who will share them?

Any lawyers care to answer that question?

Father

-- Thomas G. Hale (hale.t@att.net), April 30, 1999.


Sysman,

Over 15 years of deep-in-the-bowels programming experience here and I agree. Most 1999 failures will come in Oct-Dec when monthly and quarterly projections are run. I still think the most dangerous time for us is going to be Jan-Jun 2000 as outright failures occur and corrupted tables are discovered.

-TECH32-

-- TECH32 (TECH32@NOMAIL.COM), April 30, 1999.



0.597% of all programs look ahead. I know, cause it was on Jeopardy the other day.

I imagine the number is indeed small, Sysman. And I agree that they would get priority attention.

-- regular (zzz@z.z), April 30, 1999.


Thomas,

This is the problem. No one has the numbers, so we can't prove it either way. That's why I'm asking for the opinion of people with experience.

Maria,

I take it that you agree, even though we can't prove it? <:)=

-- Sysman (y2kboard@yahoo.com), April 30, 1999.


I'm reposting a question I asked on the other threrad that didn' get much response (probably because it was something like the 65th response)...

--

As someone who is neither in the "doomer" or "polly" camp (not publicly anyhow), I have a question for the Pollys: even Koskinen suggests that major infrastructure failures are likely in many countries abroad. The CIA has expressed the same beliefs many more times, and much more forcefully. So has the World Bank...and the UN...and Gartner...and...and...

My question, then, is twofold: (a) do you think this concern is overblown, and (b) if you think it is well-founded, and then you combine the infrastructure-level problems, secondary-level failures, human response, and economic fallout, isn't it naive to suggest that Y2K will be a nonevent for us...in essence, that we live in a vacuum from the rest of the world?

It seems to me that there is so much hangup about precisely predicting the exact impact of primary failures, and that the secondary cascading impacts are underplayed. But maybe that's just me.

I know your answers will be as unique as your personalities. Thanks for your consideration...

Scott Johnson
Editor,
y2ktoday

-- Scott Johnson (scojo@yahoo.com), April 30, 1999.


sorry for the typos...it's Friday... :)

Scott

-- Scott Johnson (scojo@yahoo.com), April 30, 1999.


Scott:

Good question. I suggest you start a new thread.

-- regular (zzz@z.z), April 30, 1999.



okay, regular, I just took you up on that suggestion. Here it is...

Scott

-- Scott Johnson (scojo@yahoo.com), April 30, 1999.


Scott is the only one at this forum that has it right. January 2000 will be a non-event. The problem will surface starting during the summer of 2000, and last through 2003, perhaps even 2005, as we feel the effects of the rest of the world not being ready. BTW the economies of Brazil, Mexico, Japan, Russia (to mention but a few) are in such shambles they may collapse without, or even before Y2K. Even if the US is 100% compliant, the result of other countries not being ready will be much worse on us than on them. World-wide, serious depression and economic hard times lasting 2 or 3 years are much more likely than 1 to 10 (or whatever) months of no electricity in the US.

-- Walt (walt@lcs.k12.ne.us), April 30, 1999.

Sysman:

My 31 years of experience in developing, writing code, and remediating on legacy systems, enterprise systems, LANs, WANs, PCs, and mid range systems in every kind of financial package known to man says:

THIS IS A FACT.

I could care less what some numb-nuts polly or other self-proclaimed expert has to say on the matter - they are dead wrong.

No offense, of course.

See ya.

Mike Cumbie

-- Mike Cumbie (mikecumbie@aol.com), April 30, 1999.


Well, I guess that's that! Next question please!!

-- RMS (rms_200@hotmail.com), April 30, 1999.

Ok RMS, here's your next question. If you do accept it as a fact that it's called the Y2K problem for a good reason, why do so many of the polly crowd cite lack of early failures as a reason for Y2K being a non-event? <:)=

-- Sysman (y2kboard@yahoo.com), April 30, 1999.


Sysman:

While I do not accept it as a fact (that was sarcasm), I'll answer anyway. The lack of early failures neither proves nor disproves the possibility of failures later. It does, however, cause any reasonable person to question why predictions of massive failure later should be accepted without proof when previous predictions have been shown to be false. Like I said in the other thread, I am the way I am because no one has convinced me otherwise. The more predictions are shown to be false, the more carefully I will scrutinize what else those same people are predicting in the future. If they have facts or even fairly credible circumstantial evidience to support their prediction, I may accept it. If not, I will look elsewhere before either accepting or rejecting their predictions. Think of it like a bookie: if he is wrong week after week after week during the regular season, are you going to go solely with his predicition on the Super Bowl or are you going to look around before placing your bet.

-- RMS (rms_200@hotmail.com), April 30, 1999.


"The number of programs that do look ahead processing is tiny, when compared to the total number of programs that have a date problem."

I would not use the term "tiny". It is a function of the type of system. On the other hand MANY systems archive dated historical information and the opportunity to screw up the files based on dates after 00 doesn't happen untill after 001231. (Yes there are exceptions.) These things have been occuring and found or not found and fixed if found for 9 years, that I know of. The scary thing is that the hardware, COTS software and infrastructure embedded problems at rollover of century coincide with the start of the post 00 business logic faults and file archiving faults.

Even if the pre 00 faults were the vast majority of problems, the leisurely way we have encountered compared with the all at once nature of rollover and post 00 faults will make it seem tiny.

"Logic also tells me that those programs that do look ahead processing are well known, and that these programs would be fixed first, because they are needed first"

I wish logic was well known. It's absolutely mind-boggling how much stuff is out there that has done its job for years, isn't documented, and the in-house expertise is long gone.

-- noel (ngoyette@csc.com), April 30, 1999.


Come on now RMS, make up your mind! Also from the other thread...

You missed the point Sysman. I'll accept it as a fact if you want. But, even so, it does not change the fact that EY and the others were flat out wrong about massive pre-Y2K failures and in no way does it imply that other software problems will not be fixed in time.

-- RMS (rms_200@hotmail.com), April 30, 1999.

------------------------------------------------------------------------

RMS,

I can't speak for Ed or anybody else on their predictions. Maybe because of people like Ed sounding the alarm early, awareness was raised, and enough work was done to avoid early problems. Myself, I have constantly said that I did not believe that early failures would amount to much.

We do know of at least one state that did not predict unemployment claims past Dec. 1999 because the system was not ready in time. <:)=

-- Sysman (y2kboard@yahoo.com), April 30, 1999.

I'ld like to also point out that we've had at least a couple of reports of companies moving their fiscal year end to December, although Y2K was not cited as the reason. <:)=

-- Sysman (y2kboard@yahoo.com), April 30, 1999.


I'm far from a reformed GI, but what RMS says makes perfect sense to me. Not many people are going to accept a prediction without some kind of track record. Here in horse country, I'm not going to bet with the guy who continually gives me bad tips at the track. Laying my money down for nothing. While my instincts tell me I have to prepare, the lack of numbers keeps me wondering what I'm missing.

-- margie mason (mar3 mike@aol.com), April 30, 1999.

Sysman,

"Tiny" is a relative term, but not that far off, IMO, in an objective sense.

I see business software divided along three lines in terms of Y2k, with estimates of breakdown gleaned from experience:

Look ahead - 10-20%
Real-time with significant date usage - 60-70%
Real-time with trivial date usage - 20-30%

The actual weightings will depend upon the application.

For the bulk of most software, most programs ask two basic questions: "What do you want me to do?" (which, as part of the "what", frequently involves scanning across historical data or projecting into the future), and "When do you want me to do it?" (which usually means either "right now" -- on demand -- or involves referencing some external element [a clock, calendar, flag, or some particular data state] in order to make a go/no go decision).

Scientific software is much less date dependent and usually operates in real-time. This is where the embedded, real-time control issues reside as well. I would give this class of software a lower "look ahead" weighting, and higher "real-time" weightings.

Manufacturing software is an amalgamation of the business and scientific genres, but is more complex than either due to generally much more critical timing and scheduling requirements. This software would have a lower "trivial real-time" weighting, and a higher "significant real-time" weighting and a potentially higher "forecasting" weighting, depending upon just how automated the process is.

Business software would generally do the longest range forecasting, manufacturing software would look ahead something like a day, a week, or a month, depending on the JIT tolerance employed, and scientific software would barely look ahead at all, e.g., weapons or measurement systems.

A few other considerations:

1) Just because look aheads aren't apparent to JQ Public doesn't mean that certain I/T staffs aren't pulling their hair out right now. Only the forecasting components of fiscal year rollover would currently be causing problems, and these may not be noticeable to either the customer base or the bulk of the internal user base.

2) Looks aheads, by their nature, are much less critical than other processing. They may well become more apparent only as the terminus of the look ahead period approaches and passes.

3) Though not strictly Y2k-related, the GPS rollover, as a real-time, embedded, widely dispersed phenomenon has a much higher probability of exhibiting apparent problems.

4) The 9/9/99 "end of file" prediction will be negligible, as the date data is normally stored in 6-digit form as 990909 (yymmdd), not 9999.

-- Nathan (nospam@all.com), April 30, 1999.


Sysman,

>Fellow programmers - is this a FACT or not...

Not.

(P.S. I'm gonna start complaining about your pronouns after a while.)

>My thread Hit me with your best shot... resulted in many opinions and very few facts from the polly crowd.

So you're fighting fire with fire?

>I ask you, based on your personal experience and knowledge of computers, do you consider my following statement to be a FACT?..

My computer experience and knowledge has little or nothing to do with recognizing your paragraph as non-factual overall. I could've figured that out before I ever touched a computer.

>Many of you have said that you are confident because nothing has come of the predictions about 1999 failures.

Does "you" refer to the "Fellow programmers" to whom you apparently addressed your preceding paragraph?

>Here is a FACT.

Shakespeare's phrase "doth protest too much" comes to mind as I behold your uppercase emphasis, so I'll go into cynical mode.

>The number of programs that do look ahead processing is tiny, when compared to the total number of programs that have a date problem. How do I know that this is a fact?

Yeah -- how?

>Do I have a detailed software inventory of the 50,000 mainframes? No, I do not. Do I have detailed knowledge of the thousands of PC programs on the market? No, I do not.

Okay, you've established that you are writing in a rhetorical mode other than straightforward exposition, and ruled out two of the most likely ways by which you could establish that your claim of factuality.

Real good start on your proof, buddy. Gonna convert lots of pollys with that!

>What I do have is 31 years of programming experience.

Oh, yeah? You also claimed to be presenting facts.

Or a fact.

Or something.

>What I have done is work on well over 1,000 programs in those 3 decades.

About 99,999,000 to go ...

(For the sake of argument, I'll give you TWO orders of magnitude and make that 999,000 to go ...)

>What I do have is a general knowledge of the types of systems that run on both mainframes and PCs. LOGIC tells me that this is a FACT.

Help me here -- I'm having trouble tracking your pronouns' antecedents. By "this", you are referring to ... ?

>Logic also tells me that those programs that do look ahead processing are well known,

... well known to whom ?

>and that these programs would be fixed first, because they are needed first. Would anyone care to refute this fact?

Okay, stop right here. "this" = ...? _Which_ fact? For what, exactly, are you requesting refutation?

>If so, take your best shot.

Can't aim while I'm laughing, Sysman ... :-)

My advice to you: Adopting the rhetorical device of labeling opinions or lines or reasoning or conclusions as "FACT" (even in lowercase) damages the credibilities of your arguments. It allows a skeptical reader to easily dismiss your statements without taking the trouble to investigate. ("If he can't tell the difference between fact and opinion, there are bound to be lots of holes in his arguments about an unprecedented, controversial, and hard-to-prove issue like Y2K.")

BTW, writing "FACT" in all-uppercase is a telltale for this sort of thing.

-- No Spam Please (No_Spam_Please@anon_ymous.com), April 30, 1999.


RMS - Read the report about Northwest Airlines remediation program, and its efforts to get the Detroit Airport (its hub) remediated, tested, and fully (operationally) compliant.

Every case their spokeman mentioned reads like he co-authored Yourdon's original book. The predictions there are exaactly on the mark. Potential troubles (1999) have never been expected to be high , except by Mr. K's office - who posted an extermely long list in their warning to the military - so if 0.5% occur, rather than 1%, the statistical implication of the difference is meaningless.

More important, there are numerous failures reported already about remediation efforts that were done wrong, and thus caused errors early. Again, theis is expected - 3-7% of program changes introduce new errors in previously working programs.

Most telling - if Y2K (overall) were to be a non-event - as you evidently hope - then who anywhere at any level in any company or any agency who has finished remediation is willing to say: "It was a waste oftime, money, and effort. We shoud have increased salaries, or raised stock options."

The fact that nobody anywhere can say that indicates that the people and companies who have looked, who have fixed their problems, and who have tested their solutions have found truly frightening problems.

The only ones who claim it will be a non-event, who claim no one should prepare, no one should be trained mentally for disruptions and inconveniences are people who can't predict the future, who have not been through it before, and who don't want people to disrupt their apple carts.

-- Robert A. Cook, PE (Kennesaw, GA) (cook.r@csaatl.com), April 30, 1999.


No Spam,

I really don't have an hour to waste, and tear your answer apart word for word. You will notice that I pointed out that no one has enough informatin to prove if this is a fact or not. I asked for OPINIONS, from those that have EXPERIENCE. I take it that your OPINION is that this is not a fact? <:)=

-- Sysman (y2kboard@yahoo.com), April 30, 1999.


I generally agree with Sysman on the relative minor contribution of lookaheads to the total failure rates. But, as mentioned above, the quality of the failure is important. Lookahead processing is usually a non-critical item in a company. If it disappeared all together, it would hardly be noticed outside a company. If all 500 of the Fortune 500 had such look ahead failures, it wouldn't be known outside a few rumors on the geekvine. So if you are expecting an item on CBS/ABC , forget it.

To specifically answer Sysman's original question, lets just say the overwhelming weight of my multicorp/multidecade experience supports the relative term of "tiny" (say LT 5%).

-- RD. ->H (drherr@erols.com), April 30, 1999.


Sysman:

No Spam answered what you said, even if that wasn't what you meant. What you presented was extrapolation based on extensive (but in a large sense, extremely limited) experience. You can call this logic and facts, but it isn't. It's extrapolation, however well-founded.

And that's what all of us with experience are doing. I can peer into the details of my own little world and see that problems there are pretty trivial. But I know my area is not the big picture. Cory looks at his world and sees big problems. He thinks his world is the big picture, but it isn't. Might be bigger than mine, might not.

I can't refute your experience any more than you can refute mine. The fact that you see important problems in your area is meaningful to me. The fact that others with similar experience don't see the same thing at all is meaningful as well.

Interestingly, I never heard anyone once say that they were focusing on lookahead problems first, until those dates passed uneventfully. Indeed, it was just the opposite -- Cory, Ed, et. al. predicted so many lookahead problems that "all speculation will end."

Critical systems first, yes. Billing systems before embeddeds, yes. Never lookaheads. This argument that lookaheads *must* have been addressed first is very recent, and is purely an ex post facto rationalization for lack of difficulty so far. If *you* were concentrating on lookahead problems as a higher priority than rollover problems, you never said that.

I'm willing to grant that lookaheads represent a small fraction of total problems, but it would seem very system-dependent. Systems that make heavy use of lookaheads should have failed badly, but didn't. So if lookaheads were addressed first, all I can say is that this is one of the very few aspects of remediation that all the geeks kept silent about. Even though they had no reason to. Of course, this strange silence isn't a refutation of what you say, it's simply all we could know about these hidden priorities until after the fact.

-- Flint (flintc@mindspring.com), April 30, 1999.


OKay RedH - but I figure less than 1%; with may more on the user PC level with a spreadsheet-type approach. The VP of Sales, or the lead marketing guru doing it himself to 1) protect his trade secrets, 2) protrect his job from somebody else figuring out how he makes predictions. Makes no difference really.

Would a company who had bad data displayed in a meetin between VP's, or during a staff planning meeting publicize it? Wouldn't it be more likely that the "error" - if one were there, and if it were noticed at all as an error - would be self-corrected (typing over manually by the user), manually re-entered into the spreadsheet, simply delayed the meeting, simply not noticed the bad data, or changed the charts manually, or ....

Why whould you figure that "ool ahead" errors would be published? And if the predicted news were bad - say "We predict doom, gloom, and low sales next year due to massive failure of our manufactoruring plants in Taiwan, Singapore, and Korea, plus a lower market for exports to Europe and the MidEast" - would you really figure the company was going to march outside and publicize it?

DON'T BUY OUR STOCK - WE WILL HAVE A BAD YEAR NEXT YEAR BECAUSE OUR VENDERS SCREWED UP.

Do you really think a president is going to advertise this?

-- Robert A. Cook, PE (Kennesaw, GA) (cook.r@csaatl.com), April 30, 1999.


No Spam,

Clearly you don't 'Get It'.

If a new type of flu started killing people across the country, who would you believe:

A) the doctors who are scared sh*tless because if it's not cured in the first 24 hours, the patient always dies or

B) the HMO spokesperson who says 'there is no flu problem so you don't have to prepare by getting those new expensive flu shots'.

Would you disbelieve the doctors simply because people weren't dying fast enough early on to convince you to get your shot? Personally, I'd play it safe and get my shot.

ALL (sorry, forgot caps annoy you) All of the programmers I know are very concerned about Y2K. See, we all know what a complete friggin' mess most systems are. We all know that 'opening up the code', particularly on older systems, always increases your chances of introducing new errors, both subtle and not so subtle. We all know just how difficult it is to get data transfers worked out between departments, let alone our 'strategic trading partners'. By the way No-Spam, those are all 'facts' that any seasoned programmer can confirm.

The Y2K problem is fixable and if everyone had started two years earlier I wouldn't be concerned at all. But they didn't start that early. The majority of companies only started looking at the problem in mid-late 1998 (care to dispute that?). Sorry No-Spam, but that just doesn't leave enough time to get it all fixed 'correctly' ('correctly' being much harder than you might imagine).

So, are you going to start listening to the doctors or not?

-TECH32-

-- TECH32 (TECH32@NOMAIL.COM), April 30, 1999.


Sysman,

I agree that in most systems only a very few programs look ahead. However, I worked on a large manufacturing system for 15 years, and the very fiber of its being dealt with looking ahead. Its materials requirements planning (MRP) and master production scheduling (MPS) modules look out six months into the future. That system will start to continuously project into 2000 between late June and early July.

-- Incredulous (ytt000@aol.com), April 30, 1999.


Thanks Incredulous. This is the kind of opinion that I'm looking for. Areas where I do NOT have personal experience. <:)=

-- Sysman (y2kboard@yahoo.com), April 30, 1999.

Flint uttered:

Systems that make heavy use of lookaheads should have failed badly, but didn't.

Didn't a certain type of credit card have serious problems a few years back? If they did then is that considered a lookahead for the system checking the expiry of the card? Just interested.

On another note, it has always been my understanding that the real problem is when computers roll over into 1-Jan-2000. The other dates mentioned has always indicated to me that these could be potential problems, not that there will be problems but there may be problems. I'd say that there were some problems on say the 1-Apr-1999 but either they were minor ones easily fixed and hidden or no one has noticed the problems caused yet.

We just got installed a rain water tank, some members of our family think we are nuts because we bought it for Y2K. Actually we've always wanted to get one, Y2K just gave us the motivation. At least we are getting all those repairs, gardening, etc all done that we have been putting off because we could 'always do it later'. :-)

Regards, Simon Richards

-- Simon Richards (simon@wair.com.au), May 01, 1999.


I'm a nonprogrammer but am compelled to think about what the apparent lack of early failures might mean. Some ideas: 1. The real-life damage done by failures in most one year look-ahead systems, even if not corrected, would not occur until one year later. 2. The lack of evidence of serious failures is not due primarily to good remediation efforts. In many parts of the world, remediation efforts have barely started. 3. $1-$2-trillion false alarm? Nothing needed to be fixed in the first place? 4. Why did nobody mention Gartner's graph of "Failures-How Many and When?" at http://www.senate.gov/~y2k/hearings/030599/gartner.html I was surprised to see about a fourth of the failures projected for 1999. Where did they get their data? For the reason stated in number 1 above, I would expect a one week look-ahead failure to be far more important than a six-monther. 5. For the same reason, we might do better at conceptualizing things if we're seeing (in our minds) graphs of real damage timetables rather than graphs of the timing of failures that will lead to that damage.

-- Bill Byars (billbyars@softwaresmith.com), May 01, 1999.

Hi Sysman,

Aren't you belaboing the obvious? Rules of triage would have any shop deal with most critical first. Seems to me you are putting forward the necessary order that any intelligent manager would follow and is therefore a given.

I will suggest that at this point in time, actual Y2K problems almost become irrelevant because awareness has now created a self fullfilling prophecy. Individuals and businesses are aware, they are modifying purchasing schedules and stocking up. (Personally our PC replacement schedule has been advanced to circumvent non compliant hardware issues - this means that 250 PC's sheduled for replacement in 2000-2001 will be replaced before the end of the year. I know of other business that are doing wholesale PC replacement this year). These actions create abberations in the economy both now and more notably next year.

If Y2K happens and causes problems - the inventories that companies are building will be used to mitigate the Y2K disaster anticipated by JIT failures. If Y2K doesn't happen the inventories that companies are building will cause economic disaster as the JIT is waiting but has no demand for delivery.

The stage for the self fulfilling prophecy is set. Regardless how it shakes out, it will be unpleasant.

Just my thoughts.

Good Luck. jh

-- john hebert (jt_hebert@hotmail.com), May 01, 1999.


Sysman,

Okay, we've established that we both can be irritable.

There are several statements in your original question posting. Some are not factual. As far as I can tell, the statement(s) which is(are) your intended antecedent(s) for "this" is(are) in the not-factual category.

-- No Spam Please (No_Spam_Please@anon_ymous.com), May 01, 1999.


OK No Spam, thanks for your input, and I'll note your comment. Not sure yet what I'll do with it, but it is noted (grin). Have a nice weekend dude. <:)=

-- Sysman (y2kboard@yahoo.com), May 01, 1999.

TECH32,

>Clearly you don't 'Get It'.

Does this mean I have to take back all those copies of TB2000 I handed out to relatives and friends last year, and divest myself of my bartering hoar-- oops --stockpil-- oops -- anticipatory acquisitions of Charmin?

>If a new type of flu started killing people across the country, who would you believe:

(... thought this thread was about software inventory facts and logic ... but I'll play along ...)

>A) the doctors who are scared sh*tless because if it's not cured in the first 24 hours, the patient always dies

Assuming your premise, and assuming that you're implying that those doctors are _saying_ "We're scared sh*tless because if it's not cured in the first 24 hours, the patient always dies", then the doctors are believable.

OTOH, if the doctors are saying "No problemo" while sweating bullets and shaking in their smocks, then no, they aren't believable.

Uttered words might contradict body language, in which case the body language is generally the more believable of the two.

>or >B) the HMO spokesperson who says 'there is no flu problem so you don't have to prepare by getting those new expensive flu shots'.

Since the spokesperson's statement is inconsistent with the assumed premise ("... a new type of flu started killing people ..."), that statement is not believable. As long as it seems that the spokesperson is trying to convince the listener that the statement is true, then the spokesperson is not believable.

>Would you disbelieve the doctors simply because people weren't dying fast enough early on to convince you to get your shot?

No. It would have to be more complicated than that.

(Is this supposed to be connected to any earlier posting on this thread? Just wondering?)

>ALL (sorry, forgot caps annoy you)

Only in certain contexts. This one doesn't qualify. :-)

>All of the programmers I know are very concerned about Y2K. See, we all know what a complete friggin' mess most systems are. We all know that 'opening up the code', particularly on older systems, always increases your chances of introducing new errors, both subtle and not so subtle. We all know just how difficult it is to get data transfers worked out between departments, let alone our 'strategic trading partners'.

So, tell me something new.

>By the way No-Spam, those are all 'facts' that any seasoned programmer can confirm.

Well, there's a majority content of opinion there, but if your quotes around "'facts'" conveys irony I won't complain.

>The Y2K problem is fixable and if everyone had started two years earlier I wouldn't be concerned at all.

_I_ would be, but less than now.

>The majority of companies only started looking at the problem in mid-late 1998 (care to dispute that?).

Judging by what I read and heard, mid-late 1998 is probably right. The company I worked for in 1991 started its formal Y2k program that year (or earlier - I wasn't in on the management meetings). I don't know whether they got started internally or because some of their customers (e.g., Visa and Mastercard) pushed them.

>Sorry No-Spam, but that just doesn't leave enough time to get it all fixed 'correctly' ('correctly' being much harder than you might imagine).

You sure do have me mixed up with someone else, don't you?

Why should getting it all fixed 'correctly' be much harder than _I_ might imagine?

-- No Spam Please (No_Spam_Please@anon_ymous.com), May 01, 1999.


OK, Sysman, I'll bite.

First of all, the fact remains that Ed Yourdon, Cory Hamasaki, Capers Jones, Gary North (though he's not a programmer) and plenty of others made clear predictions about what would happen, and those predictions have failed utterly. I don't understand why you're so interested in proving that you know more than them, but hey; that's your perogative.

Second, you -- once again! -- demonstrate the usual Doomer's penchant for shooting your own argument in the foot. The vast majority of all computer calculations are NOT date-sensitive to start with; if we start digging and displaying numbers here, you're sunk anyway, and you know it.

Third, it depends on the business, anyway. I'm not going to waste time digging up numbers, because common sense should suffice.

In insurance, look-aheads are common. Every agent who has written an annual policy since January, 1999 has relied on software that looks ahead. (Did you even think of that?) Experience modifiers and dozens of other calculations also involve look-aheads. In insurance, in fact, look-aheads are probably the most common date-sensitive calculations.

Why have there been no serious Y2K catastrophes in the insurance industry? (I wait with bated breath for Cory to mention again -- for the nth time -- that little company in Washington state.)

In banking, look aheads are also a very common date-sensitive calculations, because banks loan money, and the interest must be correctly calculated well into the next millennium.

So, you're left hoping that third and fourth-quarter reports will somehow bring on The Collapse. The field keeps getting more and more narrow.

Why you think this "challenge" will make some earth-shattering point escapes me. This is as meaningless as Cory's challenge to find a mainframe Polly to write for his little newsletter.

Fortunately, the average Joe is finally starting to see through the smoke and the handwaves. Just today, I received a copy of a panicked letter from a Y2K misinformation vendor warning everyone who sells supplies: people are starting to RETURN this stuff! You'd better get signed contracts first!

Heh.

The Y2K Doom and Gloom movement is dissipating, and fast. Face it.

-- Stephen M. Poole (smpoole7@bellsouth.net), May 01, 1999.


sysman, maybe lookaheads aren't a problem where you live, but they are a problem in my neck of the woods. my hubby works for a computer services company, is their CAD/CAM specialist, lots of clients have had problems with lookaheads. if i remember rightly, a bunch of them are using MRP and Realworld and other weird stuff, which isn't and won't be compliant. they ran into problems in january and february, called my hubby and he told them to change their forecasting timeframe so they are still within 1999, and to change software as soon as practicable. it worked temporarily, but these people are running out of time, and a number of them still don't know what they are going to do.

the local Purchasing Management Association also reported a number of businesses with the same problem. the point is that they told US, they are not out there talking to the press and reporting it. why would they do that?

-- jocelyne slough (jonslough@tln.net), May 01, 1999.


jocelyne,

That depends on what they're looking ahead to. If they just need to make forecasts, tell 'em to buy an Apple with the latest spreadsheet software. :)

-- Stephen M. Poole, CET (smpoole7@bellsouth.net), May 01, 1999.


I have been programming for ten years, most of that time for banks.

I think that the "look ahead" problem is a small facet of Y2K. The premise that date calculating programs get first attention, is in general correct, although we (ING Bank, Holland) are still in the process of replacing some of our faulty date routines. Bank have been meeting Y2K problems for at least 7 Years now (Credit card expiry dates ).

How many programs do "Look back" functions ? 00 - 99 gives rubbish ! That is the area that is really going to give problems in Jan 00.

-- Ian Phillips (iphillip@solair1.inter.nl.net), May 01, 1999.


"Second, you -- once again! -- demonstrate the usual Doomer's penchant for shooting your own argument in the foot."

LOL! Stephen, in this case the guy blew his whole leg off - maybe with one of those pump-action shotguns that seem to be a doomer's standard equipment.

-- Computer Pro (first_minister@hotmail.com), May 01, 1999.


Moderation questions? read the FAQ