In 2005 the US Air Force asked for software that was “truly ‘off the shelf’: unmodified and available to anyone.” It wanted one system to replace hundreds of old programs that tracked its parts, fuel and planes around the world, and buying commercial software, the Air Force thought, would spare it most of the custom work. A 2006 strategy said the program would forgo any changes to the software.
Then the software met the Air Force’s way of doing things. When the contractor proposed changing Air Force processes to fit the software’s, according to the company, the Air Force resisted and asked for the software to be changed instead. In 2012 the Defense Department cancelled the program, called ECSS, after more than $1 billion had been spent without fielding any usable capability. A Senate investigation called it “a waste of $1.1 billion in taxpayer money, a loss of eight years of effort.” The case has the rest.
Essence and accident
Tools can save the labor of writing code. They can’t decide for you what to build.
Fred Brooks, the computer scientist behind Brooks’s Law, made the argument in a 1986 paper. He split software work in two, borrowing Aristotle’s terms. The essence is the conceptual structure: what the data is, how it relates, what the system must do. The accidents are the labor of writing that structure down in a programming language and fitting it onto a machine.
Most of the big past gains, Brooks wrote, had come from attacking the accidents: high-level languages, faster turnaround, better tools. But unless the accidental work was more than nine-tenths of the effort, shrinking it to nothing would not give a tenfold improvement. Hence his forecast, looking “to the horizon of a decade hence”: “There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement in productivity, in reliability, in simplicity.”
“The hardest single part of building a software system,” he added, “is deciding precisely what to build.”
Buying doesn’t decide for you
Brooks wasn’t a pessimist. “Skepticism is not pessimism,” he wrote. Many smaller innovations, pursued with “a disciplined, consistent effort,” should together “yield an order-of-magnitude improvement.”“There is no royal road, but there is a road.” His first suggestion was to buy what can be bought instead of building it. The growing mass market for software, he wrote, was “the most profound long-run trend in software engineering.”
ECSS shows the limit of that advice. Buying the software was supposed to spare the Air Force much of the accidental work, though the three products it got still had to be integrated. What buying couldn’t do was decide how the Air Force should order parts or manage maintenance, and that was the essential question. When the answer the software assumed clashed with the answer the Air Force was used to, the Air Force, by the contractor’s account, changed the software. The Senate investigators put the failure down mainly to resistance to changing business processes, weak leadership and unmanaged risks.
Brooks’s other suggestions point at the essence directly: prototype quickly to find out what users actually need, grow a system a piece at a time instead of building it all at once, and find and develop great designers.
Imagine a small charity that buys a donor-management system to fix its messy fundraising. If nobody first agrees who owns a donor relationship or when a pledge counts as received, the new system may simply hold the same confusion in neater rows.
Is AI the bullet?
AI coding tools are the latest candidate, and the early evidence points both ways. In an experiment published in 2023, developers were asked to build a small web server in JavaScript. Those given GitHub Copilot finished in 55.8 percent less time, on average, than those without it.
A 2025 randomized trial by Joel Becker and colleagues looked at harder conditions: 16 experienced developers working on 246 real tasks in large open-source projects they knew well. Before starting, they expected AI tools to cut their time by 24 percent; afterward, they believed the tools had cut it by 20 percent. In fact, tasks where AI was allowed took 19 percent longer. The authors caution that the result covers early-2025 tools in one setting.
Brooks’s split offers one reading of the gap. A clean, well-specified task is mostly accidental work, the kind tools are good at shrinking. A change to a large, mature project carries more essence: knowing what the code is for and what the change must not break. That reading is an interpretation, not something either study tested.
Back in 2005, the Air Force bought the software it wanted. What it couldn’t buy was the decision about how it would work.