1986 United States meta

No Silver Bullet — Essence and Accident

Fred Brooks, 1986 — the hard part of software is the part you cannot automate away. No tool will deliver an order-of-magnitude improvement in a decade. None did.

Frederick P. Brooks Jr., at the University of North Carolina, drew the distinction between essential and accidental complexity in software. Accidental complexity, he argued, is what comes from the tools and processes — it has been steadily reduced by better languages, libraries, and environments. Essential complexity is what comes from the problem itself — the inherent intricacy of what the software must do. Brooks predicted that no single technology, in either tools or management, would deliver an order-of-magnitude improvement in productivity, reliability, or simplicity within a decade, because the remaining work is essential and essential complexity cannot be tooled away. The prediction has held for forty years. Brooks named the constraint that this book argues AI does not break: the hard part of software is what the software is for, and the next-token predictor does not know what it is for.

In plain terms

Brooks made one move and the entire industry has had to reckon with it ever since. He split the difficulty of software into two piles. The first pile — accidental complexity — is everything that is hard because of the tools, the languages, the environments, the deployment infrastructure, the version-control system, the build process. The accidental pile shrinks as the field matures. Compilers got better, so we stopped writing assembly. Garbage collectors got better, so we stopped managing memory by hand. Type systems got better, so a class of bugs disappeared. IDEs got better, so navigating large codebases got cheaper. All of this is real progress and all of it is accidental complexity going down. The second pile — essential complexity — is everything that is hard because the problem itself is hard. An accounting system has to handle taxes correctly. A medical device has to handle patient overdoses correctly. A scheduling system has to actually schedule. This pile does not shrink with better tools. No language, no framework, no IDE, no AI assistant makes the underlying problem simpler. If the customer wants thirty things, the program must do thirty things, and someone has to figure out what those thirty things are and how they interact. Brooks predicted that since most of the easy gains in accidental complexity had already been harvested by 1986, no future tool would deliver a tenfold improvement in any decade. He was right. Every "this changes everything" technology since — object-oriented programming, agile, the cloud, microservices, DevOps — has produced incremental improvements at best. The 70% maintenance figure from Lehman has stayed roughly 70%. This is the constraint AI now faces. An LLM is a tool. Tools, by Brooks's argument, can only attack accidental complexity. AI tools are good at writing the kind of code humans were already writing — boilerplate, glue code, idiomatic patterns. That is accidental. What AI does not do is figure out what the program is supposed to do, why it is supposed to do that, and how it interacts with everything else in the system. That is essential. And essential complexity is the part Lehman's laws say is rising. The hard part is what the software is for. No tool fixes that.