Ed, who is Nicholas Zvengintzov and why is he saying those things? My wife gave me a copy of his paper"the Year 2000 as a racket & ruse" He says that it is clear what to do. The places that need fixing are easy to find(?),the corrective action is straightforward and solving the Y2K problem is an execise for the software novice. I e-mailed him and he says he still believes this only more so. My skeptical wife is impressed with his credentials but I cannot judge them. The evidence to me seems overwhelming that he is wrong but I cannot convince her! help.

-- Jan S C Czarnecki (czarneck@tbaytel.net), April 29, 1998

Answers

Jan,

I have no clue as to who Mr. (Dr.?) Z is. But when I see this kind of reasoning from him I immediately question his grasp of reality:

<>

Take his second point. The very simple answer is that you correctly apprehend the 01 on your driver's license because you are *intelligent* and *adaptable* and so know that the century will be 200 0 and not 1900. The computer program does not know this; it often blindly assumes 1900 and must be specifically recoded to reacte otherwise. The fact that Mr. Z can make such an palpable and naive blunder makes me seriously question his grasp of the most basic computer realities. A computer academic he may be, but he seems to have a gigantic blind spot when it comes to Y2K.

As for the rest of the points, others have presented reams of evidence showing that 1) there is a gigantic amount of software that contains the problem, 2) it will require gigantic amounts of efforts to fix it, and 3) that companies and government agencies can be shown with statistical precision not to have started their remediation soon enough. All of this Mr. Z dismisses with a wave of his hand. I'm not reassured by his optimism.

Best regards,

David

-- David Palm (djpalm@compuserve.com), April 29, 1998.

Mr. Zvengintzov holds an opinion I find both common and understandable, even though I disagree with it.

Frankly, if you were able to count all instances of Y2K bugs in all the software in the world, the vast majority would fall into the category he cites, namely "excercises for novice programmers." It really is a simple, repetitive matter of correcting some date math code, expanding some field widths and being done with it. But the problem (at least as I see it) lies in several other places.

1. Volume. Even the simple fixes mentioned above can be overwhelming in volume, especially when considered on a global basis. It becomes like that old Chineese torture called The Death Of A Thousand Cuts. Small nicks were made in the victims skins, none of which tkaen indiviually were particularly painful or damaging. However, by the time several hundred to a thousand were made, the victim bled slowly to death and in terrible agony. Many organizations will have the resources and the time to fix enough of their "cuts" to survive. Others will not.

2. The exceptions: Primarily, the exceptions to this rule lie in much more complex software and firmware systems such as those found in operating systems and embedded controllers. While these problems are smaller in volume, they can be much more complex to fix.

3. Physical access to the problem. In software, this means things like "Do I still have the source code and a working compiler, and can I distribute the fix to every system that needs it?" In firmware it means "Can I distribute replacement chips everywhere that needs them, and can they be physically accessed and replaced?" In the Yourdon's book, they mention the problem with a bank valut door. If you need to replace a faulty chip in that door, it doens't matter how simple the problem was to fix if you have to tear half your building down to gain access to the chip!

To me, his failure is not in understanding the problem so much as it is in failure to understand the problems associated with delivery of the solution.

-- Paul Neuhardt (neuhardt@compuserve.com), April 29, 1998.

I agree with Paul N. who says:

<< To me, his failure is not in understanding the problem so much as it is in failure to understand the problems associated with delivery of the solution. >>

I gather that Mr. Z is a computer professional. If so, then he must have long since forgotten how torturous it is to work on somebody else's code. I am a programmer by profession (embedded systems). I weekly experience the plight common to so many programmers that unless I have documented my work meticulously it's hard to understand what I've done even a month after I wrote it. These are the unchangeable verities of the software industry.

I have been forced to work on programs so convoluted that you don't dare look at them cross-eyed or them will break down. Change one or two lines and it sends ripples of subtle bugs through the system. Every change requires another massive round of system testing. I have several programs at my present company that I refuse to have our group support because they are so poorly documented; it would take a month of effort just to begin to understand what they do. These programs that I am talking about are literally 100 to 1000 times smaller than many of the applications that banks, the FAA, Treasury, the IRS, etc. are dealing with. Y2K is a huge problem.

I suspect that what we have here is a man who has been on the academic side of computer science so long that he's forgotten the realities of real-world programming.

Best regards,

David

-- David Palm (djpalm@compuserve.com), April 30, 1998.

Stupid.

-- Robert A. Cook, P.E. (cook.r@csaatl.com), September 01, 1998.