Code that kills, for real

Future military combat systems will require ever more complicated code, but writing software that is bug free and ready for a firefight is a challenge that gets tougher every day.

Topics: U.S. Military,

“When everyone decides for themselves what frequency to use, what protocols to use, what standards to use, then you get systems that don’t talk to each other. And it’s killing us.”

That sort of lament is a staple at technology conferences, and its dire language is usually a matter of executive hyperbole: Somewhere in corporate America, perhaps, a bottom line is breathing its last, and we’re supposed to care.

But when the speaker is in uniform, and the incompatible systems he’s describing belong to the armed forces, then you sit up straight in your seat and realize that the words are meant all too literally. As Adm. Michael Sharp of the U.S. Navy went on to say, in a talk last month in Salt Lake City, “Software errors, timing errors, can get real critical — killing the wrong people, or not killing the right people and leaving our people unprotected.”

Here’s David Cook, senior research scientist at Aegis Technologies: “It has been said that, without software, the F-16C is nothing more than a $15 million lawn dart. There are stories that I know for a fact of airplanes that have been flying cross-country that land at a base that’s not where they’re supposed to land, and while they’re there, somebody modifies the software. And the airplane flat stops in midair when they turn on the radar unit. Why? Because there are incompatible versions of this certain piece of radar software, one of which they never thought would be on that particular model.”

The U.S. military is like every other institution in our society: It runs on software. And all software has bugs. But unlike, say, your Windows PC, where a crash could cause you to curse at some lost work, or your bank’s ATM, where a software error could leave you with an incorrect cash balance, or even your precinct’s voting machine, where a security hole could cast doubt on a close election’s outcome, bugs in Pentagon programs carry potentially fatal risks. Americans in wartimes past were warned that “loose lips sink ships”; today, it’s loose code that sinks ships, and downs airplanes, and costs lives.

I recently spent four days at the Systems and Software Technology Conference, a 16-year-old Pentagon-sponsored event for Defense Department contractors and software developers, because I wanted to know more about how the defense establishment approaches the ever more complex job of writing the literally hundreds of thousands of individual programs that our tax dollars fund and our armed forces depend on. Private-sector software is notoriously late, expensive and full of flaws; no one has a more urgent incentive to solve those problems than the people who write code for “the warfighter” (a Pentagon terminology upgrade for “soldier”). Have they figured out anything the rest of us can learn from?

The headlines from Iraq and the Pentagon since then may make that question seem trivial. During the week I spent at the Utah conference, casualties mounted in Iraq, and the latest defense-contracting scandal at Boeing was hitting the front pages. But the world of “defense systems” moves at a pace that is, in contrast to the flow of news, geological: The average “acquisition cycle” for a military product, according to conference speakers, is 10 years — and that’s an optimistic figure. Between the time the Pentagon commissions a system and a contractor delivers it, whole generations of private-sector computing software and hardware have come and gone.

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.)

You Might Also Like

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.”

Salon co-founder Scott Rosenberg is director of MediaBugs.org. He is the author of "Say Everything" and Dreaming in Code and blogs at Wordyard.com.

More Related Stories

Featured Slide Shows

  • Share on Twitter
  • Share on Facebook
  • 1 of 11
  • Close
  • Fullscreen
  • Thumbnails
    Martyna Blaszczyk/National Geographic Traveler Photo Contest

    National Geographic Traveler Photo Contest Entries

    Slide 1

    Pond de l'Archeveche - hundreds thousands of padlocks locked to a bridge by random couples, as a symbol of their eternal love. After another iconic Pont des Arts bridge was cleared of the padlocks in 2010 (as a safety measure), people started to place their love symbols on this one. Today both of the bridges are full of love locks again.

    Anders Andersson/National Geographic Traveler Photo Contest

    National Geographic Traveler Photo Contest Entries

    Slide 2

    A bird's view of tulip fields near Voorhout in the Netherlands, photographed with a drone in April 2015.

    Aashit Desai/National Geographic Traveler Photo Contest

    National Geographic Traveler Photo Contest Entries

    Slide 3

    Angalamman Festival is celebrated every year in a small town called Kaveripattinam in Tamil Nadu. Devotees, numbering in tens of thousands, converge in this town the day after Maha Shivratri to worship the deity Angalamman, meaning 'The Guardian God'. During the festival some of the worshippers paint their faces that personifies Goddess Kali. Other indulge in the ritual of piercing iron rods throughout their cheeks.

    Allan Gichigi/National Geographic Traveler Photo Contest

    National Geographic Traveler Photo Contest Entries

    Slide 4

    Kit Mikai is a natural rock formation about 40m high found in Western Kenya. She goes up the rocks regularly to meditate. Kit Mikai, Kenya

    Chris Ludlow/National Geographic Traveler Photo Contest

    National Geographic Traveler Photo Contest Entries

    Slide 5

    On a weekend trip to buffalo from Toronto we made a pit stop at Niagara Falls on the Canadian side. I took this shot with my nexus 5 smartphone. I was randomly shooting the falls themselves from different viewpoints when I happened to get a pretty lucky and interesting shot of this lone seagull on patrol over the falls. I didn't even realize I had captured it in the shot until I went back through the photos a few days later

    Jassen T./National Geographic Traveler Photo Contest

    National Geographic Traveler Photo Contest Entries

    Slide 6

    Incredibly beautiful and extremely remote. Koehn Lake, Mojave Desert, California. Aerial Image.

    Howard Singleton/National Geographic Traveler Photo Contest

    National Geographic Traveler Photo Contest Entries

    Slide 7

    Lucky timing! The oxpecker was originally sitting on hippo's head. I could see the hippo was going into a huge yawn (threat display?) and the oxpecker had to vacate it's perch. When I snapped the pic, the oxpecker appeared on the verge of being inhaled and was perfectly positioned between the massive gaping jaws of the hippo. The oxpecker also appears to be screeching in terror and back-pedaling to avoid being a snack!

    Abrar Mohsin/National Geographic Traveler Photo Contest

    National Geographic Traveler Photo Contest Entries

    Slide 8

    The Yetis of Nepal - The Aghoris as they are called are marked by colorful body paint and clothes

    Madeline Crowley/National Geographic Traveler Photo Contest

    National Geographic Traveler Photo Contest Entries

    Slide 9

    Taken from a zodiac raft on a painfully cold, rainy day

    Ian Bird/National Geographic Traveler Photo Contest

    National Geographic Traveler Photo Contest Entries

    Slide 10

    This wave is situated right near the CBD of Sydney. Some describe it as the most dangerous wave in Australia, due to it breaking on barnacle covered rocks only a few feet deep and only ten metres from the cliff face. If you fall off you could find yourself in a life and death situation. This photo was taken 300 feet directly above the wave from a helicopter, just as the surfer is pulling into the lip of the barrel.

  • Recent Slide Shows

Comments

0 Comments

Comment Preview

Your name will appear as username ( settings | log out )

You may use these HTML tags and attributes: <a href=""> <b> <em> <strong> <i> <blockquote>