Software systems development as theory building

At the end of his career Peter Naur writes the article Programming as Theory Building [NAUR1992] where he summarizes his experiences with software systems development by arguing for a view that software systems development is something more than just production of a program and certain texts. He argues that successful software systems development is a question of having an appropriate understanding of both the referent and the software system. His arguments are based on personal experience and presented as two case studies. The first case study looks at making extensions to an existing compiler. The story concerns two software development teams, team A and team B. A has implemented a compiler for language L. Team B wants to implement the compiler for a language L+M, which is language L with minor modifications M. Team B strikes a deal with A, where A agrees to provide B with support in form of full documentation and personal advice. During the design phase, team B comes up with ways to add modifications to the existing compiler. These suggestions are submitted to team A for review. As it turns out, team A finds that in most cases team B does not make use of the existing framework when implementing their changes. This despite the fact that the facilities inherent in the original design are discussed at length in the documentation. Team B's suggestion are instead "based on additions to the structure in form of patches that effectively destroyed its power and simplicity" [NAUR1992](Naur 1992, p. 228).

His second case relates to the installations and fault diagnosis of a large real-time system. The people installing the system have been involved with its development over several years. During fault diagnosing they rely on their knowledge of the system and its annotated 200,000 lines of program text. They are unable to conceive how any kind of additional documentation could prove useful to them. Other programmers' groups are responsible for the operation and maintenance of particular installation of the system. These groups have to rely on written documentation of the system and guidance by the producer's staff. They "regularly encounter difficulties that upon consultation with the producer's installation and fault finding programmer are traced to an inadequate understanding of the existing documentation" [NAUR1992](Naur 1992, p. 229).

Naur's conclusion to both stories is that with certain kinds of large programs, the continued adaption, modification, and correction of errors depends on certain kinds of knowledge possessed by a group of programmers who are closely and continuously connected with the software system [NAUR1992](Naur 1992). For these systems the programmers' knowledge transcends that which is recorded in the documentation. Naur's argument is related to three issues: how, why and the application of how and why. A programmer possessing a theory of the program can explain how the software systems relates to the referent system. He is able to explain what real-life affairs the program is matched to. This involves everything from the software's overall characteristics, its architecture, to how its details are mapped into the program text and any additional documentation. The programmer is also able to justify why the program is the way it is. The justification is the programmers' direct, intuitive knowledge or estimate. It makes use of reasoning based on quantitative estimates, design rules, comparison with alternative.

Arguing for the third issue, the application of how and why, Naur says the programmer is able to constructively respond to demands of modifying the program. Based on the works of American psychologist Ryle, Naur calls this understanding a theory. In extension to this he argues that successfully developing software is a question of building this theory.

Writes Naur: "a person who has or possesses a theory … 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" [NAUR1992](1992, p. 229). The notion of theory was proposed by Ryle [RYLE1949](1949) in an effort to describe the difference between intellectual and intelligent behavior. Ryle claims that intelligent behavior is the ability to do certain things without having any concrete knowledge to build this behavior on. These are things we do without thinking about them, like talking grammatically correct, for instance. Intellectual behavior is, according to Ryle, a question of not only doing certain things intelligently, but also to explain and argue about the behavior. Behind intellectual behavior lies a theory. A theory is understood as the knowledge a person has to possess to act intellectually.

Intellectual behavior is not merely confined to the general and abstract part of 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 [KUHN1996](Kuhn 1996). It is the knowledge of knowledge, so to say.

Relating this theoretical framework to his first case study, Naur argues that team B did not possessed the theory behind the compiler. Hence their suggestions to incorporate modifications not based on the program's existing infrastructure. Team A possessed the theory behind the compiler, and were thereby able to classify team B's suggestions as patching up and befuddling the simplicity of the original design. Team B did not have the theory to constructively respond to demands of modifications. Team A did. The same conclusion applies to his second case study.

Assuming a software development model is a set of work rules for programmers, saying something about what to do, in what order, which notations and programming languages to use and what kinds of documents to produce, argues Naur, then the most important aspect of the method is that of ordering actions. But: "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. Rather, the person possessing a theory will be able to produce presentations of various sorts on the basis of it, in response to question and demands" [NAUR1992](Naur 1992, p. 236). Naur supports himself on the conclusions of more radical philosophers of science, that there is no such thing as a scientific method helpful to scientists [FEYERABEND1996](Feyerabend 1996). It is therefore a mistaken assumption, he argues, that software systems development should be based on scientific methods. "[T]he notion of methods as systems of rules that in an arbitrary context and mechanically will lead to good solutions is an illusion" [NAUR1992](Naur 1992, p. 237), Naur argues referring to software engineering.