The following is an excellent post by Cory Hamasaki on remediation schedules. He is a bonafide, double beanie geekster with a Phd from Codehead State University. For those of you who don't know about him, I suggest you read his Washington Weather Reports. This is a guy on the front lines. http://www.kiyoinc.com/current.html

ubject: Re: Washington Water Power Date: 20 Oct 1998 20:35:33 GMT From: kiyoinc@ibm.XOUT.net (cory hamasaki) Organization: HHResearch Co. Newsgroups: comp.software.year-2000 References: 1 , 2

On Tue, 20 Oct 1998 13:43:22, karinoliver@my-dejanews.com wrote:

> When a company remediates for Y2K they assess, repair, and test. All these> articles that I've been reading say that they plan to finish their> remediations this year and do testing next year.

They're just funning with you. The people in IT know that it takes a long time to implement, test, fix bugs, reimplement, retest, etc. the systems so they picked a very long period of time for the test cycles, a full year.

That's why the code is supposed to be fixed by December 1998. December 1998 is magic because we think of a year as a long time and everyone knows it will take a long time to test the code.

The problem is, some systems take two or three years to implement and shake down, others take only 3-4 months.

There's no way to really tell but I've seen large packages, documented, shaken down by multiple other installations, take more than a year to drop into production.

There are people who study these issues in the abstract, Capers Jones, Larry Putnam, Ed Yourdon... I'm a hands on code-head, I'm the guy with the sledge hammers called ASMH, IFOX00, AMASPZAP... I can blow in to a shop, chat it up with the other gear-heads, PDSUTIL the libs, IDCAMS print some files, AMBLIST the libraries and tell you whether the system will make it or not. I might run GTF one morning, take a look at RMF but in a couple days, I'll know if you're burning up the CEC, outa MIPS, pedal to the metal or if things are mismanaged. > Now it takes a set amount of time to do the actual remediation, correct? If> upon testing, you discover that you haven't caught everything, and it still> goes blooey, then don't you have to do the remediation again? Granted, you > won't have as much to rewrite, but you still have to find it. I would think,> then, that the time allotted for testing would have to be at least the same> time period as for the remediation, if not twice as much, just to be safe. > If you managed to catch everything, you'd be fine, but how many remediation> projects in IT exist where that has happened? So basically, that would mean> that unless everyone is suddenly blessed with perfection, chances are we're > screwed.

Yes 'n no... the done by December 1998, leaving all of 1999 for testing is an artifact of the public relations people and the idiots in the corner office. Don't take it to mean anything.

Here're the facts. In large complex systems, you don't know what you'll find when you pop the hood. The job could be smooth or it could be a horrid mess. The really bad problems are very likely just surfacing now. These are lost source code, code that resists modification, dates in VSAM keys of terabyte files... or be still my heart, BDAM with date keys and assembler XDAP IO... or how about RSCS mods.

There are shops with source tied to old compiler versions and operating systems. Upgrading any part will force upgrades of other components. There have been a couple cites of these cascade upgrades in c.s.y2k.

If the shop is lucky, and they started a couple years ago.... and they're actually sliding the last brick into place this December 1998. They might be able to complete their testing in 1999. That's assuming that they have their time machine, that the staff doesn't bail, and there are no fundamental conflicts uncovered in testing. .but it's a matter of the luck of the draw now...

> I am not a programmer, so perhaps I've made some assumptions that are > incorrect, and I welcome any programmers to correct my thinking in this> matter.

You haven't really made an error... other than, maybe, buying into the idea that the schedules mean something. In general, not enough time was allocated, the schedules are unrealistic, and the work will not be done.

There are a few companies that are in fair shape. I'm tracking a few that should make the deadlines. I expect the December 1998 and January 1999 time period to be very interesting.

cory hamasaki 437 days, 10,496 hours. 

-- R. D..Herring (drherr@erols.com), October 20, 1998

Answers

Nice catch, RD.

Here's the site I use to keep track of Cory's WCD Weather Report. http://www.sonnet.co.uk/muse/dcwrp.html

Besides being very informative, they sure are fun reading.

Hallyx

"Human beings, who are almost unique in having the ability to learn from the experience of others, are also remarkable for their apparent disinclination to do so." --- Douglas Adams

-- Hallyx (Hallyx@aol.com), October 21, 1998.