In 1985, Peter Naur — Turing Award winner, co-author of the Backus–Naur Form — published a short essay with an unassuming title: Programming as Theory Building. It is rarely cited in engineering handbooks, yet it quietly reframes what software development actually is. And, perhaps unintentionally, it offers one of the best arguments for why theoretical computer science is not a luxury for engineers, but a necessity.
Naur’s claim: the code is not the product
Naur’s provocation is simple: programming is not primarily the production of program texts. The executable artifact — the source code, the documentation, the tests — is secondary. The primary activity is the building of a theory in the minds of the programmers.
By „theory“ Naur means something close to Gilbert Ryle’s notion of knowing how rather than knowing that. A programmer who holds the theory of a system can answer questions that no document contains: why the architecture looks this way and not another, which modifications are cheap and which are catastrophic, which user requests fit the system’s grain and which violate its deepest assumptions. The theory is what lets a developer respond intelligently to a new situation — one that was never written down anywhere.
This explains phenomena every practitioner recognizes but classical engineering metaphors cannot:
- Programs „die“ when their team leaves. The code still compiles, the documentation is still on the shelf — yet the system becomes unmaintainable. Naur’s diagnosis: the program’s life is the theory held by its programmers. Lose the people, lose the theory, lose the program. The text is merely a fossil of it.
- Documentation can never be sufficient. Not because engineers are lazy writers, but because a theory in Ryle’s sense is in principle not fully expressible in text. You can record conclusions, but not the capacity to derive new conclusions in unforeseen circumstances.
- Rebuilding is cheaper than reviving. A new team often fares better rewriting a system than inheriting it — because modification requires the theory, and reconstructing a theory from artifacts alone is brutally expensive.
From Naur to theoretical computer science
Here is where the argument turns. If engineering competence consists in holding theories, then the question for engineering education and practice becomes: where do good theories come from?
One answer is experience — Naur’s own view. Theories of specific systems are built by living with those systems. But there is a second, complementary answer, and this is the role of theoretical computer science: TCS provides the general theories within which situation-specific theories can be built.
Consider what a theoretical education actually deposits in an engineer’s mind:
- Computability and complexity theory teach not facts but judgments: which problems resist efficient solution in principle, so that one stops searching for the algorithm that cannot exist and starts reformulating the problem. That is theory in Naur’s sense — a capacity for intelligent response — applied across all possible systems.
- Formal semantics and type theory provide the vocabulary in which claims about program behavior can be stated precisely at all. An engineer without this vocabulary can feel that a design is unsound; an engineer with it can say why, and convince others.
- Automata, logics, and models of concurrency are not academic decorations. They are the shapes of thought — the compressed experience of decades — that let an engineer build a local theory of their system faster, because the general theory is already in place.
Naur noted that a theory holder can do things a mere text-reader cannot. The same holds one level up: an engineer with theoretical foundations can approach a novel problem — a domain, a failure mode, a performance anomaly nobody has seen before — and generate understanding where the purely trained practitioner can only pattern-match against what they have already encountered.
Two kinds of theory, one practice
It helps to be precise about the relationship. Naur’s theory building is particular: the theory of this payroll system, this compiler, this embedded controller. Theoretical computer science is general: theories of computation, information, and structure as such. Neither substitutes for the other.
The general theory without the particular is empty formalism — proofs about nothing anyone runs. The particular theory without the general is fragile craft — intuition that shatters the moment the problem shifts shape. Engineering, at its best, is the continuous act of instantiating general theories into a living, shared, particular theory of a system — and feeding insights back.
This also reframes the eternal curriculum debate. „Should engineers study theory?“ is the wrong question, as if theory were a subject among others. On Naur’s account, all competent engineering is theory building. The only question is whether engineers build their theories with the best conceptual tools available — or rediscover, at great expense and one project at a time, what the theorists already knew.
A closing thought
There is something humbling in Naur’s view. If the real product lives in people’s heads, then engineering is irreducibly human: a matter of shared understanding, cultivated over time, impossible to fully hand over, automate, or file away. Theoretical computer science does not threaten this human core — it strengthens it. It gives minds better theories to build with.
The code is temporary. The theory is the program. And the theories behind the theory — that is what TCS is for.
References: Naur, P. (1985). „Programming as Theory Building.“ Microprocessing and Microprogramming, 15(5). Ryle, G. (1949). The Concept of Mind.
0 Comments