{"course":{"slug":"how-software-changed","title":"How Software Development Changed","url":"https://addaly.com/learn/how-software-changed","level":"intermediate","track":"work"},"lesson":{"slug":"essence-and-accident","title":"The distinction that keeps being right","url":"https://addaly.com/learn/how-software-changed/essence-and-accident","position":79,"of":87,"minutes":9,"answer":"Generation attacks the accidental difficulty of expressing a decision and leaves the essential difficulty of making one, which is why identical tools produce large gains on representation-dominated work and none where requirements.","keyIdea":"Generation attacks the accidental difficulty of expressing a decision and leaves the essential difficulty of making one, which is why identical tools produce large gains on representation-dominated work and none where requirements, domain or organisational agreement are the constraint."},"body":{"format":"markdown","text":"## A forty-year-old argument, restated\n\nIn 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.\n\nThe 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.\n\nBrooks'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.\n\nThat is exactly the shape of what happened here, which is why the argument keeps coming back.\n\n## The four essential difficulties, against a generator\n\nBrooks named four properties of the essence. Read them against a tool that writes code.\n\n**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.\n\n**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.\n\n**Changeability.** Successful software gets changed, because success reveals uses nobody planned for. Generation makes each change cheaper and makes more changes arrive.\n\n**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.\n\n## Where the argument is weaker than it sounds\n\nIt would be dishonest to present this as settled wisdom, because the central distinction has a real problem: **the line between essential and accidental moves.**\n\nManual 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.\n\nSo \"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.\n\nThere 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.\n\n## Conway, still undefeated\n\nThe other 1960s result that refuses to age: organisations produce designs that copy their own communication structure. Conway's observation, 1967.\n\nIt 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.\n\nNothing 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.\n\n## Why this is the useful frame\n\nBecause 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.\n\nAnd 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.\n\n> 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."},"check":{"question":"Two teams adopt the same assistant. One measures a large improvement on a language migration; the other measures none on a new billing feature. What best explains the difference?","options":[{"text":"The migration team had better prompting discipline, so they extracted more from the same tool.","correct":false,"tempting":"Attributes it to skill with the tool when the two tasks have different proportions of essential difficulty."},{"text":"Billing code is more security-sensitive, so the second team spent the gains on extra review.","correct":false,"tempting":"Plausible as a secondary effect but does not explain why the gain failed to appear in the first place."},{"text":"Migration expresses settled decisions; billing is dominated by deciding what should happen.","correct":true},{"text":"Models are trained on more migration examples than on billing domain logic, so coverage differs.","correct":false,"tempting":"A data-volume story that would predict improvement on any well-represented domain, which is not what is observed."}]},"prev":{"slug":"maintainers-and-the-flood","title":"The commons under a flood of free submissions","url":"https://addaly.com/learn/how-software-changed/maintainers-and-the-flood"},"next":{"slug":"one-way-doors","title":"Decisions that do not swing back","url":"https://addaly.com/learn/how-software-changed/one-way-doors"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'The distinction that keeps being right', in How Software Development Changed. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/how-software-changed/essence-and-accident (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"The distinction that keeps being right","courseTitle":"How Software Development Changed","module":{"index":9,"slug":"what-did-not-change","title":"What did not change, and what to do now"},"answer":null,"keyIdea":"Generation attacks the accidental difficulty of expressing a decision and leaves the essential difficulty of making one, which is why identical tools produce large gains on representation-dominated work and none where requirements, domain or organisational agreement are the constraint.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"a-forty-year-old-argument-restated","runs":[{"text":"A forty-year-old argument, restated"}]},{"t":"p","runs":[{"text":"In 1986 Fred Brooks published "},{"text":"No Silver Bullet: Essence and Accidents of Software Engineering","i":true},{"text":". 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."}]},{"t":"p","runs":[{"text":"The argument rests on a split. "},{"text":"Accidental","b":true},{"text":" difficulty is the work of representing an idea on a machine: the syntax, the memory management, the build system, the boilerplate. "},{"text":"Essential","b":true},{"text":" difficulty is constructing the conceptual object itself: deciding what the thing must do, how its parts relate, and what must never happen."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"That is exactly the shape of what happened here, which is why the argument keeps coming back."}]},{"t":"h2","id":"the-four-essential-difficulties-against-a-generator","runs":[{"text":"The four essential difficulties, against a generator"}]},{"t":"p","runs":[{"text":"Brooks named four properties of the essence. Read them against a tool that writes code."}]},{"t":"p","runs":[{"text":"Complexity.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"Conformity.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"Changeability.","b":true},{"text":" Successful software gets changed, because success reveals uses nobody planned for. Generation makes each change cheaper and makes more changes arrive."}]},{"t":"p","runs":[{"text":"Invisibility.","b":true},{"text":" 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."}]},{"t":"h2","id":"where-the-argument-is-weaker-than-it-sounds","runs":[{"text":"Where the argument is weaker than it sounds"}]},{"t":"p","runs":[{"text":"It would be dishonest to present this as settled wisdom, because the central distinction has a real problem: "},{"text":"the line between essential and accidental moves.","b":true}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"There is also a scoping subtlety people miss. Brooks’s claim was about "},{"text":"a single development within a decade","b":true},{"text":". 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."}]},{"t":"h2","id":"conway-still-undefeated","runs":[{"text":"Conway, still undefeated"}]},{"t":"p","runs":[{"text":"The other 1960s result that refuses to age: organisations produce designs that copy their own communication structure. Conway’s observation, 1967."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"why-this-is-the-useful-frame","runs":[{"text":"Why this is the useful frame"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"quote","runs":[{"text":"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."}]}],"check":{"question":[{"text":"Two teams adopt the same assistant. One measures a large improvement on a language migration; the other measures none on a new billing feature. What best explains the difference?"}],"options":[{"text":[{"text":"The migration team had better prompting discipline, so they extracted more from the same tool."}],"correct":false,"tempting":[{"text":"Attributes it to skill with the tool when the two tasks have different proportions of essential difficulty."}]},{"text":[{"text":"Billing code is more security-sensitive, so the second team spent the gains on extra review."}],"correct":false,"tempting":[{"text":"Plausible as a secondary effect but does not explain why the gain failed to appear in the first place."}]},{"text":[{"text":"Migration expresses settled decisions; billing is dominated by deciding what should happen."}],"correct":true,"tempting":null},{"text":[{"text":"Models are trained on more migration examples than on billing domain logic, so coverage differs."}],"correct":false,"tempting":[{"text":"A data-volume story that would predict improvement on any well-represented domain, which is not what is observed."}]}],"order":[3,1,0,2],"why":null},"prev":{"slug":"maintainers-and-the-flood","title":"The commons under a flood of free submissions","minutes":9},"next":{"slug":"one-way-doors","title":"Decisions that do not swing back","minutes":9}}}