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

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
    Burger King Japan

    2014's fast food atrocities

    Burger King's black cheeseburger: Made with squid ink and bamboo charcoal, arguably a symbol of meat's destructive effect on the planet. Only available in Japan.

    Elite Daily/Twitter

    2014's fast food atrocities

    McDonald's Black Burger: Because the laws of competition say that once Burger King introduces a black cheeseburger, it's only a matter of time before McDonald's follows suit. You still don't have to eat it.

    Domino's

    2014's fast food atrocities

    Domino's Specialty Chicken: It's like regular pizza, except instead of a crust, there's fried chicken. The company's marketing officer calls it "one of the most creative, innovative menu items we have ever had” -- brain power put to good use.

    Arby's/Facebook

    2014's fast food atrocities

    Arby's Meat Mountain: The viral off-menu product containing eight different types of meat that, on second read, was probably engineered by Arby's all along. Horrific, regardless.

    KFC

    2014's fast food atrocities

    KFC'S ZINGER DOUBLE DOWN KING: A sandwich made by adding a burger patty to the infamous chicken-instead-of-buns creation can only be described using all caps. NO BUN ALL MEAT. Only available in South Korea.

    Taco Bell

    2014's fast food atrocities

    Taco Bell's Waffle Taco: It took two years for Taco Bell to develop this waffle folded in the shape of a taco, the stand-out star of its new breakfast menu.

    Michele Parente/Twitter

    2014's fast food atrocities

    Krispy Kreme Triple Cheeseburger: Only attendees at the San Diego County Fair were given the opportunity to taste the official version of this donut-hamburger-heart attack combo. The rest of America has reasonable odds of not dropping dead tomorrow.

    Taco Bell

    2014's fast food atrocities

    Taco Bell's Quesarito: A burrito wrapped in a quesadilla inside an enigma. Quarantined to one store in Oklahoma City.

    Pizzagamechangers.com

    2014's fast food atrocities

    Boston Pizza's Pizza Cake: The people's choice winner of a Canadian pizza chain's contest whose real aim, we'd imagine, is to prove that there's no such thing as "too far." Currently in development.

    7-Eleven

    2014's fast food atrocities

    7-Eleven's Doritos Loaded: "For something decadent and artificial by design," wrote one impassioned reviewer, "it only tasted of the latter."

  • 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>