House Study Exposes Bad Software

FAULTY or inadequate computer software used by the federal government is costing taxpayers billions of dollars. And according to a congressional report, Washington has only itself to blame. ``Government policies on everything from budgeting to intellectual property rights have congealed over time in a manner almost perfectly designed to thwart the development of quality software,'' says the report, issued by the House of Representatives Committee on Science, Space, and Technology.

Software programming is often the most important and costly element of computer-driven equipment. The Pentagon, for example, expects to spend $30 billion on software alone in 1990.

Regardless of how sophisticated the equipment is, if the software that runs it does not perform properly, neither does the machinery. The B-1B bomber's electronic defense system, for example, does not work as it should because of deficient software.

The Vincennes incident

Even worse, shortcomings in computer programs can be fatal. In 1988, the USS Vincennes mistook an Iranian airliner for an attacking fighter plane and shot it down, killing hundreds of passengers. A review of data from the ship's sensors showed that the plane was climbing, not descending for an attack. But the software was not designed to display altitude changes in ``real time,'' so information about the plane's climb traveled too slowly from sensors to target displays for the captain to see that his ship was not under attack, the report notes.

The committee began investigating the issue in 1986 after a faulty computer program allowed a radiation therapy machine to expose patients to huge overdoses of radiation, killing four.

Procurement process faulted

The government's procurement policies are a primary reason the government gets bad software, says James Paul, a staff member for the House committee's Subcommittee on Investigations and Oversight, and the report's author. The government requires software producers to say exactly how a program will work when it is finished several years later, he says. So the software producer writes a program to run a complex piece of equipment before the equipment even exists.

In the meantime, the engineers developing the machinery often make changes without telling software writers. The result: ``When you try to put the software and the hardware together, it doesn't work,'' Mr. Paul says.

In these conditions, most software flaws are not detected until the equipment is produced. At that point, the report says, it can cost six to 20 times more to fix the ``bugs'' in the program.

The solution, Paul says, is better communication during the design process between the software writer and the hardware user.

``We should never let them get apart,'' he says.

This means the government must change the way it buys software. Paul says the National Aeronautics and Space Administration, which has a lot of computer experience, should help federal procurement officials develop new software-procurement regulations. ``There will probably need to be some significant changes'' in federal procurement laws as well, he says.

William Wulf, assistant director of the National Science Foundation, agrees that the federal procurement process leads to bad software. ``If anything, [Paul] may understate the case,'' he says.

But Judith Prewitt, a software specialist who runs two software companies in Maryland, cautions against putting too much emphasis the procurement system. ``Software writing is difficult, and it's hard to anticipate the effect of every statement of code,'' she says.

``The problem is not so much the procurement process as it is the writing of software to make it do what you want and not do what you don't want.'' Dr. Prewitt agrees, however, that ``if there is inadequate communication ... the procurement system can make the problem worse.''

The study also says government agencies such as the Federal Aviation Administration or the Food and Drug Administration have inadequate means to test the reliability and safety of programs that run systems they regulate.

The report recommends that government agencies look into ``innovative hiring and salary structures'' for software managers.

Dr. Wulf concurs with the suggestions, but is somewhat pessimistic about prospects for change. ``We have known about the `software crisis' for 20 years,'' he says. ``There have been lots of reports, but little done about it.''