|
This article is written by a man who chooses not to address the key aspects of y2k. Then he glosses over the technical problems. Having done this, he says that y2k wll even be a benefit.
The y2k problem is systemic. It involves all of the problems that my site lists as categories. For example: (1) bad data from noncompliant computers will re-infect compliant computers; (2) the domino effect of noncopmliant suppliers will bankrupt the companies that depend on them; (3) the banking system is fractionally reserved, and will be shut down by bank runs before y2k is remediated; (4) the embedded chip problem is inherently unsolvable -- too many chips in inaccessible places -- and cannot be solved by programmers, yet he merely mentions it as one problem, as if it could be solved; (5) the power grid may go down, thereby wiping out all compliant systems; (6) there are no agreed-upon standards for making the century date change or testing the supposedly corrected system, and there are major problems with all of them, which is why there is no agreement.
If the problem were easy to fix, there would be many examples of large organizations that have fixed it. Where are these examples?
The author approaches the problem from the micro level: programmer A in company Y who starts looking for noncompliant code. He does not ask: (1) How many noncompliant computers are there in relation to the number of programmers, worldwide? (2) How many lines of code can a competent programmer fix in a year (100,000-150,000)? (3) How many lines of code are there to be examined and fixed, in how many languages, most of which are forgotten? (4) How many lines of code and programmers are there outside the United States, and where are the y2k training materials to guide them? (5) When did most organizations get started with actual code remediation? [Answer: they have yet to begin.] (6) Where will all the companies locate excess computer capacity and programmers to run parallel tests on separate computers to make sure that the data fed into the "fixed" computer system do not shut it down?
Notice that he uses unverifiable adjectives: "many," "most of the time." These adjectives are applied, without proof, to situations without information. They really mean, "I'd like to believe." In one case -- the percentage of good code -- he is more honest. He says "my guess." He offers no evidence to verify this guess. He wants us to take it on faith.
Then there is the favorite, "It is reasonable to expect." We need evidence, not happy-face expectations. He offers no evidence.
Other than this, there is good news about y2k. The good news is that y2k will force lots of spending. This is the classic economic error that Frederic Bastiat in the 1850's called the falacy of the broken window. Break a window, and look at all the spending. Glassmakers will get new business. So will window installers. The fallacy rests on the thing not seen: the money would have been spent elsewhere. Henry Hazlitt exposes this line of reasoning in his classic book, ECONOMICS IN ONE LESSON. The largest broken window in man's history is the Millennium Bug -- expenditure that adds no value to production. This is why so few firms and governments are willing to spend the money.
He blames profit-seeking consultants for exaggerating the problem. The author runs a
marketing-consulting company.
It is not clear where this March, 1998, editorial was published.
* * * * * * * * *
I have been working in the information technology industry for over 20 years now and on the Year 2000 conversion issue for over three years. The general and IT industry trade press have done their typical job of over-dramatizing and sensationalizing the Y2K conversion issue. . . .
First - The Good News
The problem is smaller than you think.
The Y2K problem as a whole is very straight-forward. There are four major issues involved:
1. Date field expansion. . . .
2. Date calendar logic. The year 2000 is a leap year. . . .
3. Date calculations. The same issues applies in date calendar logic. You must have the leap year correctly identified and the 00-99 relationship in the right order. If not, subtracting 12-31-99 from 03-01-00 does not produce the right answer of 59 days. It is possible to get a result of a negative 99 years and 10 months. Any interest or loan repayment calculations would be off by one day at best and greatly misstated at worst.
4. Naming of date fields. Since dates are used often and in various ways within programs, each time a date is used must be identified and analyzed for compliance. However most of the name identifiers of these fields do have the word date or other date language (month, year, day, week, etc.) in them so to be easily recognizable.
None of these four issues requires substantial technical expertise to solve. They are just time-consuming to fix.
The press talks about the billions of lines of computer program code that must be Y2K remediated. This is true, there are billions of lines of code involved. But what they haven't told you is that only 15%-25% of the code actually involves date capture, retrieval, manipulation and storage. What the press means is that there are billions of lines of code that must be scanned to determine whether date processing is involved. Some percentage of that code (currently unknown and guesses are wildly divergent. My guess is 30%-40%) is already Y2K compliant. This means that at the worst 80% and at the best 90% of the software code developed is Y2K compliant already because it has already been remediated, was written initially to be compliant or does not involve date processing at all. . . .
Technology comes to the rescue. . . .
There has been the rapid introduction of Y2K diagnostic, analysis and conversion software from companies such as ViaSoft, Peritus, MicroFocus and many others. Most of the current Y2K remediation software does just scan the code to identify date field and date calculation usage in programs. However, there is an increasing amount of conversion software becoming available which, in addition to scanning the code, automatically remediates up to 90% of the date usage issues involved. It is reasonable to expect the percentage of remediation to increase as technological improvements are developed. . . .
The economy will be helped. When you read the "doom and gloom" articles about the effects of Y2K, consider the source. Many of those parties who are predicting the end of the world as we know it, have a vested interest in doing so - to make big money. . . . The extent of the Y2K issue will actually cause a boomlet in the economy, in my opinion. There already is and will continue to be a huge demand for technology services to help with the remediation processing. This demand has caused some manpower shortages and increased salaries for information technology professionals. There will be increased spending on replacement items or technology upgrades for consumer goods which have date handling and processing incorporated in them. Personal computers, digital watches, home security systems, microwave ovens, VCRs, etc. and the microprocessors they use are just some of the items which will have an upswing in spending as the millennium date draws closer.
Now the Bad News
The problem is greater than you think.
While I've never believed the argument that many companies will go out of business due to Y2K compliance problems (you can always go back to paper and pencil, if you must), there have already been documented incidents of Y2K-noncompliance problems. . . .
What does concern me is the amount of embedded microprocessors used in a wide variety of critical equipment, the bank ATM machine just being one. Add to the items listed above, aircraft control systems, automobile ignitions, manufacturing processing machinery, telecommunications equipment, electrical systems and many, many other types of goods critical to life functioning being affected. There will some dramatic dislocations and events occurring because of the effects from the date rollover, we just don't know for certain where and when.
Shortages exist now and more will occur. . . .
The same holds true for mainframe computer processing availability. . . .
It is also possible that some specialized types of microprocessors needed will be out of stock due the huge demand for product upgrades or new purchases. . . .
Technology doesn't cure everything. The last published reports I read were that 30% to 40% of businesses have not started Y2K remediation and don't believe they have a Y2K problem. This includes many major corporations. It is doubtful that if these companies start the remediation process now that they will be completed in time, even with the technology advances that have occurred and will continue to be occurring. . . .
We are all going to be paying for the bad practices of the companies that got us into the messes that will occur. These bad practices include:
Not designing Y2K compliance into their products. . . .
Bad programming practices. . . .
Not resolving, just postponing the problem. . . .
Inadequate product testing. . . .
However, you haven't been told the other secret of the year 2000 crisis. While most companies, consultants and analysts continue to state that the effort this crisis creates will provide no added value to business and the world at large, it does. The greatest value is in the finding out all the above so these problems are finally being fixed and brought under control. The other value, IMNSHO (in my not so humble opinion), is that those parties who created the crisis and those who have played Chicken Little with this issue, cynically playing on the public's fear of overreliance on technology for their own gain, are finally being exposed.
|