No Silver Bullet: Essence and Accidents of Software Engineering

Picture an example (written for this write-up, like the code below): you type one line into an AI coding assistant, "add partial refunds to checkout", and moments later the code fills your screen: a request handler, a database query, a call to the payment provider. If code arrives that fast, does building software get ten times faster? Or was typing never the hard part?

In 1986, long before tools like this existed, Fred Brooks wrote a paper that answers a version of that question. Every paper in this library is read the same way: we start from something you use today, read the paper in its own words, draw its idea step by step, and then check what has aged.

The Problem in 1986

Frederick P. Brooks, Jr. was the Kenan Professor of Computer Science at the University of North Carolina at Chapel Hill, and already known for a book about software projects, The Mythical Man-Month (1975). He gave this paper as an invited talk at the IFIP Congress in Dublin in September 1986. It was printed in Information Processing 86 (pages 1069 to 1076), reprinted in IEEE Computer in April 1987, and again in the 1995 anniversary edition of The Mythical Man-Month. The quotes on this page come from the University of North Carolina technical report of the same paper, TR86-020 (September 1986), with its own page numbers.

He opens with a werewolf: the monster that turns without warning from something familiar into a horror. A software project, he says, looks "usually innocent and straightforward, but capable of becoming a monster of missed schedules, blown budgets, and flawed products." So people cry out for a silver bullet, "something to make software costs drop as rapidly as computer hardware costs do."

And hardware really was racing ahead. Brooks points out that "no other technology since civilization began has seen six orders of magnitude price-performance gain in 30 years." An order of magnitude is a factor of ten, so six of them is a factor of a million. His point: the anomaly is not that software improves slowly, it is that hardware improved so fast.

The Bet

But, as we look to the horizon of a decade hence, we see no silver bullet. 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. …

(p. 2)

Each part of the sentence matters:

He is careful about what he is not claiming:

Skepticism is not pessimism, however. Although we see no startling breakthroughs, and indeed, believe such to be inconsistent with the nature of software, many encouraging innovations are under way. A disciplined, consistent effort to develop, propagate, and exploit them should indeed yield an order-of-magnitude improvement. There is no royal road, but there is a road.

(p. 2)

No shortcut, but a path: many steps together can reach ten times, even if no single one does.

Essence and Accident

Go back to the refund code. One line in it reads:

const amount = Math.min(req.body.amount, order.paid)

It caps every refund at the amount the customer paid. That is not typing. It is a decision about the shop, and nobody actually made it: the tool guessed. (The code here is written for this write-up, not captured from a real tool.)

Behind the feature sit many decisions like that one, and then the work of telling a computer the answers:

Brooks splits the difficulty of software along exactly this line:

… Following Aristotle, I divide them into essence, the difficulties inherent in the nature of the software, and accidents, those difficulties which today attend its production but which are not inherent.

(p. 2)

Accident does not mean a mistake. It means a difficulty that comes from how we build software today, not from the problem itself. The essence is what he calls "a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions": the web of decisions. And he says which kind is harder:

… I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.

(pp. 2 to 3)

The Arithmetic

Put rough numbers on the refund feature, made up just for this picture: ten days of work, one day per block, six days of decisions and four of expression. Now imagine a tool that removes every bit of the accident, instantly. How much faster does the whole feature get?

The four days vanish, but the six days of decisions are still there. Ten days become six: about 1.7 times faster, nowhere near ten. To get ten times faster, the accident would have to be nine days out of every ten, so that removing it leaves one.

That is the arithmetic in his abstract:

… How much of what software engineers now do is still devoted to the accidental, as opposed to the essential? Unless it is more than 9/10 of all effort, shrinking all the accidental activities to zero time will not give an order of magnitude improvement.

(p. 1)

Later he writes it as the productivity equation (p. 13):

time of task = Σᵢ (frequency)ᵢ × (time)ᵢ

The time of a task is the sum, over its parts, of how often each part happens times how long it takes. He believed the conceptual parts were already taking most of the time, so "no amount of activity on the task components that are merely the expression of the concepts can give large productivity gains."

Why the Essence Stays Hard

Brooks names four properties of the essence of every large program.

Complexity

Software is "more complex for [its] size than perhaps any other human construct, because no two parts are alike" (p. 3). A building repeats the same window many times; in software, two parts that are alike get merged into one subroutine, so what is left is all different parts, and they affect each other. With three refund rules there are three pairs that can clash; with six rules there are fifteen, because each new rule can clash with every rule already there. In Brooks's words, "the complexity of the whole increases much more than linearly." From it come hard communication inside a team, more states than anyone can list, and changes that cause side effects.

Conformity

A physicist faces complex things too, but works "in a firm faith that there are unifying principles to be found." Brooks says "no such faith comforts the software engineer" (p. 4). The refund feature must fit the payment provider's refund rules, the tax rules where the shop sells, and the format the accounting team imports. These interfaces differ "not because of necessity but only because they were designed by different people," and that complexity "cannot be simplified out by any redesign of the software alone."

Changeability

"All successful software gets changed" (p. 4). Buildings and cars change rarely once they are built, partly because "the high costs of change, understood by all, serve to dampen the whims of the changers." Software is "pure thought-stuff, infinitely malleable," so the requests never stop. Two forces drive them: users who like a product stretch it to new uses (refunds in the mobile app, to gift cards, in a second country), and software outlives the machines it was written for (in 1986, new disks, displays and printers; for us, new phones and browsers).

Invisibility

An architect can hand a client a floor plan, and both can see the rooms, the doors and the mistakes. Software "is not inherently embedded in space," so it has no such picture (p. 5). Draw the refund feature's parts and you get several graphs on top of each other: "the flow of control, the flow of data, patterns of dependency, time sequence, name-space relationships." They are "usually not even planar, much less hierarchical," which hinders design inside one head and communication between heads.

Past Wins Hit the Accident

The big gains of the past came from removing accidents (pp. 5 to 6):

Each win leaves a smaller accident for the next. As he says of languages, "once those accidents have been removed, the remaining ones are smaller, and the payoff from their removal will surely be less" (p. 7).

The Hopes of 1986

Brooks asks of every candidate: does it attack the essence, or only what is left of the accident? (pp. 7 to 12)

Every one lands on the accident: a real help, not a silver bullet.

Artificial Intelligence

The hope that matters most for us gets its own section:

Many people expect advances in artificial intelligence to provide the revolutionary breakthrough that will give order-of-magnitude gains in software productivity and quality {3}. I do not. …

… The hard thing about building software is deciding what one wants to say, not saying it. No facilitation of expression can give more than marginal gains.

(p. 8)

He borrows two definitions from David Parnas. AI-1: "the use of computers to solve problems that previously could only be solved by applying human intelligence," a definition with a "sliding meaning": once we understand how a program works, we stop calling it AI. AI-2: heuristic or rule-based programming built from the rules of thumb of human experts, the expert systems of the day. For expert systems, he expected their most powerful contribution to be "to put at the service of the inexperienced programmer the experience and accumulated wisdom of the best programmers," and added: "This is no small contribution" (p. 10).

What about a tool that writes the whole program from a plain description? Brooks covers that too, as automatic programming, which people had anticipated "for almost 40 years." Parnas called it "a euphemism for programming with a higher-level language than was presently available to the programmer," and argued that "in most cases it is the solution method, not the problem, whose specification has to be given" (p. 10).

Attacks on the Essence

What does work? Attacks on the essence itself (pp. 13 to 17).

Buy, don't build. "The most radical possible solution for constructing software is not to construct it at all." Even at $100,000, bought software cost "only about as much as one programmer-year," and delivery was immediate. And "the use of n copies of a software system effectively multiplies the productivity of its developers by n."

Buying skips the building, not every decision: "The key issue, of course, is applicability. Can I use an available off-the-shelf package to do my task?" (p. 14).

Why had buying become practical? Not because the packages changed much, he argues, but because of the hardware/software cost ratio. "The buyer of a two-million dollar machine in 1960 felt that he could afford $ 250,000 more for a customized payroll program," while "the buyer of a $ 50,000 dollar office machine today cannot conceivably afford a customized payroll program; so he adapts his payroll procedure to the packages available" (p. 14). The dramatic exceptions he names are "electronic spreadsheets and simple database systems," which let many users solve new problems "without ever writing a program."

Refine the requirements with rapid prototypes.

The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is so difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. …

(p. 14)

"The client does not know what he wants," and cannot specify it exactly "before having built and tried some versions of the product." A prototype "simulates the important interfaces and performs the main functions," so the client can test the decisions early. In the refund feature, that is how the coupon question gets its answer: the shop owner tries a rough version and decides that coupon orders are refunded at the price actually paid.

Grow, don't build. In 1958 Brooks first heard a friend talk about building a program instead of writing one, and the metaphor (specifications, components, scaffolding) stuck. Now he argues it is time to change it again. Following Harlan Mills, first make the whole system run, "even though it does nothing useful except call the proper set of dummy subprograms," then flesh it out bit by bit, so that at every stage there is a working system. "Teams can grow much more complex entities in four months than they can build."

Grow great designers. "The very best designers produce structures that are faster, smaller, simpler, cleaner, and produced with less effort. The differences between the great and the average approach an order of magnitude." Of the gains Brooks puts a number on, the only one near ten times is not a tool; it is the gap between great and average designers. (That is our reading of the paper, not his sentence.) His proposal: treat great designers as being "as important to its success as great managers are," and develop them deliberately, with mentors, career plans and apprenticeships.

Where It Lives Today: AI Tools, Measured

Two careful experiments give a first, partial answer to the opening question.

METR's abstract states the second result plainly: "Before starting tasks, developers forecast that allowing AI will reduce completion time by 24%. After completing the study, developers estimate that allowing AI reduced completion time by 20%. Surprisingly, we find that allowing AI actually increases completion time by 19%--AI tooling slowed developers down."

Neither study measured essence and accident, so treat what follows as a question, not a verdict. Brooks's picture suggests one reading: a small server built from scratch to a clear task is mostly expression, while a change inside a large project you know well is mostly deciding.

What Aged

The Takeaway

Every feature has two kinds of work: deciding what the software must do, and expressing it to a machine. Languages, time-sharing, better tools and now AI assistants have all shrunk the expression. The decisions stay, and Brooks's best attacks work on them directly: buy what you can, prototype to find out what to build, grow the system, and grow great designers.

Tools can shrink the work of saying it, but the hard part is still deciding what to say.

Twenty years later, Ben Moseley and Peter Marks kept Brooks's two words but questioned where he drew the line: they "disagree with his premise that most complexity remaining in contemporary systems is essential," and argue that "much complexity that we do see in existing software is not essential (to the problem)." So, in Out of the Tar Pit: if much of what feels essential is complexity we made ourselves, where does it come from?

References

• Frederick P. Brooks, Jr., "No Silver Bullet: Essence and Accidents of Software Engineering," Information Processing 86, H.J. Kugler, ed., Elsevier Science Publishers B.V. (North Holland), 1986, pp. 1069 to 1076. Quoted from University of North Carolina technical report TR86-020, September 1986. cs.unc.edu/techreports/86-020.pdf. Publication record: Brooks's page at UNC.
• Sida Peng, Eirini Kalliamvakou, Peter Cihon, Mert Demirer, "The Impact of AI on Developer Productivity: Evidence from GitHub Copilot," arXiv 2302.06590, 2023. arxiv.org/abs/2302.06590.
• Joel Becker, Nate Rush, Elizabeth Barnes, David Rein (METR), "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity," arXiv 2507.09089, 2025. arxiv.org/abs/2507.09089.
• Mark Chen et al., "Evaluating Large Language Models Trained on Code," arXiv 2107.03374, 2021. arxiv.org/abs/2107.03374.
• npm Docs, "About npm." docs.npmjs.com/about-npm.
• Ben Moseley, Peter Marks, "Out of the Tar Pit," 2006. curtclifton.net/papers/MoseleyMarks06a.pdf.