Some thoughts regarding the Joann Effect.

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

I think that the lack of serious problems on the trigger dates from the "Joann Effect" in other countries warrants some further discussion. The lack of reported problems from foward looking software that was so intensly anticipated in April seems to have been the mechanism that brought a near halt to Y2K awareness, and in some cases preparation. It also brought a host of Pollies to this forum screaming that finally there was justification of their cause. Mr. Yourdon in particular went far out on a limb on this issue. I was intensly disappointed in Mr. Yourdon's explanation of the failure in his predictions. "Grumpy Mood" simply does'nt cut it on an issue as complicated and emotional as Y2K. I would have been quite interested in a thorough analysis of his missed predictions from Mr. Yourdon. In my analysis of this lack of failures there are three possible explanations.

1) Remediation in the U.S. and abroad is going quite well. The critical programs that look ahead were remediated first. Corporations and Government reports are pretty much on track and honest.

2)Remediation may or may not be going well. It was simply very easy to patch, roll back look ahead dates, or whatever. Systems in countries that have yet to be remediated may have been handeled in this manner.

3) Y2K is simply not the boogie man that it has been made out to be. Non remediated systems are still workable and will not become usless. Fix on failure is resonable and workable.

From my studies regarding Y2K, It is fairly universally agreed upon that there are many countries that are far behind the U.S. in the remediation game. These countries simply should have had a higher incidence of look ahead failures than the U.S. For some reason, from which I have not read a convincing analysis, these countries suffered no more failures than the U.S. I look foward to reading some responses from people who are on the front lines of this issue.

-- Dr. Albert Estevez (alvez@aol.com), June 25, 1999

Answers

You may be correct, however, I would point out that many such 'JAE' problems can be easily hidden. Indeed, most companies do not discuss their problems openly. This is standard business practice regardless of Y2K.

I do have personal knowledge of one such 'JAE' failure that occurred in a fairly large organization at the begining of this year. The result was that the organization could not process credit card payments for 6 weeks until the source of the problem could be identified and corrected.

I cannot disclose more than this without potentially putting the source of my information at risk, so you may want to simply chalk it up to 'anecdotal evidence' or dismiss it out of hand. However, the bottom line in this is that no one's life was put at risk by the failure and the problem did eventually get corrected. The organization in question was able to weather the 6 week processing outage with minimal visible impact. I suggest that many businesses that operate on thin margins would be devastated by a 6 week outage of credit card authorizations.

In this specific example however, the failure occurred at a point in time where the resources required to address the issue could be marshalled. The result was that the problem occurred, was corrected, and, except for those working there and few people like myself, the problem did not receive what the organization would have characterized as 'undue exposure'. I haven't seen any hard data but what I would like to know is this: Of the entire set of systems susceptible to Y2K problems, what percentage of those are susceptible to JAE effect? Obviously, accounting systems fall under this subset but what percentage this subset constitutes is not known to me. Perhaps with some rough numbers, some general conclusions could be drawn.

If the majority of problems which do occur, occur under the circumstances described above, this will be a good thing. After all, if a problem can be hidden over the long term, it is not likely to have serious global consequences.

Also, as has been pointed out by several other participants here, the longer the time frame that you can spread all Y2K problem over, the less likely we are to be overwhelmed by cascading events.

We shall see.

-- Arnie Rimmer (Arnie_Rimmer@usa.net), June 25, 1999.


or 4) The overwhelming majority of software is concerned with past dates (recording transations, etc.) or current time (most imbedded systems).

And 5) Most organizations have far less than a one year time horizon. A more substantial set of failures will happen when systems attempt to take orders for year 2000 delivery dates, schedule manufacturing or shipping for next year, etc. Given Just-in-time processes, this could be very late in 1999.

And finally, 6) It is never in the interest of any organization to call up the news media and annouce failures. Unfortunately, the news media are not even bothering to check if deadlines have been met, or if systems that were failing (state unemployment systems) are still failing.

-- Michael Goodfellow (mgoodfel@best.com), June 25, 1999.


I select door #2--and also doors #4, 5, and 6. It's not that difficult to hide many "back office" problems--at least up to a certain point. Reportedly, programs that look ahead one year account for only about 3% of corporate software. And you're right--these programs probably were fixed first.

There's a reason why it's called the "Year 2000" problem.

By the way, both Capers Jones (founder of SPR and the world's most respected expert on software metrics) and the Princeton Economic Institute (one of the world's most respected economic think tanks) have discovered that there have been significant problems this year with the Euro conversion. (Some banks have taken up to four weeks to process transactions that should have been done by day's end.) Heard much about that in the mainstream press or from govt. and financial leaders? I think not.

I don't know what is going to happen next year. But I think it is too soon for anyone to proclaim that he/she does know. I've researched this problem with periodic intensity for the past 14 months (including reading lots of "official" documents) and have studied the arguments and alleged evidence of "experts" from the entire spectrum of Y2K opinion--and I have yet to discover any sign of divine (or even semi-divine) wisdom. Just discovering occasional documented, incontrovertible "facts" seems to be miracle enough. But if you want "speculation" a-plenty, well, Y2K discussions and the stock market are the places to be. Y2K debates seem to be the breeding ground for attacks ad hominem, argument by assertion, non sequiturs, overgeneralizations, and a host of other delightful logical fallacies. For those of us blessed/cursed by not being mainframe programmers or systems analysts, Y2K has certainly been a trip through the looking glass.

-- Don Florence (dflorence@zianet.com), June 25, 1999.


"Y2K debates seem to be the breeding ground for attacks ad hominem, argument by assertion, non sequiturs, overgeneralizations, and a host of other delightful logical fallacies."

-- Don Florence (dflorence@zianet.com), June 25, 1999.

I see you've been reading a lot of Mr. Decker's posts. . .

-- Hardliner (searcher@internet.com), June 25, 1999.


There is a world of difference between programs in June, 1999 that look ahead to 2000 and real computers in real time 2000 next year. The Joanne effect has always been a very minor part of the whole y2k problem. It's what happens when the computers and their programs are actually in the year 2000 that matters.

-- cody varian (cody@y2ksurvive.com), June 25, 1999.


Wasn't there a high profile issue with unemployment compensation regarding "look ahead" systems? I believe they "fixed" it by artificially terminating all benefits on December 31, planning to reinstate them after a real fix was made. It bought them time. I wonder if such might also be the case with some long term disability insurance systems that were not prepared. One would not see the effect because of the bandaid approach.

There are a lot of look-ahead systems other than accounting. Most would probably be license and tax systems with a due or call-up date after December 31. Since the call up has yet to trigger, we don't know how it would be effected.

-- marsh (armstrng@sisqtel.net), June 25, 1999.


Here's another recent thread on the Jo Anne Effect...

http://www.greenspun.com/bboard/q-and-a-fetch-msg.tcl?msg_id=000wgU

"For the record: Your July 1st predictions, please"

-- Linkmeister (link@librarian.edu), June 25, 1999.


The Jo Anne Effect refers to problems a company may have when attempting to roll over their accounting (general ledger) software to fiscal 2000. Some problems might occur if the fiscal year spans two calendar years.

I've always figured that the easiest "work-around" for this problem would be to just temporarily set the end of the fiscal year to December 31, 1999. Most software should be able to handle this type of change in fiscal year-end. When the end of 1999 rolls around, the company can then specify a new year-end that would include only the appropriate months in the year 2000. A bit of manual work would be required to combine the two "shortened" years.

Example: Your fiscal year-end is March 31. On April 1 1999, you tell your software that December 31 1999 is the fiscal year-end. Then, on January 1 2000, you tell your software that March 31 2000 is the year-end. You manually combine the two periods to get "correct" figures for the whole year.

It's a bit more complicated than this, obviously, but the amount of extra work involved could probably be handled by a few accountants.

As has been stated numerous times, The Jo Anne Effect was never expected to have earth-shattering repercussions. It's just a slightly interesting, possibly obscure, symptom of a much larger problem that may hit us in six months.

That mole on my arm doesn't look like it would cause any problems, either.

Jo Anne

-- Jo Anne Slaven (slaven@home.com), June 26, 1999.


marsh,

Here's an article on how some state unemployment insurance systems were "bandaged" so they could work in January 1999:

[for educational use only]

[snip]

13 States, District Face Y2K Problems

Unemployment Checks May be Slowed

By Stephen Barr

Washington Post Staff Writer

Wednesday, December 23, 1998; Page A03

Thirteen states and the District will have to put electronic bandages on their computers next month so they can pay new unemployment insurance claims into the year 2000, Clinton administration officials said yesterday.

The federal-state unemployment program provides one of the first large-scale examples of the problems caused by the "Y2K bug." Computer experts have warned that payments for billions of dollars in Medicaid, food stamps, child welfare and other federal-state benefits could be at risk because surveys have shown that states are moving slowly on the Y2K problem.

Many of the computer systems in the unemployment insurance program, which processes claims, makes payments to the jobless and collects taxes from employers, are more than 30 years old. The systems processed more than $20 billion in state unemployment benefits in fiscal 1998 and provide crucial data on economic trends.

Persons filing claims for jobless benefits are assigned a "benefit year," which means that -- starting Jan. 4, 1999 -- unemployment insurance systems will have to be able to process dates and calculations that extend into 2000. Y2K problems may occur when computers next month try to process a first-time claim with a benefit year that covers both 1999 and 2000, officials said.

Some states that have not solved their Y2K problems will use a simple temporary fix, such as ending all benefit years on Dec. 31, 1999, while other states will use different techniques that essentially trick the computers so they will perform accurate date calculations, officials said.

If the computers are still not ready to operate on Jan. 1, 2000, states then will rely on emergency backup plans, including the writing of benefit checks by hand, officials said.

John A. Koskinen, the president's adviser on Y2K issues, and Deputy Labor Secretary Kathryn Higgins yesterday stressed that the nation's unemployment insurance system would not suffer serious disruptions.

"A year out, we know where our problems are. . . . It's an enormous help to have that information," Higgins said.

Koskinen pointed to the contingency planning for jobless benefits as a clear sign that the government will be able to maintain important services and programs, even if computer systems encounter Y2K problems.

[snip]

Labor Department officials listed Arizona, Connecticut, Delaware, the District, Hawaii, Illinois, Kansas, Louisiana, Massachusetts, Missouri, Montana, New Hampshire, New Mexico and Vermont as lagging on Y2K repairs. Puerto Rico and the Virgin Islands also are running behind schedule, the officials said.

Delaware, according to the Labor Department, will not have all computer systems converted until the last possible moment: Jan. 1, 2000. But state officials said the most critical systems have been fixed and suggested that even experts can disagree on how to assess Y2K readiness.

The District should have its unemployment system fixed by March 31, the Labor Department said.

Overall, the repair bill could run to $490 million for the unemployment insurance systems, according to preliminary estimates.

) Copyright 1998 The Washington Post Company

[snip]

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

-- Linkmeister (link@librarian.edu), June 26, 1999.


My experience has been that problems have occurred, but aren't being publicized. Work arounds are being applied while patches are being developed. On one critical planning system which I am directly familiar with: things are being handled manually while waiting for the patches...but this cannot continue much longer without causing a major manual effort.

-- Mad Monk (madmonk@hawaiian.net), June 26, 1999.


Gawd, I just wish something new would happen so Kevin could come up with a new 'really long, stale, old post' to bore everyone with.

-- Bored GI (bored@with.thisforum), June 26, 1999.

As far as the JOE, I have a personal example. Last month, I was late on my car insurance payment, so opted for their pay-by-credit-card option, to avoid the late fee. After punching in my info, then playing back for confirmation, the recording stated my expiration date was January 1, 1999, rather than January 1, 2001... this works for now, but how long can these patches hold, ie., disabling date validation?

I'm in the PeeCee biz, working on remediating those SME's that actually have the money to do something... another JAE that worries me is why companies like Cisco patch their routers and bridges by disabling date validation to jump over the leap year problem... not even fixing the date masks... chicken wire and bubble-gum code has kept the look-ahead systems alive, and is being used to patch real- time systems, but sooner or later, they have to be fixed... for real...

Hate to burst your bubble doc, but we've been slapping bandaids on a pipe that's building pressure by the minute... and the bandaids are starting to slip...

The "look-ahead failures" have been happening, nobody wants to advertise until senior management can sell off their stock options...

Carl

-- Carl (clilly@goentre.com), June 27, 1999.


This is about vehicle registration renewals in Honolulu:

http://starbulletin.com/1999/06/26/news/story7.html

[snip]

There are no delays -- in fact, one-day processing is standard -- for mailed vehicle registration renewals, but that is an area where the Y2K bug raised its ugly head. Manual processing has been under way since Jan. 1 because "the system has been rendered unreliable by the Y2K problem."

The staff is working after hours to achieve the one-day processing goal, resulting in unbudgeted overtime costs, the auditor found.

[snip]

-- Linkmeister (link@librarian.edu), June 27, 1999.


Moderation questions? read the FAQ