|
Comment: |
The standard media Party Line is this: "Large organizations will survive y2k because they have the money and resources. Mid-size and small organizations are more likely to fail." This is a comforting thought for both writers and readers, anchormen and viewers. After all, modern society is totally dependent on large organizations: the military, central banks, money center banks, government welfare agencies, the post office, telecommunications, public utilities, the energy industry, the automobile industry, etc. These industries are dominated by huge organizations. If these organizations fail, society will collapse. So, they must not fail. Thus, the media assure us that they cannot fail. Any major media reporter who figures out that they will fail will quit and get a job with a small-town newspaper. Thus, the Party Line has few critics, and none in big media.
Large organizations can fail, for at least these reasons. First, they are huge. They are difficult to change. They do not do well in emergencies. There are too many vested interests, too many rival departmental agendas, inside them. Second, they are too dependent on mainframe computers. Third, they have been dependent for too long: legacy code, embedded chips. Fourth, they are dependent on too many suppliers that are also dependent on mainframe computers, and whose systems are not 2000-compliant and also not integrated with the large organizations' systems. Fifth, they are dependent on the credit markets far more than small organizations are, and the credit markets are uniquely vulnerable to bank runs. Sixth, large code projects come in late.
Point six is made forcefully by Ed Yourdon, who has been programming mainframes for over three decades, and who has written two dozen books on the subject. His conclusion: the bigger they are, the harder they fall, more often.
He is an optimist. He believes that 80%to 90% of all y2k projects may be finished on time (though not in government). I am not nearly so optimistic. But note: he is talking about 80% to 90% of projects in the United States. Capers Jones has offered evidence that 80% of all software code is located outside the United States. No one -- I mean this literally -- suggests that in Asia or Latin America or anywhere outside the English-speaking world is there a society ahead of the United States in the y2k field.
The largest banks on earth are Japanese. They are not compliant. There is no evidence that they will get compliant by 2000.
If 100% of every industry in the U.S. except banking is 100% compliant, and 20% of the world's money center banks aren't, then the banking system, as a system, will collapse. The 80-20 law says that's the best we can expect for banking (or any other other industry). If the public figures this out in 1999, we'll get a worldwide bank run.
Frightened depositors will not wait until 2001 for 2000 fixes. If the runs begin in 1999 and banks go down, there will be few completed y2k projects in 2000 -- or any other kind of project. If you can't pay your programmers in 1999, you will not make the 2000 deadline.
This possibility, the programmers refuse to discuss in public. They are full-time optimists who assume that "banks are." They have never lived through a worldwide bank run. But they will.
Oh, yes: one more observation. Yourdon is discussing programming. He is not discussing embedded chips.
This article appears on Roleigh Martin's site. It was taken from the YEAR 2000 JOURNAL.
* * * * * * * *
The issue of project management is one that has been mentioned in various writings about Year/2000, but it's often glossed over or dismissed-and yet it's the primary basis of my technical concerns about the risk of Year/2000 projects all over the world. Here it is, in a nutshell: the software industry has accumulated metrics from tens of thousands of projects (that's a literal number, not hyperbole) over the past 30-40 years, which tell us, statistically, that approximately 15 percent of all software projects are delayed (behind schedule), and approximately 25 percent are canceled before completion. Statistics like this have been gathered and published over a long period of time, by well-respected software metrics professionals, long before Year/2000 was on anyone's radar screen.
One of the sources of information in this area is Patterns of Software Systems Failure and Success, by Capers Jones (International Thomson Press, 1996). But if you don't like the numbers from Capers, you can find almost identical numbers from the research carried out by Dr. Howard Rubin (head of the Computer Science Department at Hunter College in New York City, author of several world-wide software benchmarking metrics studies, and developer of the highly regarded ESTIMACS software-estimating product now marketed by Computer Associates) or Larry Putnam's company, Quantitative Software Management (Larry has also been in the software industry for 30 years, and is the coauthor of a book called Measures for Success: Delivering Software On Time, Within Budget (Prentice- Hall, 1992). The Standish Group, the Gartner Group, the GAO, Scientific Amer-ican, and several other reputable sources have confirmed that our track record for delivering software on time is lousy, and has been for a long, long time.
Large Projects Suffer Worst
The situation is substantially worse for large projects. In the Capers Jones book referenced above, approximately 24 percent of all 10,000 function-point (FP) projects are finished behind schedule, and approximately 48 percent are canceled. For 100,000 FP projects, approximately 21 percent are behind schedule, and approximately 65 percent are canceled. If you're not familiar with function points: One FP is approximately equal to 100 COBOL statements; you can do the rest of the arithmetic. The point is that many of the large, mission-critical legacy systems that are the subject of Year/2000 remediation fall into this category.
Just How Late?
A related issue: just how late are the projects that are "delayed?" It turns out that the experience of the software industry, over the last 30-40 years, is that the average software project is approximately six to seven months late. Again, the situation is much worse on the big projects: the 10,000 FP projects, according to the Capers Jones statistics, are an average of 13.8 months behind schedule, and the 100,000 FP projects are an average of 25.8 months behind schedule. Note that this doesn't include the projects that were canceled! . . .
My experience in the Year/2000 field for the past two years is that neither project managers, CEOs, or interested bystanders want to hear any of this. The reaction seems to be: "Oh, that's interesting" - and then they push it out of their mind and get back to their optimistic plans for Year/2000 projects. . . .
Bugs, by the way, are another reason I'm pessimistic about the likelihood of a smooth Year/2000 transition in most organizations. Again, the pessimism is based on 33 years of experience: software project teams typically deliver "tested" software, which is put into production with an average of one bug for 100 lines of code (a certain well-known software company, for example, delivered a well-known PC operating system to the marketplace at the beginning of this decade with 5,000 known bugs in the code - known to the software organization at the time they shipped the product! This is not atypical behavior.). . . .
What's taking place on almost all Year/2000 projects is not estimating, but rather a form of "backwards wishful thinking." It starts as follows: everyone knows what the "ultimate" deadline is for Year/2000 - we can't negotiate or ignore that fact. Indeed, most organizations have arbitrarily decreed that their Year/2000 projects will, by golly, be finished on Dec 31, 1998. . . .
Using the available industry metrics, the statistically predictable fate of the 8,500 or so mission-critical systems (the number comes from the OMB folks) in the Federal government agencies is that we can expect approximately 1,250 of those systems to be finished late (by an average of one to two years, probably) and 2,100 to be canceled, except that cancellation is a rather grim option, and may not be allowed. . . .
All of the available evidence strongly suggests that we're not going to finish our Year/2000 projects. We'll certainly get 50 percent of them done, probably 80 percent, possibly 90 percent - but nowhere near 100 percent. . . .
To ignore the significant likelihood that 10 percent or 20 percent or more of the mission-critical Year/2000 projects in this country won't be finished is irresponsible, in my opinion, not to mention imprudent. On a national level, sooner or later (probably later) someone at a high level is going to have to confront the significant likelihood that 900 or 1,000 or more of the government's mission-critical systems will not be remediated in time. Unpleasant news, to be sure, but to ignore it is something I'm not willing to do.
|