Remark: This post is some excerpts from Programming as Theory Building (Peter Naur, 1985). In the software industry, there are too many movements, but too few insights. The movements come and go, the insights last. This paper is one of the three papers that shape my views on programming. The other two are No Silver Bullet (Fred Brooks, 1986) and Reality: a cousin twice removed (Bertrand Meyer, 1996).
Programming: Theory Building VS. Text Production
Programing should be regarded as an activity by which the programmers form or achieve a certain kind of insight, a theory, of the matters at hand.
Programming must be the programmers’ building up knowledge of a certain kind, knowledge taken to be basically the programmers’ immediate possession, any documentation being an auxiliary, secondary product.
The programmers’ knowledge properly should be regarded as a theory, in the sense of Ryle (1949). Very briefly, a person who has or possesses a theory in this sense knows how to do certain things and in addition can support the actual doing with explanations, justifications, and answers to queries, about the activity of concern.
The notion of theory employed here is explicitly not confined to what may be called the most general or abstract part of the insight…, the person having the theory must have an understanding of the manner in which the central laws apply to certain aspects of reality, so as to be able to recognize and apply the theory to other similar aspects.
…the theory build by the programmers has primacy over such other products as program texts, user documentation, and additional documentation such as specification.
(1) The programmer having the theory of the program can explain how the solution relates to the affairs of the world that it helps to handle.
(2) The programmer having the theory of the program can explain why each part of the program is what it is, in other words is able to support the actual program text with a justification of some sort.
(3) The programmer having the theory of the program is able to respond constructively to any demand for a modification of the program so as to support the affairs of the world in a new manner.
- text production view: low cost
- theory building view: hard, high cost
…flexibility can in general only be achieved at a substantial cost.
The decay of a program text as a result of modifications made by programmers without a proper grasp of the underlying theory becomes understandable.
The very notion of qualities such as simplicity and good structure can only be understood in terms of the theory of the program, since they characterize the actual program text in relation to such program texts that might have been written to achieve the same execution behavior, but which exists only as possibilities in the programmer’s understanding.
Program Life, Death and Revival
An essential part of any program, the theory of it, is something that could not conceivably be expressed, but is inextricably bound to human beings.
The building of the program is the same as the building of the theory of it by and in the team of programmers. During the program life a programmer team possessing its theory remains in active control of the program, and in particular retains control over all modifications.
The death of a program happens when the programmer team possessing its theory is dissolved.
Revival of a program is the rebuilding of its theory by a new programmer team.
Program revival, that is reestablishing the theory of a program merely from the documentation, is strictly impossible.
In preference to program revival, the Theory Building View suggests, the existing program text should be discarded and the new-formed programmer team should be given the opportunity to solve the given problem afresh.
Method and Theory Building
In building the theory there can be no particular sequence of actions, for the reason that a theory held by a person has no inherent division into parts and no inherent ordering.
It follows that on the Theory Building View, for the primary activity of the programming there can be no right method.
The notion of the programmer as an easily replaceable component in the program production activity has to be abandoned. Instead the programmer must be regarded as a responsible developer and manager of the activity in which the computer is is part.
…he or she must be given a permanent position, of a status similar to that of other professionals, such as engineers and lawyers, whose active contributions as employers of enterprises rest on their intellectual proficiency.
While skills such as the mastery of notions, data representations, and data processes, remain important, the primary emphasis would have to turn in the direction of furthering the understanding and talent for theory formation.
There are two different usage of the concept theory in the paper:
- some inexpressible capabilities of the programmer
- some entity (abstract?) being built as part of programming activity
It seems that there are at least two different kind of theories or knowledge that the author failed to differentiate:
- knowledge about the code design, organization and details
- knowledge about the theory for the matters at hand
The author also indicated in a lot of places that the theory is not expressible. This adds some mystery to the nature of theory. If it is not expressible, what is the way to transmit or communicate such theory in a team? How to reflect on such theory?
- Programming as Theory Building, PeterNaur, 1985
- No Silver Bullet, Fred Brooks, 1986
- Reality: a cousin twice removed, Bertrand Meyer, 1996