# # # 19981109 -- This is all true, folks! Read it ... then weep!!

An open, real life Y2K challenge:

Tell me why I should not shoot down this software vendor on their perception of their application's alleged Year 2000 compliance?

Scenario:

Application: Financial ( ~250 total customer-base ) ( Attorneys & Financial Agencies )

Platform: Windows NT; NetWare; UNIX(!)

Y2K Testing: Done 2 years ago; no test scripts; no records; unaware of process. Tested 1/3/2000 and 2/29/2000. ( Claimed he will check ITAA [ at my suggestion (!) ] for Y2K testing/ methods/processes/practices. )

Windowing: <=40 == 20xx; >40 == 19xx; EDI == { any pivot they want(!) }

Language: "Business Rules" ( underlying languages: SYS36; 'C' -- couldn't provide flavor )

Tools: Compiler, Configuration Management, libraries, drivers and utilities not Y2K-tested.

Future Interest Calculations: Avoided response by diversion.

Future of Product: Claimed intentions of changing development base next year!!

Release of Y2K-compliant Product: 1.) Letter to customers: 02/99

2.) Telephone call by Yours Truly (on 10/14/1998): 04/99

3.) Today's interview: "I could release it today, but user manuals are not completed. ... 01/99

Characterization of Interview/ee:

Bewildering telephone conversation/interview.

Interviewee OVER-compensating for exposure of prima facie lack of process and vulnerability this application system presents, with LOUD, BOISTEROUS ( as a diversionary tactic ) incantations of, "We are very confident that this system will handle any date computation after the roll-over past 2000."

Does anyone have a clue as to why I should not, in the strongest of terms possible, advise my client that US$22,000,000+ ( a significant proportion ) of their annual revenue generated by the user/service provider base business partners is at GREAT, PERILOUS JEOPARDY if this application is not RAILED UPON? ... Yesterday?!

My advice to my client will be to issue the STERNEST, STRONGEST WARNING(S) POSSIBLE to the user-base of this application: BAIL OUT, BEFORE END OF 1Q1999 -- OR ELSE! -- LOSE YOUR "FRANCHISE!" ( While my client still has a window of opportunity to do so before 01/01/00! )

This experience demonstrated the old canard of say it ( we're Y2K-compliant ) loud enough and it ( the lie ) has got to be accepted as true.

Is there ANYTHING I can look to in this pile, that could possibly mitigate Y2K-RISKS this product presents to the user-base and [ up | down ]stream business partners?

Any guesses as to why the Year 2000 melt-down will NOT precipitate the greatest tragedy that human civilizations will likely ever experience?

The challenge: What would you advise? ...

ANYONE?!? ...

Regards, Bob Mangus

"I'm a computer 'Y2K-bomb' technician. If you see me running, try to keep up." RMangus

"Sometimes a majority simply means that all of the fools are of one mind." [Author Unknown] # # #

-- Robert Mangus (rmangus@mail.netquest.com), November 10, 1998

Answers

I often think of Lyndon Johnson's heartfelt remark, in 1965, when all his advisers were telling him that Vietnam was about to collapse:

"I feel like a hitchhiker caught in a hailstorm on a Texas highway. I can't run, I can't hide, and I can't make it stop."

-- Tom Carey (tomcarey@mindspring.com), November 10, 1998.

Not that I know much about this things, but if the vendor is loudly claiming they are Y2K ready, I would think that you could have a lawyer draw up some "insurance" type paperwork to the effect that if in fact the vendor's product fails due to Y2K problems, then they will pay your client $xxxx.xx per day until the problem is resolved. If nothing else, attempting that approach may cause a more responsible discussion of risk mitigation.

-- Jack (jsprat@eld.net), November 10, 1998.

Robert, you say you are a Y2k bomb technician. That's a neat title. I am wondering what it is you do in the way of helping your clients. Does a Y2k bomb technician just make phone calls to vendors? Don't wait for those idiots to respond. Test the damned software yourself. In fact, regardless of what the vendor responds, you should test it yourself. Now, get your ass in gear and earn the money you are being paid as a Y2k bomb technician. Prove this stuff works or doesn't. If it doesn't then get on with business of installing a replacement system. This ain't rocket science mister Y2k bomb technician, it's just work. Sometimes consultants are put in a position where they have to sell more than just their gift for gab. You won't assure your clients Y2k readiness by simply calling vendors.

-- Woe Is Me (wim@doom.net), November 10, 1998.

Answer to Jack:

You wrote---------- Not that I know much about this things, but if the vendor is loudly claiming they are Y2K ready, I would think that you could have a lawyer draw up some "insurance" type paperwork to the effect that if in fact the vendor's product fails due to Y2K problems, then they will pay your client $xxxx.xx per day until the problem is resolved. If nothing else, attempting that approach may cause a more responsible discussion of risk mitigation. ---------------

The real difficulty with that approach is that when the vendor's product fails, it fails for everyone they sold the product to. The bottom line is that the vendor probably goes out of business and there are so many claims that there is not enough money to go around. It's no use some company owing you money if they go out of business.

-- Craig (craig@ccinet.ab.ca), November 10, 1998.

To 'Woe is Me'

I found Robert's posting to be very useful. Obviously he is not compelled to report every aspect of what he does for his clients to this group. I suspect, from the details of his postings, that he does have all the bases covered and fully provides the services he has been paid to do.

I also suspect, from the tone of your posting, that some bugger pissed in your cornflakes this morning! Come on, lighten up just a bit.

-- Craig (craig@ccinet.ab.ca), November 10, 1998.

Craig, thanks I needed that. Your'e right some bugger did the equivalent of pissing in my cornflakes. You are also correct that Robert's information was useful and I probably assumed too much. Robert, my heartfelt apologies - please keep up the good work. I have one system outstanding due to vendor delays and I don't have the source code. Consequently I have already designed a rudimentary replacement system on which we will begin programming in January if the vendor has not delivered by then. If there was a point to my previous post it is this: Anyone still at the mercy of vendors should be making plans on the assumption that they won't deliver because many of them won't. Another problem inherent in the vendor delays is that they may complete their efforts too late to be of use to much of their installed base. For example, if they finally deliver in summer of '99 and the whole customer base is trying to upgrade at once then the vendors support staff will be overwhelmed. In small companies there is still time to consider new systems and their are plenty of vendors anxious to come in and replace the old stuff. In some cases you might be able to utilize encapsulation to keep the old system alive. In other cases, you might find that you can live without the historical data in the early months of 2000 and you might just start the system over with new files in January 2000. After all most of the problems involve data arithmetic so many will function fine in 2000 if they don't have any data from 1999 to look back at. There are scores of approaches to Y2k solutions and within any organization you may use several. You guys have a great day and keep plugging, there is light at the end of the tunnel.

-- Woe Is Me (wim@doom.net), November 10, 1998.

Test it yourself -

Look at the "undocumented" test dates referenced: 1/3/2000 and 2/29/2000. Great it will work twice, and it (or the PC (NT right, what about Unix version(s)?) recognized that there was a "day" for Feb 29, 2000.

So what will it DO on those day(s)?

Get the actual working machines and op systems that will be running the application. (Unix-compiled programs will be different than NT-compiled programs, and both may vary with different op system versions - particularily since you ar ereading/using system dates), and the PC/Unix boxes at your office will be different than at clients office.

Try month-end calculations , billing, receipts, payroll ?, hours/billing ? entries for the first three day period in Jan (1999 -> 2000 conversion of information), a middle of Jan period, and the month-end of Jan - Feb 2000.

Then try the same (if those work) for month-end (and all other modules) for Feb-Mar conversion. If those work, rest of months "probably" will.

Then try quarter-end reports and changes for Mar-Apr 2000. Are monthly reports still good? Can "new" accurate lsitings and clients be added, deleted, edited? Changed modules could freeze information, and screens (data entry) may reject "new" information, while displaying existing data correctly.

If you don't have a current test results database, create one (I use Winnovations IssueManager to track problems, resolutions, test results, re-test results, to-do's, got-done's, closed items.) Use a screen capture to document data-in/data-out problems and error msgs.

Did I forget anything? QA me! I don't know your application, so I can't be very specific.

-- Robert A. Cook, P.E. (Kennesaw, GA) (cook.r@csaatl.com), November 10, 1998.

I agree with Robert's excellent suggestions. Test a half dozen relevant things. If its as obviously bad as you believe, the results should be dramatic enough to make the user blink.

-- R. D..Herring (drherr@erols.com), November 10, 1998.

# # # 19981110

ADDENDUM/ERRATA/OMISSION

You all are on the right tracks with me!! ( Even "Woe Is Me" ;-) ) ...

The missing info ( not trivial ) is this:

1) The software is 4th party vendor. No test scripts -- didn't even know what they were ( until I told him ) -- and no results to demonstrate what their 1,000,000 LOC product does with "funny" dates. ( Ugh!! )

2) The users are 1st tier ( state-licensed, specialized ) service providers ( to my client ) using this software application as an integral ( indispensible ) part of their ability to provide the service competitively. ( Translation: Without this package ( today ), they are OUT OF _THIS_ BUSINESS! )

So, as you might imagine, my client ( or I ) cannot simply yank the application ( source ) in BIG QUESTION and scan it or run it. No expertise and/or resources available for this custom ( evolving since 1978&#@*! ) package. The users are "turn-key" ( lovable ) numb-nuts -- no technical expertise, either. ( Mercy! )

Apologies for this omission. Does shed a different light on the scenario and possible solutions.

BTW: Thanks to all respondents! Especially to those that recognize the incredible difficulty dealing with all the ugly software foundering about in the world today. This application is more typical than atypical, unfortunately. That's why the Year 2000 Techno-Ambush is going to be so bad.

My only point in this exercise -- besides trying to figure out what the H*LL TO DO 8-) -- is to demonstrate how tremendously, incredibly stupid this whole Y2K mess is and is going to be to straighten out! ( Hopefully in terms that even the non-IT individual can understand! Educate, educate, educate! It'll scare the HELL out of the political and corporate Wonks if they perceive that you might understand and have insight into the nature of THIS BEAST!! )

Go get'em!! ... GGRRRRRrrrrr ...

Regards, Bob Mangus # # #

-- Robert Mangus (rmangus@mail.netquest.com), November 10, 1998.

I work for the second largest wholesale grocery provider in Canada. It has just been announced that it will be amalgamating (actually a take over). Here is the problem. The head office just started installation of new software in order to become compliant. The rest of the country is still waiting their turns (hopefully complete by July/99!?!) The take overor and the take overee are on different systems. What chance that groceries will be on the shelves in 2000 even if the iron triangle did stay up? Year end of the take overee would have been January/99 before take over. Hard to say what it will be for the amalgamated company. I was hoping the Joanne effect might give some impetus to triage. I just keep on keeping on...

-- Usually post under my own name (anon@this.one), November 12, 1998.

Dear Usually - If the iron triangle stays up, there will be some food on the shelves (for those who can afford it). It's stories like yours that have me feeling that the 1930's will be seen as nothing to the 2000 depression. We see food banks now, what will we see if the Welfare cheques stop? I'll keep praying.

-- Tricia the Canuck (jayles@telusplanet.net), November 13, 1998.