Is "bug-free" software possible?

In the software development process, which is part of the systems life cycle, a crucial step is finding and correcting errors - so-called "bugs." As software becomes more complex, the process of "debugging" each program of a software package also becomes more difficult. Programmers now spend at least as much time debugging their work as they do in actually writing their programs. Nevertheless, it is generally acknowledged that bugs still exist in most commercial software. In fact, most software sold today carries a disclaimer stating, in effect, that the package is not guaranteed to work! Writing bug-free software is inherently difficult, because the logic supporting the program is inflexible. In most engineering projects, a margin of error is built into the design specifications, so a bridge, for example, usually will not collapse if an element is defective or fails. With computer software, on the other hand, each program instruction must be correct. Otherwise, the whole program may fail.

Examples of problems attributed to faulty software include the following:

• 1,800 automatic teller machines at a major bank in Tokyo shut down on payday.

• An airline's reservation system failed, forcing 14,000 travel agents to book flights manually.

• The air traffic control system at Dallas-Fort Worth International Airport began spitting gibberish, forcing controllers to track planes on paper.

• A bug in the Pennsylvania state lottery computer system allowed clerks to buy winning tickets after a drawing—about 465 winning tickets were punched out before the error was detected.

• Problems with telephone systems have included the AT&T outage in 1990 and the disrupted service to 10 million people in five states and the District of Columbia in 1991.

• A problem with the computer system that directed the Patriot antimissile system allowed a Scud missile to hit a barracks, killing 28 U.S. service people during the Gulf War. The error, attributed to a "freak" combination of ten abnormal variables, was not detected in thousands of hours of testing.

Prison inmates pass their time with programming

Аt Somers Correctional Institute, Connecticut's only maximum security prison, a group of prisoners is spending time writing programs. The inmates wrote the programs not just for their use but for some of the prison's operations. For example, the group wrote programs in dBASE to automate the prison's pharmacy, track the status of prisoners for prison administrators, and monitor job and pay schedules for the 1,400 inmates at Somers.

Some prisoners were in the computer field before entering prison. Others, however, learned computer programming through the prison's educational program. Many prisoners had not seen a personal computer before their incarceration but learned a lot in the six hours a day they spent in school. When administrators were confident that prisoners could write the programs, they began assigning projects to them, and prisoners have taken over many responsibilities associated with the prison's restricted information system.

The members of the group work six days a week, 10 to 12 hours a day. They believe they are gaining valuable experience that will help them when they are released from prison. In recognition of the group's effort, it has been designated as a tester of BASE IV. Members believe their work is important—so important that one member of the group turned down an opportunity to move to a medium security prison, because it did not have computers.