|The User-Developer Convergence: Innovation and Software Systems Development in the Apache Project|
The previous chapter's look at software systems development is from a prescriptive point of view. Both software engineering and participatory design aim at saying something about how software systems development is supposed to be conducted. Software engineering's approach is to apply natural scientific methods to the effort. This objectivist approach aims at reducing the development effort into a series of phases continually transforming work products, and finally ending up with a running software system. With little or no concern about the software system's context, software engineering's main concern can be argued as building the software right. Participatory design views software systems in context of use. To participatory design software plays a role in the working place, and is to be considered a tool to improve employees' working conditions. The view is based in both pragmatics of improving an organization's productivity and working life politics.
Similar to both software engineering and participatory design is that they proscribe an approach to software systems development based on external factors. Both approaches are rooted in more traditional industrial understanding of work and production. Software engineering looks at developing software as any other semi-automated production, as if developing software is analogous to any other factory production [CUSUMANO1989](Cusumano 1989) [AAEN1997](Aaen et al., 1997). Participatory design does not even deal with how best to develop software, but sees the running software system merely as a means to an end.
Human and social sciences has concerned themselves with knowledge and understanding for a long time. Lately a shift of focus has come about within computer sciences, building upon the knowledge research within fields such as anthropology [ORR1996](Orr 1996), psychology [NAUR1992](Naur 1992), philosophy [EHN1988][EHN1992](Ehn 1988, 1992) and the philosophy of science [FLOYD1987](Floyd 1987). Instead of looking at software systems development in light of production, the shift of view has been to look at software systems development as an intellectual activity dealing with knowledge and learning. In this chapter I will try to underpin the appropriateness of such a view. The field of knowledge and learning is too broad to fit the scope of this thesis. Instead of an exhaustive treatise on the field, I will therefore limit my topics to those directly applicable in understanding certain aspects of the Apache group's approach to software systems development.
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.
Naur's perspective on software systems development is that of the individual developer. This is somewhat different to both software engineering and participatory design. Software engineering looks at the development effort with what is to be done when and by whom in mind—a bit crudely put, it could be said that software engineering is concerned with building the system right. Participatory design looks for ways to develop the right system, looking at how the software interacts in a larger social context. Naur does not concern himself with how software is to fit into the larger social context, but neither does he offer any advice on how developers best can build a theory of the software system being developed. His critique of software engineering as an illusion, and the claim that scientific methods are not much help to neither scientist nor software systems developer, makes Naur a representative of Hirscheim and Klein's subjectivist position.
While not the first to question the appropriateness of an approach to software systems development based on scientific methods, Naur is among the first to make the connection between software systems development and knowledge research. His contribution is significant in that it provides argumentation for viewing software systems development as a knowledge intensive activity. While implicit in some of the approaches described in the previous chapter, Naur is explicit on the fact the knowledge and understanding is the key factors in software systems development. He argues why it is so, but provides no practical clues as to how this would be reflected in an approach to software systems development.