The distinction that keeps being right

A forty-year-old argument, restated

In 1986 Fred Brooks published No Silver Bullet: Essence and Accidents of Software Engineering. Its claim was narrow and specific: no single development in the following decade would produce an order-of-magnitude improvement in productivity, reliability or simplicity.

The argument rests on a split. Accidental difficulty is the work of representing an idea on a machine: the syntax, the memory management, the build system, the boilerplate. Essential difficulty is constructing the conceptual object itself: deciding what the thing must do, how its parts relate, and what must never happen.

Brooks’s point was that every improvement anyone had made had attacked the accidental half, that this half was already a minority of the effort, and that halving a minority cannot produce an order of magnitude.

That is exactly the shape of what happened here, which is why the argument keeps coming back.

The four essential difficulties, against a generator

Brooks named four properties of the essence. Read them against a tool that writes code.

Complexity. Software has no repeating parts; if two pieces are the same you make them one. So scale means more distinct interacting elements, not more of the same thing. A generator produces elements quickly; it does not reduce how many distinct ones you have to hold.

Conformity. Software must fit arbitrary human institutions: a tax code, a settlement window, a union agreement, a legacy system built by people who have left. This is the one that matters most here, and it is precisely the module-eight point about authorisation and the module-four point about ambiguity. The rules are arbitrary because humans made them up, so there is no way to derive them, and no corpus contains yours.

Changeability. Successful software gets changed, because success reveals uses nobody planned for. Generation makes each change cheaper and makes more changes arrive.

Invisibility. Software has no natural geometry. You cannot look at a system; you can only read representations of parts of it. Generation increases the volume to be represented without improving the representation.

Where the argument is weaker than it sounds

It would be dishonest to present this as settled wisdom, because the central distinction has a real problem: the line between essential and accidental moves.

Manual memory management was essential difficulty for a systems programmer in 1986: it was part of getting the conceptual object right. Garbage collection turned it into accidental difficulty for most work, and then largely removed it. The same happened to writing your own sort, to hand-managing sockets, to laying out a page for four browsers.

So “essential” is not an eternal category. It is relative to the best available abstraction, and abstractions improve. Someone arguing that specification is essential difficulty today is making a claim about now, not a theorem.

There is also a scoping subtlety people miss. Brooks’s claim was about a single development within a decade. Cumulative improvement across many developments over forty years is a different proposition, and by most measures the accidental half has in fact collapsed enormously since 1986. He was arguing against silver bullets, not against progress.

Conway, still undefeated

The other 1960s result that refuses to age: organisations produce designs that copy their own communication structure. Conway’s observation, 1967.

It survives because the mechanism is human coordination, not engineering. An interface between two components is easy to specify when the same person owns both, and becomes a negotiation when it crosses a team boundary, so boundaries in the organisation become boundaries in the software, whatever the architecture document says.

Nothing about faster code writing touches that. If anything the effect sharpens: when implementing is cheap, the cost of a design is dominated by the negotiating, and the negotiating is organisational.

Why this is the useful frame

Because it predicts where disappointment comes from. A team that adopts a tool and measures no improvement usually has a bottleneck in the essence: unclear requirements, a domain nobody understands, three teams who must agree. No amount of faster representation moves those, and the team concludes the tool is useless when the correct conclusion is that it was aimed at the wrong half.

And it predicts where the gains are real. Work that was dominated by representation (a language port, a codemod, boilerplate, an unfamiliar syntax) does get several times faster, and the people reporting that are not deluded.

The test to carry: in the work in front of you, what fraction is deciding what should happen and what fraction is expressing a decision already made? That ratio, not the tool, sets what you should expect.