That scale and pace makes defense-establishment technology a world unto itself. This parallel universe of software has a lengthy and checkered history of dependence on a dauntingly complex armamentarium of methodologies and practices and disciplines, aimed at codifying good engineering practices, producing reliable plans and schedules, and reducing flaws in the product. (One epicenter for these standards is the Pentagon-backed Software Engineering Institute at Carnegie Mellon.)

Like everything else in this field, these schemes kick up dust storms of acronyms. Although the "high ceremony" required by such approaches -- including rigorous documentation, exhaustive testing and precise measurements -- can look an awful lot like arthritic bureaucracy, many programmers swear by them, insisting that their tenets reduce costs and save time in the long run.

In a talk titled "The Need for Speed," conference speaker Jon Ogg, director of engineering and technical management at the Air Force Materiel Command, laid out what he calls the "software divergence dilemma" the military faces today. In the past 50 years, the amount of code in a typical military system has increased a hundredfold: For instance, a 1960s-era jet fighter might have had 50,000 lines of code, whereas the new Joint Strike Fighter will demand 5 million. Meanwhile, in that same span of time, the average productivity of programmers has only doubled. That means we've seen the "person-months of effort now required to develop a capability" increase by a factor of 50, Ogg says.

As Barry Boehm, professor of software engineering at the University of Southern California and a pioneer in the field of cost estimation, put it, "The amount of software DoD needs is growing exponentially, and you'll never get it done in a finite amount of time."

And so today's Pentagon is deep in the throes of a convulsive sea change toward a more nimble and "agile" method of making software -- one that parallels recent developments both in the private sector and in the operational transformations the Rumsfeld-era military has espoused. The military-industrial elephant, in other words, is trying to learn dance steps from the private-sector menagerie.

From what I could tell from the people I talked to and the sessions I sat in on at SSTC, there's a pitched battle taking place in the defense technology world between die-hards of the old disciplines and the proponents of the new agility, with its emphasis on "working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan." The latter scorn the stultifying paperwork of their more traditional colleagues and are staging a "rebellion against an overemphasis on process," in one speaker's words. Meanwhile, among the old guard, as another put it, "there's almost a feeling that lightweight is cheating."

The Defense Department honchos who spoke at the conference left little doubt about which road they favor. They're abandoning custom-tailored, white-elephant "legacy systems" and buying COTS -- commercial, off-the-shelf systems. In their push toward a "netcentric" vision of "warfighters" connected by the GIG -- a secure, global broadband network -- they are emphasizing the adoption of standards from the commercial world, including many familiar technologies and buzzwords.

"XML and Web services are crucial for protecting America," according to deputy undersecretary of defense Sue Payton.

David Wennergen, CIO of the Department of the Navy, had tough words for the crowd of contractors and developers: Get with this new program, or your project will get cancelled. "We have the hardest time when we try to invent the solution all on our own," said Wennergen. "Our future is a future of Web services, as we move toward an enterprise portal structure. Too often we're tortured by the idea of sunk costs. But if you're not part of that transition, it really doesn't matter how much we've already spent on your system."

Which is not to say that there aren't skeptics about the new marching orders, who view at least some of these directives as futile or misguided. Critics point out that agile and "extreme programming" approaches fit small teams and projects best and may not offer much help to the vast hordes of developers laboring over the Defense Department's next-generation megaprojects.

One of the five winners of the conference's Top Five Quality Software Projects awards, a software framework for the Patriot Excalibur missile, started out as a troubled project paralyzed by delays and low morale; the team of about 20 started to click only when they switched to what they described as a "modified extreme programming" technique. Every other project in the Top Five, though, involved much bigger groups of roughly 100 or more developers.

And while the government's budget monitors may dream of saving money by plugging in ready-made commercial software rather than handcrafting one-of-a-kind products, history and experience suggest that road is pocked with its own craters. Randall Jensen, a Hughes Aircraft veteran now with Hill Air Force Base's Software Technology Support Center (the conference host), questioned the Pentagon's COTS mania: "It's a bolt-on! It's free! That's the current philosophy. But you have to understand it, build the interfaces, and test it. Reusable software is not free. It's going to kill you.... It's dangerous stuff."

As the armed forces prepare almost unimaginably complex new technologies -- like the Army's Future Combat System -- for an age of "network-centric warfare," it may be that the adoption of "agility" as a watchword is simply bowing to the inevitable. These projects may differ from their predecessors in their decentralization, their compatibility (or "interoperability") and their automation, but they share one thing with their forebears: They still take forever to move from the drawing board to the field. If you're writing software today for a system that's going to take years to deploy, you have no choice but to plan on everything changing around you. You're Sisyphus, and you might as well get used to that stone rolling back down the hill.

Or, as Aegis' Dave Cook put it, in a pep talk on quality:

"What are the odds your software is going to change? Oh, 100 percent. It's going to be around for 10 years. You're going to have to modify it more times than you can imagine. You're gonna have to change it for different hardware and software environments, change languages three times, and go through four personnel turnovers. What you have to do is fight as hard as you can to keep quality up so that 10 years from now you have something left. It's like, when you grab the software in your hands, it's sand. And as you stand here doing the best you can, sand starts leaking between your fingers. Ten years from now, there's a few grains of sand left, and that's all you have to work with. Your job is to keep your hands as tight as possible."

Recent Stories