The accepted way to break up a program was to follow its flow — read, then process, then output. Parnas took one small system, a KWIC index, and decomposed it two ways. The second built each module around a decision likely to change — the input format, the storage, the sort — and hid that decision behind a stable interface. When a change came, the flow-based version rippled through every module; the information-hiding version sealed it in one.

Ousterhout asks you to picture a module as a rectangle: the top edge is its interface (what you must know to use it), the area is its functionality (what it does). A deep module is tall and narrow — a small interface over a lot of hidden work. A shallow one is wide and short — nearly as much exposed as hidden, so it barely pays for the interface it adds. Thin wrappers and a scatter of tiny classes (“classitis”) are shallow, and shallow is negative value.

Conway argued that any organisation that designs a system produces a design whose structure is a copy of the organisation's communication structure — in his terms a structure-preserving map, a homomorphism. Three teams building a compiler will tend to ship a three-pass compiler. The paper was rejected by the Harvard Business Review; Fred Brooks rescued it in The Mythical Man-Month and gave it its name. MIT and Harvard researchers later found strong support for it under the name “the mirroring hypothesis.”

McIlroy, who invented the Unix pipe, distilled the Unix philosophy: write programs that do one thing and do it well, and write programs to work together. The power is not in any single tool but in their composition through a shared, simple interface (text streams). Each tool stays small and replaceable; the system's capability emerges from combining them.

Brooks borrowed Aristotle. Software's difficulties are essential — inherent in the problem, the interlocking complexity of the concepts — or accidental, attending its production but not inherent: clumsy languages, slow machines, repetition. Progress had attacked the accidental, with real gains; but because the hard part is conceiving and specifying the thing, no single advance yields an order-of-magnitude improvement. The hardest single part, he said, is deciding precisely what to build.

Hickey separated two words we conflate. Simple is objective — how many concerns are braided together. He went to the root: simplex, one fold; complecti, to braid together. To make simple is to decomplect — un-braid. Easy is relative — “to lie near,” familiar, in reach. They're different axes: a familiar one-liner can be easy yet produce complexity, because it braids concerns; the simple thing may be unfamiliar. We keep choosing easy and pay later, because entanglement is what makes a system hard to change.

Knuth's most-quoted line: premature optimization is the root of all evil. The fuller thought is that we should ignore small efficiencies most of the time, but not pass up the critical few — and find, by measuring, where the time actually goes. Twisting code for speed before you know the hot path buys nothing and costs clarity. (Knuth half-credited Hoare for the line; Hoare didn't recall saying it, so it is standardly Knuth's — a contested attribution.) His other contribution, literate programming, treats a program as writing for humans first.

Hunt and Thomas coined DRY: every piece of knowledge must have a single, authoritative representation in a system. The crucial word is knowledge, not text — two pieces of code that merely look alike but encode different things are not a violation, and duplicating them is correct. Metz named the failure on the other side: the wrong abstraction. Someone unifies two similar pieces; requirements diverge; rather than pulling the abstraction apart, people add flags and conditionals so it serves every case; it rots. Her rule: when you're adding parameters to make an abstraction fit a new case, re-inline it — duplicate the code back — then re-abstract along the seam that actually fits. “Duplication is far cheaper than the wrong abstraction.”

Dijkstra's 1968 letter argued that unrestricted goto makes a program impossible to reason about, and that control flow should be limited to a few well-behaved structures — sequence, selection, iteration — so the static text matches the running process. (The title “Go To Statement Considered Harmful” was added by the editor, Niklaus Wirth.) In 1974 he coined separation of concerns: study one aspect at a time, in isolation, because no one can hold everything at once. His recurring theme — the humble programmer — is that our intellectual powers are limited, so good structure is a concession to that limit, not a luxury.

Pólya, a mathematician, set out four phases for solving any problem: understand it, devise a plan, carry out the plan, then look back to check and reflect. Around them, heuristics — solve a simpler related problem, work backwards, find a pattern, draw a figure. It predates computing by decades, but it is exactly how you break a build into tractable pieces.

A program is not fundamentally the code or its documents — it is a theory held in the minds of those who built it: how it maps to the world, why it's shaped this way, what each part is for. Naur drew on Gilbert Ryle's sense of a theory as knowing-how: those who hold it can answer new questions and extend the program without violating its logic. And it can't be fully written down — so when the team disperses, the program dies; a new team working from the artifact alone damages it with changes that look reasonable but break the unseen logic.

Evans argued that a team — developers and domain experts together — should share one rigorous language, used in conversation and in the code alike. If the business says “policy” and “claim,” the code says Policy and Claim. The model is not a diagram drawn once; it is a living distillation of the domain's knowledge, refined continuously — and the language and the model are the same thing. A model is valid within a bounded context; the same word can mean different things in different contexts.

Alexander, an architect, defined a pattern as a recurring problem-in-context together with the core of a solution you can use a million times without ever doing it the same way twice. Behind the patterns lay a deeper claim: a quality without a name — a property of places that are alive, whole, comfortable — that you recognise but can't fully define. He later tried to name it through properties of living structure (levels of scale, strong centres, boundaries, good shape). Alexander directly inspired software's design patterns and the first wikis.

Kay coined “object-oriented programming,” and his own account is that it was never chiefly about classes and inheritance. The big idea, he has said, is messaging. He regrets the word “object” because it pointed people at the wrong thing; the essence is autonomous parts — like cells, or computers on a network — that keep their internal state hidden and coordinate only by sending messages, deciding at runtime how to respond (late binding). The common class-hierarchy picture of OOP is a drift from his actual idea, which is closer to information hiding plus message-passing.

Hoare drew a line between two kinds of design: one so simple that any flaw would be obvious, and one so intricate that no flaw is — and insisted the first is far harder to achieve, and the only trustworthy kind. Complexity that merely hides problems is not the same as soundness. (Hoare also gave us quicksort, and called the null reference his “billion-dollar mistake.”)

An LLM can write clean code that does the wrong thing because it misread the spec. So the pass, in order: right vs works (compare output to the spec, case by case — “it ran” is a different question); edge cases (empty / None / huge / malformed — where generated code is thinnest); invariants (what must always hold — can the code reach a forbidden state?); tests (do they check behaviour, not assert True?).