A small lie - an examplegreenspun.com : LUSENET : TimeBomb 2000 (Y2000) : One Thread
A while back there was a thread to check out your states compliance with Y2K, and I finally got around to doing it.
Wisconsin says it has 98% of systems inventoried (that will need evaluation - says 68% of those have been evaluated). How come, then, in my hot little state employee hands, I have a document from our Y2K coordinator (3/8/99) that says we will "begin inventoring all possible Y2K vulnerable equipment and software" ... "very soon". Even I, a state worker, am not a total fool. I know our State Office in Madison has done a little (maybe 30 - 40 %), the regions of my agency have done NOTHING.
So you DGIs don't have to tell me anything. I KNOW.
-- Jon Johnson (firstname.lastname@example.org), March 17, 1999
Some of the regulars may remember my ranting throughout much of December about the absolute bogosity of compliance percentages (mind you, in both directions, I'm convinced that a few are further along than reported).
The reasons they are bogus are almost inexhaustible:
... no standards in IT for metrics generally
... one person's guesstimate/analysis of progress is diff than anothers'
... IT projects routinely move in both directions (back as well as forward: see FAA as example)
... communications are generally recalced in more optimistic directions as they move up the mgt food chain
And so it goes. I stopped ranting mainly because I got bored of that dimension of the problem. I take their emptiness for granted, most don't. Thanks for the "from the front" update.
-- BigDog (BigDog@duffer.com), March 17, 1999.
Yeah Jon, know whatcha mean. Yesterday I go to the NASIRE website, the organzation that representing the chief information officers of the states, to get their read on my states, Alabama, readiness. According to the Chief Info officer of Alabama, 28% of the work is done. NOW, I go to the "State of Alabama" website, they report 60% done. jeezzzzz. Rusty2k
-- Rusty (email@example.com), March 17, 1999.
If the statistics were given (not as percents only) but with date, nbr systems, nbr critical systems, nbr complete assess, assessment complete date, nbr completed remediate, remediate complete date, nbr completed testing, scheduled testing complete date, total budget, total spent to date, nbr people programming, total people assigned.
IF these were reported, then you could track, and hence trust the figures aas they improve over time, or get suspicious (when too many systems get reclassified from critical to non-critical. Or when thousands of systems "disappear" from the ledger, hence improving the percent complete as schedule dates get closer.
I have a sneaky feeling that this much information is not known to the federal, state and local Y2K managers, much less the public.
-- Robert A. Cook, P.E. (Kennesaw, GA) (firstname.lastname@example.org), March 17, 1999.
All excellent examples of why my favorite Y2K descriptor is, "Crapshoot". . .
-- Hardliner (email@example.com), March 17, 1999.
My favorite is Cory's "the truth isn't out there".
-- anon (firstname.lastname@example.org), March 17, 1999.
This is a valuable insight, even if it is disturbing.
Please keep posting with updates if and when you are able.
-- Watchful (email@example.com), March 17, 1999.
Robert --- "I have a sneaky feeling, ...". I agree. The data you cite AREN'T collected (remember, data is plural), so how can it be reported. There are a few amazing exceptions, amazing against the backdrop of the mass.
The only thing the gov has access to that we don't are key "seat of the pants" evals by people they trust ("this is hosed." "this is going to be okay.") Even here, "trust" has to be put in quotes.
We're probably as knowledgeable about the USPS status with the audit report and nine's reporting, for instance, or nuclear power with you/others as they are.
But, psst, let's bring everyone in on the BIG secret (Robert, you already know it): without the kind of data collection you detail (no, it doesn't have to be perfect, just reasonable), a worldwide, systemic problem like Y2K CAN'T be fixed but could very well be made worse IN THE END.
We're just about to pass the most optimistic point in the process. Everyone is 80-90% there. Sure, take that at face value. But what does it mean?
Translation: all the easy stuff has been done, just like with any IT project, because that's how we work in this here profession, see? We're breaking out the cigars. We've told mgmt, no sweat, you can get rid of those pesky auditors and outsourced creeps. It's under control. Done.
Well, allllmmmmoooosssstttt done. It's just a small matter of programming. Testing. Staging.
The END GAME. Deja vu.
-- BigDog (BigDog@duffer.com), March 17, 1999.
Well put, BigDog.
Based on my experiences, the easy stuff gets accomplished first to show that progress is being made.
I'm not sure if it's human nature, or a defacto standard in this industry. To me, designing a system is the easy part...as for implementation and testing, that is the hard part.
Just my .02...
-- Tim (firstname.lastname@example.org), March 17, 1999.
My experience is that if the designing isn't considered so easy, then the testing isn't considered so hard.
-- Flint (email@example.com), March 17, 1999.
Here is an example of doing the easy stuff first.
A few days ago one of our servers crashed, first of all I tried to fix it remotely but after 15 mins I knew I wouldn't be able to. So I jumped in the car and travelled to the office, I spent the next 2 hours or so trying to fix the hard drive errors.
After two hours I realized that the system would have to be rebuilt so I made some modifications (15 mins worth) so things would function normally (ie the other servers are now taking up the load for the time being). I went home (being now approx. midnight).
We are now into the second day of rebuilding that particular server, several hardware components have been replaced and now we are rebuilding the OS (Linux in this case) all the hard drives have just been formatted and we are now at the beginning of installation of Linux. We still have another day or so to go before the machine will be ready.
So to the outside world we are 99% fixed as the rest of our machines are functioning normally doing all their required tasks. :-)
And this is fix on failure, an easy job of approx. 3 days worth of work that requires no fixing of code. If we needed to fix the code then it would probably stretch to a week for a minor code problem.
-- Simon Richards (firstname.lastname@example.org), March 17, 1999.