Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : 2000 Date-Change Problem: Scam, Hype, Hoax, Fraud -- Ignore unavailable to you. Want to Upgrade?

To: Contra Guy who wrote (944)	12/10/1998 1:22:00 PM
From: Cheeky Kid	Respond to of 1361

Excellent post!

To: Contra Guy who wrote (944)	12/10/1998 1:50:00 PM
From: jbe	Read Replies (1) \| Respond to of 1361

At the risk of becoming the target of anti-hypesters armed with rotten veggies, let me refer you to my own reaction to the Aaron Lynch article: Message 6743312 jbe

To: Contra Guy who wrote (944)	12/10/1998 2:40:00 PM
From: Bill Ounce	Read Replies (2) \| Respond to of 1361

Friendly critique of Ben's post First off, my position on all this: I'm not an alarmist, just someone that believes that Y2K will generate somewhere between a moderate recession and a 30's style depression. We will survive, but it could get uncomfortable for a while... After it's all over we will (eventually) be better off than before. First of all, Bill never says that the Y2K problem does not exist. In his most recent post, he said it was 100% hoax. He correctly identified it as a fairly typical software maintenance problem. Unusually widespread to be sure, but a straight forward problem This is true. But, any idiot knows that. :-) that is not too difficult to fix if the programmer knows the application. This is misleading a bit. It's not difficult, just extremely time consuming. Plus, the smart programmers that know the application have moved on to better things while the dumb ones have been downsized. As such, like most maintenance issues, it does not lend itself to solution by software packages, code generators or roaming consultants. correct again. It is best fixed by those who are not available. It is best dealt with by in-house staff, Not most companies in-house staff :-) the very same people who make the myriad of changes that are continually required due to changes in company policy, union contracts, government regulation, etc. Partially true. The support crew for applications requiring ongoing modifications are staffed at levels for these relatively small changes. This is probably not enough people to fix all date related code. Not mentioned is that the schedules are seldom met for these normal maintenance activities, so we have little hope that all the fixes will be completed on time for a larger Y2K effort. What the Y2K companies were selling was a lie based on a truth, but a lie nevertheless. Bill exposed this lie. Not really. If you have an old COBOL app, and all the developers have gone, some of the tools these companies offer can increase your productivity in making Y2K fixes. If you no longer have any people left to maintain the code, some of these companies can provide bodies to re-work the code. Why else has the salaries for COBOL programmers more than doubled in the past two years? If you have lost the source code, you will need some sort of code generator. I have had personal experience with this. It is extremely time consuming... See I'm not really an alarmist: With all this, I still have faith that private industry should find a way to muddle through all the resulting mess. But have some concerns: Can any reasonable person have more than zero faith for poorly managed government infrastructure systems such as the FAA Air Traffic COntrol system. Just that one system [down for 6 months] could really mess up our economy for a while.

To: Contra Guy who wrote (944)	12/12/1998 8:34:00 AM
From: J.L. Turner	Read Replies (1) \| Respond to of 1361

I am attempting to make sense of all the claims and counterclaims of y2k.Would anyone answer the following for me? 1Does anyone claim that residual failure does not exist? 2Can anyone prove that it occurs less than 1% of the time? after any major maintenence change to a system (which Y2K most certainly is) there is always a residual rate of failure as a result of the changes themselves, even when the changes are properly "tested". The failures manifest themselves when the system is placed back into the real world of "production", as opposed to the artificial world of "testing". They happen because maintenence programmers customarily test only the immediate effects of their changes. There is neither the time nor the money nor often even the ability to test the entire consequences of a particular change to a system. The residual failures typically arise elsewhere in the system, at some point unrelated to the change itself and completely unanticipated by the programmer. This last is why residual failures are so hard to identify and correct. Often, we can't even tell for certain whether a particular failure really is the result of a recent system change or not. In turn, this is why a good system administrator would never return two or more systems to "production" at the same time. Not only is the risk of failure almost doubled, but there is also a small chance of both systems failing simultaneously. For Y2K, the problem is greatly compounded by the fact that, essentially, we will be placing all of our corrected systems back into "production" at roughly the same time. We can even calculate the magnitude of the residual failures, to a first approximation. The actual rate of residual failure depends on a number of factors, but mostly on the size of the system and the scope of the changes. Under average conditions, modest changes to a moderately sized system, the rate would be about 7%. The scope of Y2K changes is, of course, much more extensive than this and many of the systems are extremely large, so the residual failure rate is also likely to be higher. Nevertheless, for the sake of argument, let us again assume an overly optimistic residual failure rate of only 5% for Y2K related changes. But this is only for one system. For a business with multiple systems (which they all have) the chance of a system failure can be computed as:1-(1-f)n, where "f" is the failure rate and "n" is the number of systems. An average small business would have perhaps 5 systems so, assuming a residual rate of 5%, they have about a 23% chance of at least one system failure (1-(1-.05)5 = 0.226). A medium size business would typically have about 25 systems and, therefore, a 72% chance of a failure (1-(1-.05)25 = 0.723). A large business with 100 or more systems would have a 99% chance of a failure (1-(1-.05)100 = 0.994). This is EVEN IF ALL OF THE SYSTEMS ARE FIXED! Of course, many of these failures will be relatively easy to fix, but others will require an effort beyond the capabilities of the business and they will not be fixed before the business itself fails (this is particularly true for small and medium businesses using packaged software). In addition, the great majority of these failures will have at least some domino effect on related customers and vendors. To make it even worse, virtually everybody will be facing these problems at about the same time, leading to a chaos in which actually fixing the problems becomes almost impossible. At the very minimum this will lead to an economic disaster, JUST FROM THE ACT OF FIXING THE SYSTEMS THEMSELVES, without even taking into account the effect of the unfixed systems, of embedded systems or of an already declining global economy. In reality, of course, the situation is much worse than this, and the residual failure rate will be much, much higher. Just how much worse is anybody's guess since we have, as yet, insufficient historical data of actual Y2K failures. One thing I can state, categorically, is that a "bump in the road" is not even on the scale of possibility. As we have seen above, the best case end of the scale really begins with a global economic disaster and even then assumes that all systems are fixed on time and that there are no outside factors such as a global recession. Clearly this, too, is an untenable position. The above was written by "Infomagic" and released by Cory Hamasaki in his weather report 103.

To: Contra Guy who wrote (944)	12/12/1998 11:44:00 PM
From: David Eddy	Read Replies (1) \| Respond to of 1361

Ben - Back to Bill. To my knowledge, he was the first person without a computing background who was able to perceive that the public (and investors) were misunderstanding the very nature of the Y2K bug. He correctly identified it as a fairly typical software maintenance problem. Interesting. In my attempts (all failed) to engage Mr Wexler in what his beliefs are, he led me to believe that he was experienced in software. From one tiny angle, yes, dealing with software boundary issues like Y2K are "typical." What's definitely NOT typical is the size, scope and DEADLINE for Y2K. Software maintenance is the bottom of the pits with it comes to the software profession. No one goes into software WANTING to be a maintenance programmer. Here's a baseline for you...I happen to know a smallish company (US$1billion in revenues) that I consider to be the best of the best in maintaining their software portfolio. They've had the same team for 20 years. They have standards, team morale, repeatable process...everything that the other 99.9% of firms just can't touch. Since late 1996 they've been putting 30% of their development resources into their Y2K effort. That's 30% of available resources for one of the best run shops in the country. Tightly run consultancies such as EDS, IBM Global Services & others are complete bumbling idiots compared to these folks. [Ask privately for a published paper on them, if you wish.] You extrapolate from there. Note - I have no quibble with the FACT that the stock promotion of Y2K got way out of hand. To the best of my knowledge Wexler never admited to Y2K as a software management issue and as a stock bubble were seperate issues. - David