When the contract was first awarded in 1984, the U.S. Army hoped to develop a largely automated battlefield.

Computers would determine what gun to fire at what target, and precisely when. They would select routes for artillery and trucks to travel. They would track troops as they moved across the terrain. Commanders would manage the battle from computer consoles.

After six painful years, the Advanced Field Artillery Tactical Data System (AFATDS) is a monument to the perils of reliance on sophisticated computer software to fulfill complex military assignments. The skeleton of a system that can automate bits and pieces of the battlefield has been created. But synchronizing the whole operation, the Army now acknowledges, is still years -- and many millions of dollars -- away. Nearly $80 million has produced nothing that is yet usable on a battlefield.

AFATDS (pronounced a-FA-tids), far from the Pentagon's largest software project, captures in miniature a software logjam that has affected the entire defense establishment.

The Pentagon is the biggest software customer in the world. Its spending on software projects is estimated to be about $30 billion a year, or 10 percent of its budget, an amount that has tripled in the past five years.

But the Defense Department is also a huge bureaucracy with old habits that aren't well-suited to the computer age.

By the admission of numerous Pentagon officials, the department has failed to master the administration of complex software projects. "We don't know how to manage it," said Virginia Castor, a Pentagon official who is helping to develop a Defense Department policy for improving software production.

Software problems have caused major delays of weapons systems, created malfunctioning aircraft and cost the Defense Department billions of dollars in unanticipated costs. Officials acknowledge that virtually every troubled weapons system, from the electronics in the B-1B bomber to satellite tracking systems, has been afflicted with software problems. Even straightforward record-keeping systems can get bogged down; last year, the Navy canceled a software accounting project nine years in the making after its costs quadrupled to $230 million.

The software problem steadily compounds itself because of the rapid expansion of the Pentagon's dependence upon software. The F-4 fighter-bombers that saw combat in Vietnam had no software at all. Today's fighters have more than 1 million lines of computer "code" -- each line a written instruction to a computer -- while the Navy's latest submarine combat system has roughly 3 million lines. The Strategic Defense Initiative, the high-tech U.S. anti-missile program, would require an estimated 30 million lines. With each additional line, the danger of error multiplies.

Never has the military's software dependence been more evident than in the current Persian Gulf crisis. From the F-16 fighters and seaborne Aegis air-defense system to the ordering of spare tires and food, software serves as the central nervous system of the U.S. buildup. "There isn't anything over there except the foot soldiers that doesn't have software," said Lloyd Mosemann II, deputy assistant secretary of the Air Force for communications, computers and logistics.

Ultimately, a failure to perfect military software problems can endanger American fighting men and women and the effectiveness of the U.S. military. One example is the huge C-17A transport plane being developed by McDonnell Douglas Corp. at about $150 million each. Three years into its development, engineers discovered that a faulty software design created an unacceptable risk that the plane could crash when landing. The design was scrapped and developers had to begin anew -- increasing the cost of the plane and adding to delays.

Such delays are typical. A review of 82 large military procurement programs conducted by Air Force Col. Joseph Greene Jr. found that those relying heavily on software generally ran 20 months behind schedule, three times longer than projects less dependent on computer programming. Greene, who retired this year as head of a Pentagon software research effort, calculated that such delays cost the Defense Department one-tenth of its $100 billion annual research and procurement budget. A separate study showed that Pentagon contractors deserve some of the blame: Three-fourths of 55 aerospace and defense projects were found to be run in an "ad hoc" and even "chaotic" manner.

"The department is paying a huge penalty for not dealing with its software problems," Greene said. "The penalty is not just late software -- it is degraded war-fighting capability."

Army Couldn't Communicate

In the case of AFATDS, the Army hoped for a computer system that would be able to set priorities in the heat of battle, decide what firepower should be used against which targets, distribute critical information to units in the field and at headquarters, manage ammunition, assess road conditions and advise commanders where to place artillery.

The contract to develop this capability was awarded in May 1984 to Magnavox Electronic Systems Co., based in Fort Wayne, Ind. The project posed big technical challenges for Magnavox, which had never won such a large government software contract before. But from the beginning, the dream was frustrated by a persistent problem of a different sort, one not uncommon to large projects: The Army couldn't communicate what it wanted the computer software to do.

"The contract was signed for a total system when the government and contractor didn't have a good understanding of what it is that we wanted," said Robert Giordano, now the Army's deputy program executive officer of command and control systems.

Such confusion continuously dogged Magnavox, where software chief Harold "Skip" Carstensen and a staff of 100 others often spent weekends cloistered in conference rooms, reading through line by line what ultimately became the official AFATDS program requirements -- nine blue binders totaling about 2,000 pages.

They frequently encountered new snags. Some were caused by Ada, the "universal" computer language adopted by the Pentagon in 1983. So new was Ada that Magnavox had to train nearly 300 people in the language -- only to have many hired away by other defense contractors hungry for Ada talent.

Magnavox made its share of outright mistakes, contributing to repeated schedule delays beyond the original 33-month plan. The company had to alter the AFATDS software, for example, because it displayed the same information about the status of troops and ammunition to all levels of personnel. The Army pointed out that generals and privates hardly needed the same information. "I as an artillery officer should have realized that," said Carstensen, an Army officer before joining Magnavox. "You can't think of everything."

He calculated that readjusting the software would take six "man-months" -- say, six people working one month. Instead, the job took two man-years, and instead of affecting 6,000 lines of code, it involved 12,000, Carstensen said.

Army gaffes caused setbacks, too. One requirement of AFATDS, for example, was that its users be able to exchange information with the older computer-based battle-management system used by the Army. But the Army failed to supply Magnavox with up-to-date technical details to make the links possible, causing several man-months of extra effort.

Invariably, delays resulted from the Army and Magnavox not seeing eye to eye on what AFATDS was supposed to do. Many misunderstandings stemmed from both parties' use of imprecise English.

One requirement, for example, reads: "The operator will receive notice of this new position when the movement requirement is delivered." To the Army, that meant that when artillery changed locations, the person manning the computer would be notified by an alarm or message on the screen. Magnavox insisted, however, that the requirement meant that the news could simply be delivered by one person handing another person a piece of paper.

Such misunderstandings led to endless paperwork. One report by a Magnavox employee outlined this conversation with an Army official: "The paragraphs in the item were and on page 124. There are no such paragraphs on that page." The matter subsequently was resolved when the parties agreed that a "2" had been dropped from the designations.

Snags like these, though troubling, were overshadowed by managerial shortcomings and political pressures that distracted attention from productive work. As the Army and Magnavox bickered, the project fell behind schedule, prompting the Pentagon to freeze payments and ultimately cap the cost of the program at $46 million, up from the original $34 million.

Like most procurement programs, software acquisition is subject to congressional pressure and interference. In the case of AFATDS, the House defense appropriations subcommittee repeatedly challenged the Army and Magnavox about the cost and feasibility of the ambitious project. The subcommittee ordered at least five General Accounting Office reports on AFATDS and related programs and at one point warned that it was growing "increasingly concerned with the Army's repeated ... disregard of congressional direction."

Under this scrutiny, the Army increased its pressure on Magnavox, whose officials became overwhelmed by visiting investigators. Some of those visitors were, they themselves acknowledged, ill-prepared to pass judgment. Richard Stanley, then an Army official, was on military business in Texas in early 1987 when he was hastily called to Indiana to investigate Magnavox's progress. "Half the people {on the review team} couldn't spell software if their life depended on it," he said. "Most of us there had very little first-hand knowledge of AFATDS."

At one point, Carstensen said, an Army official requested a photo of a "compiler" that was causing problems. Magnavox people just shook their heads. A compiler is a batch of software code, not a piece of hardware, as the Army official had presumed.

Software Two Years Late

Finally, in the spring of 1989 the software emerged from field testing with remarkably few flaws. Magnavox was two years late and had spent $30 million of its own funds on AFATDS, but in the end it joined the Army in rejoicing that the complex software actually worked.

But for all the agony, Magnavox had been asked to complete merely what is known as a "concept evaluation" -- enough software to confirm that computers can support a broad range of troops and weapons, yet far short of what actually would be needed to automate the battlefield. That dream, once expected to become reality starting in 1990, has been broken apart into smaller, incremental steps, and it will be at least three more years before any troops will be even partially equipped with AFATDS gear.

Now, officials say, AFATDS software development is moving forward on schedule, thanks to improved cooperation among everyone involved, with a new $60 million Magnavox contract. Still, so much has changed since the Army first sketched out AFATDS that Magnavox has concluded that half of the software written in the first phase is unusable.

Maj. Gen. Peter Kind, who for a time oversaw AFATDS, said the experience taught an important lesson about software: "With large programs, it's a very difficult thing to get it all working and out there in one fell swoop. It just doesn't work that way."

NEXT: Japan's factory approach

Space Defense Operations Center (SPADOC)

This $469 million software project is supposed to detect and monitor enemy objects in space. But so far it is eight years behind schedule, and a 1987 Air Force-commissioned study found that work at the contractor, Ford Aerospace (now Loral Corp.) was not well managed.

The Air Force report cited programming problems -- typographical errors and mistakes in formulas -- and occasions when Ford kept working on software code that had been replaced by newer versions. It found that corrections were lost, incomplete manuals were used, efforts to coordinate with other subcontractors were haphazard and in some instances Ford had more than one contractor doing the same work. Other tasks weren't assigned to anyone. Company and Pentagon officials say the software development process is now better controlled.

Army Civilian Personnel System

This software project, intended to automate the Army's personnel records, was killed in 1988 after cost overruns and delays convinced officials it would be better to adapt an existing record-keeping system that they had previously rejected. Three years in the making, the project suffered from a variety of problems, including an arrangement that scattered responsibility for developing the software among at least three companies and government agencies.

Army officials also were reluctant to be candid about the potential costs and problems that might ensue for fear of losing the program's financial and political support, according to retired Maj. Gen. Alan Salisbury, who was commander of Army information systems engineering command.

"I assign myself blame," he said, "for not standing up, instead of saluting and saying, 'Yes sir, we'll build that system.' "

The C-17A Air Force Transport

Development of the huge C-17A cargo plane has been repeatedly hit by software snafus. Three years into the program, engineers discovered that a model of the aircraft showed an unacceptably high risk of crashing when landing. Contractor McDonnell Douglas Corp. traced the problem to the design of the software intended to control and stabilize the plane. Work began anew.

A 1989 Pentagon inspector general report said McDonnell Douglas did not meet the military's quality standards for software and warned that "without an adequate quality assurance program, there cannot be any assurances that the C-17A software will provide the integrity, reliability and maintainability needed." In what became a dispute over interpreting regulations, the inspector general put the ultimate blame on the Air Force for failing to require McDonnell Douglas to follow the correct guidelines. (Company officials said they are now satisfied with the quality standards applied to the ongoing software work.)

If fighting breaks out between the United States and Iraq, it will be the first heavily automated war, with several weapons systems being used by U.S. troops highly dependent on software. A few examples:

F-16 Fighter - Software helps pilots navigate these planes, and identify missiles and other aircraft. Since the fighters arrived in the gulf, the software in them has been updated several times to assure the planes are equiped with the latest combat data available. Some of the changes to computer code, written in the United States, were sent to the gulf over phone lines.

E-3 AWACs -- The Airborne Warning and Control System, a Boeing 707 stuffed with computers and radar equipment, is designed to track up to 600 aircraft simultaneously so that pilots can determine whether other aircraft are friend or foe. The computer systems in these planes contain 515,000 lines of code that aids in navigation, operations and surveillance.

Small receivers -- Portable software-laden radio receivers are carried by troops to help them avoid getting lost in the desert. The receivers pick up signals from satellites and then calculate the longitude and latitude of the person.

Aegis combat system -- Cruisers equipped with the Aegis defense system track dozens of planes using sensors and computers that rely on 3.7 million lines of software. It is considered one of the military's primary seaborne combat systems.