Programming as Theory Building
Probably the most profound essay on what programming actually is.
Naur argues that a program is not the code but the theory in the programmers' heads — the understanding of how the code maps to the real-world problem.
When the original programmers leave, the theory dies even if the code survives.
This explains why rewrites are so costly, why documentation never suffices, and why Conway's law is not a joke but a theorem.
For anyone managing a codebase or a team, Naur makes visible the invisible asset that determines whether software can evolve or only decay.
Central argument
Naur argues that programming is fundamentally an act of theory building, not text production: the real output of a programmer's work is a mental model — a theory — of how a problem in the world is solved by a particular program. The code is merely a residue of that theory, not the theory itself. This leads to his core claim: when the programmers who built a system leave, the theory is lost irreversibly, and no documentation, comment, or specification can reconstruct it, because theory is tacit knowledge that cannot be fully externalised. Consequently, maintaining or extending software without its original theory-holders is not a documentation problem but an epistemological one.
Critique
Naur's framework, written in 1985, implicitly assumes a relatively small, stable team where individual cognition is the dominant unit of knowledge — a model that sits uneasily with large distributed systems built by hundreds of contributors over decades, where no single person ever held a complete theory. One could argue that modern practices like architecture decision records, living documentation, and domain-driven design are precisely attempts to socialise and distribute theory across people and artefacts, and Naur underestimates how much of that tacit knowledge can be encoded in shared practice and tooling rather than individual minds. His pessimism about knowledge transfer may be empirically correct in the cases he observed, but it risks becoming a self-fulfilling prophecy that discourages investment in the organisational and artefactual structures that partially compensate for individual departure.
Why it matters for product
For a CPO, Naur reframes team attrition as something far more damaging than a hiring problem: losing a senior engineer who owns a critical subsystem is not a headcount gap but a permanent destruction of the theory that makes that system legible and evolvable, which directly degrades the product's ability to absorb new requirements. This has concrete implications for how product leaders should think about team continuity during reorganisations, the hidden cost of outsourcing core platform work, and why velocity often collapses after a rewrite that looked cheaper on paper — the new team is rebuilding theory from scratch, not just code. It also offers a more precise language for defending investments in engineering stability to a board: you are not paying for code, you are paying to keep the theory alive.