first WSJ oped:
Today's Pentagon is losing its most important battle, the one for its own future. The Defense Department's latest evaluation report on the F-35 Joint Strike Fighter reveals how badly that fight is going, and why.
There have been many stories about the F-35 Lightning II's problems and delays, and its looming total price tag of $1 trillion, up from prior estimates of $331 billion and $177 billion before that. Still, the DOD's Jan. 14 report zeroes in on the key issue: software and information technology.
All five software "blocks"—systems to take the plane from testing to full production—that Lockheed Martin is contracted to develop for the Lightning II are behind schedule and over budget. The testing of software for producing F-35s won't get done until 2017. Any new glitches that are found will likely delay deployment even longer.
The fault, however, doesn't lie with Lockheed Martin, or even with the F-35.
The problem is how the Pentagon goes about acquiring the IT and software that modern weapons systems need. If this problem doesn't get fixed, any hope of building a 21st-century American military will be doomed.
The complexity of the software that the F-35 fighter needs is staggering, almost incomprehensible. It runs to almost 10 million lines of software source code. The man in charge of the F-35 program, Maj. Gen. Chris Bogdan, has been quoted as saying about thesoftware, "it scares the heck out of me"—because he knows in the world of high tech, complexity is the enemy of effectiveness.
Reuters/Lockheed Martin
The U.S. Marine Corps version of Lockheed Martin's F-35 Joint Strike Fighter, F-35B test aircraft BF-2 flies with external weapons.
Yet that's the dilemma the Pentagon faces every day when it comes to IT and software.
For example, the Air Force's Oracle -based Expeditionary Combat Support System was supposed to be ready in October 2013. Having spent $1 billion already, it needed another $1 billion just to get to one-quarter functionality by 2020. ECCS was supposed to automate the Air Force's management of parts and equipment. This inherent complexity of the acquisitions process effectively killed ECCS and led to the rampant cost overruns that also killed the Navy's DDG1000 destroyer late last year.
The Pentagon acquires IT and software-based systems the way it buys aircraft carriers—as if they were physical items to be forged or welded or mass-produced. The standard procurement cycle is geared around multiyear milestones and intensive evaluation reviews that can take months or years.
The modern software development cycle, by contrast, moves in weeks, days and even hours—because software is a malleable digital item whose only limits are the human imagination.
In addition, the Pentagon relies on a bureaucratic review process that demands contractors anticipate and resolve problems in advance. Every software engineer, however, knows that's not possible or even desirable.
Modern software constantly evolves. Engineers know that repeated test cycles in small portions at a time work best. Designers can learn from mistakes and glitches embedded in initial and early versions, and they can learn as well from early users of these versions.
More important, designers can take advantage of technologies that are unknown today but emerge later on. Learning by trial and error doesn't work so well for aircraft carriers or Abrams tanks, but it is crucial for the development of effective software.
The DOD's current acquisition strategy hasn't caught up or caught on. By treating software as if it were a product instead of a process, our military services are shutting themselves off from the kind of cost-efficient innovation that rules in the commercial software and IT industries. Amazon, for example, can make over 30 changes a week to its portal, from adding simple code changes to new complex features, without a major glitch. Our service personnel know this only too well, when they see how their children's videogames work better and have more sophisticated apps than the electronic gear they have to use in the field—and at a fraction of the cost.
The Pentagon has tried to go around the problem by buying off-the-shelf software for some systems. But that only postpones the inevitable frustration when it comes time to design software that can integrate those commercial products into warfighting systems. This is what happened when the Air Force tried to create the Expeditionary Combat Support System, which ended up as a $2 billion boondoggle.
Instead, the Pentagon needs a modern software and IT acquisition process that's as flexible, agile and open-ended as software itself—one that's geared for Moore's Law (computing power doubles every 18 months) and Butter's Law (network capacity costs get halved every nine months) instead of Murphy's Law.
Until we do, expect more messes like the F-35 and DDG 1000—which we ultimately can't afford and our fighting men and women ultimately won't survive.
Mr. Herman is the author of "Freedom's Forge: How American Business Produced Victory in World War Two" (Random House, 2012). Mr. Scott is a senior system engineer for Radiant Blue Technologies and co-wrote "Open Technology Development: Lessons Learned and Best Practices for Military Software" (Department of Defense, 2011).
A version of this article appeared Feb. 12, 2013, on page A15 in some U.S. editions of The Wall Street Journal, with the headline: Send in the Tech Reinforcements.
Recent Comments