Programming as Theory Building, Peter Naur, 1985 Paper link
Peter Naur has made seminal contributions to programming languages, particularly through the Backus-Naur form (BNF) notation. This paper was written in 1985 but the essential ideas and observations remain still very relevant. In fact, in may be argued that with distributed groups of programmers working on codebases of growing complexity, the viewpoint of programming presented here is even more useful now. The paper makes the case that through the act of programming, the programmer builds useful abstractions and mental models of the problem and the proposed solution. This view, called the theory-building view in the paper, is distinct from the view of programmer as producer of text - source code, documentation, test cases.
The usefulness of theory-building view is shown by examples of what happens when an existing well-functioning codebase has to be extended to more use-cases or respond to changes in the environments in which the software operates. Such extensions are often undertaken by a different set of programmers than the ones who wrote the software in the first place. It’s usually been observed (by the original programmers) that the way these extensions are designed and implemented have more of a patchwork quality, rather than fitting within the core ideas and abstractions of the original system. If the new group still is able to communicate with the original group, the latter can course correct the design proposals early so that the extended system is coherent and effective. It’s also been observed that the existing documentation from the original programmers is not drawn upon as much as we would normally expect. All of these taken together suggest that the original programmers’ group built useful mental models in the course of developing the software and trying to convey that via documentation alone is very insufficient. There’s nothing like talking directly to the programmers who wrote the software in the first place.
Naur also suggests that a more effective way of conveying such theories is via metaphors that give the essence of what the software intends to do. For a given program, one can say for instance that it’s like producer-consumer, it does load balancing, it’s model of incoming requests is like an assembly line. For a new programmer, understanding of an existing codebase can flow more easily and effectively if anchored in well-chosen abstractions. This hints that an important purpose of documentation then is to convey such metaphors effectively.
Naur advises that organizations would do well to understand what good programmers do when they go about writing software. Such an understanding shows us how ineffective it can be to try to replace one set of programmers with another, assuming that all that is needed is change of hands working on the system and they can take what came before and simply build on top of that. Of course, this can be done but the resulting system may be bloated and hard to maintain. The implication of all this is also that the activity of and challenges inherent in programming be given its due respect.