1 Why study programming?

1.1 The paradox of “the software crisis”

The rationale for this book is to be found in a paradox in the scientific study of software and programming. This is the paradox between the view held within science on the current state of the art of software development, which tends to be rather dismal and pessimistic, and the obvious success and importance that software development enjoys in society. The dismal view is not new. Indeed, it seems to have been with us since the first days of programming research.

Carl H. Reynolds wrote in 1970 on the subject of computer programming management:

“A common complaint among those who are charged with the responsibility of planning and managing computer program systems is that despite their best efforts the product is completed behind schedule, over budget, and below promised performance.” 1

Frederick P. Brooks, Jr. echoed these feelings in his 1975 book The Mythical Man-Month, one of the most well-known and influential texts on software engineering:

“No scene from prehistory is quite so vivid as that of the mortal struggles of great beasts in the tar pits. ... Large-system programming has over the past decade been such a tar pit, and many great and powerful beasts have thrashed violently in it. Most have emerged with running systems – few have met goals, schedules, and budgets.” 2

Figure 1.1 – The tar pits of large-system programming. C.R. Knight: Mural of La Brea Tar Pits. The Natural History Museum of Los Angeles County. Source: Brooks 1975 [1995] p. 2.

Another influential book on software development, Peopleware, was written by Tom DeMarco and Timothy Lister in 1987. These authors generally have a more optimistic approach to the state of the art of software development; yet, they open their book with a chapter heading stating, “Somewhere today, a project is failing”. They explain:

“There are probably a dozen or more accounts receivable projects underway as you read these words. And somewhere today, one of them is failing. Imagine that! A project requiring no real innovation is going down the tubes. Accounts receivable is a wheel that’s been reinvented so often that many veteran developers could stumble through such projects with their eyes closed. Yet these efforts sometimes still manage to fail.” 3

A textbook on software engineering from 2000 simply starts its introduction with a list of “Software Engineering Failures”, under headings such as “Interface misuse”, “Late and over budget” and “Unnecessary complexity”.4 Søren Lauesen’s 2002 book about software requirements puts it bluntly:

“Most IT systems fail to meet expectations. They don’t meet business goals and don’t support users efficiently.” 5

According to Hans van Vliet, in a 2008 textbook on software engineering, the “software crisis” first became apparent in the 1960s. But it is not over yet, as we still need:

“Better methods and techniques for software development [that] may result in large financial savings, in more effective methods for software development, in systems that better fit user needs, in more reliable software systems, and thus in a more reliable environment in which those systems function.” 6

As we can see, the professions that study programming, and the software engineering profession in particular, do seem to take a negative view of software development, with a recurring chorus highlighting failure to meet schedule, budget, and user goals. This would be no cause for wonder if programming really were in a state of utter confusion and chaos. But how, then, do we account for the huge success of programming and computers more widely in society? After lamenting the current state of programming, van Vliet hints at the other side of the paradox:

“On the positive side, it is imperative to point to the enormous progress that has been made since the 1960s. Software is ubiquitous and scores of trustworthy systems have been built. These range from small spreadsheet applications to typesetting systems, banking systems, Web browsers and the Space Shuttle software.” 7

Numbers alone demonstrate the enormous progress that has been made. For example, we can look at the development in the U.S.A., which is by most accounts the world leader in computer development. According to the U.S. Department of Commerce, the computer systems design and related services industry increased in value from 5 billion dollars in 1977 to 184 billion dollars in 2010. This is an increase in share of GDP of 550%, and it means that the industry is now larger than the entire oil and gas industry.8

Our everyday experience chimes with the numbers in showing the success of computers and programming. Our lives are full of programmed devices, from the more obvious, such as mobile phones and personal computers, to the perhaps less conspicuous, such as washing machines, cars and airplanes. And these devices normally work satisfactorily. This, then, is the paradox of the software crisis: even though computers and programming have been so hugely successful and have become such an integral part of daily life, the scientific study of programming talks about it in dire, almost dystopian, terms.

Where might we find the cause of the paradox of the software crisis? I believe that it has its roots in overblown expectations to what the scientific study of programming can achieve. For example, when the IEEE Computer Society defines “Software Engineering” as “the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software” 9 it expresses the hope that an engineering approach to software will result in better, cheaper, and faster development. But this dream has so far been elusive.

Stating that science expects too much of the study of programming amounts to saying that science has an insufficient understanding of what programming really is. The obvious question then becomes: what kind of thinking should be employed in order to broaden the scientific understanding of programming? The answer offered here is cultural theory.

1  Reynolds 1970 p. 38.

2  Brooks 1975 [1995] chp. 1, p. 4.

3  DeMarco & Lister 1987 [1999] chp. 1, p. 3.

4  Bruegge & Dutoit 2000 [2010] chp. 1.1, p. 38.

5  Lauesen 2002 back cover.

6  van Vliet 2008 chp. 1, p. 5.

7  Ibid.

8  U.S. Department of Commerce 2011: GDP by Industry.

9  Institute of Electrical and Electronics Engineers (IEEE) Standard Glossary of Software Engineering Terminology 1990 p. 67.

1.2 Research approach

In a general sense, the research method I employ is the application of a new perspective to the study of a phenomenon that is inadequately understood. In this situation, the answer to a problem largely becomes an explanation of what the problem really constitutes. To the question “what is the best way of developing software?”, the answer must necessarily be that there is no “best” way of developing software. This answer is in itself of course not very helpful, and the value of the research thus lies in a qualification of the answer. In a similar way, the research question posed by this treatise, in common with much cultural research, is very open.

The aeronautics engineer Walter Vincenti, in his 1990 book What Engineers Know and How They Know It, provides an historical exposition of episodes in U.S. aeronautical engineering. Vincenti analyses how engineering knowledge is created and used, and points to the central role of the design process in engineering. His analysis shows the necessity of learning about the subjective, human element of a problem before everyday engineering and design tasks can commence. In engineering terms, it can be posed as the necessity of examining an ill-defined problem in order to identify needs and translate them into specifiable criteria.1 The needs and criteria cannot be specified beforehand: they must follow in the course of the research. This is the kind of research problem that is dealt with here.

The approach taken by this treatise is to apply general theories in order to understand the more specific phenomenon of programming. The most general theory employed is an Aristotelian theory of culture, mainly inspired by the Danish ethnologist Thomas Højrup.2

To examine more specifically the work practices of programming, I employ the theories of hermeneutics and rhetorics. Hermeneutics is a general theory of how understanding takes place, whereas rhetorics is a general theory of expression; that is, of utterances.3

It should be noted that hermeneutics and rhetorics are intimately connected; it is a central insight of both that doing and understanding are inseparable. Hermeneutics, then, looks at doing and understanding from the perspective of understanding, while rhetorics looks at the same thing from the perspective of doing.

This treatise answers the following questions:

The use of hermeneutics in the study of programming is a largely unexplored area. Hermeneutics has previously been applied to artificial intelligence, but without much insight or success.4

The concept of understanding has a close connection to hermeneutics. Jorge Aranda’s doctoral dissertation from 2010 applies the perspective of understanding to programming, in what Aranda calls “a theory of shared understanding”. According to this approach, software development is not a simple transfer of data but a gradual process of mutual understanding. The software team has to discover all relevant aspects of the problem it intends to solve, and this requires interpretation.5 Aranda emphasizes that shared understanding develops slowly from practice, that it is dependent on context, and that it takes effort and practice to gain knowledge of the context of understanding.6

Aranda’s conclusions are consistent with those that follow from a hermeneutical perspective on programming. The main difference between Aranda’s work and the approach taken in this treatise is that Aranda bases his theory on cognitive psychology rather than hermeneutics. In cognitive psychology, understanding consists of internal mental models,7 whereas hermeneutical theory views understanding as an existential question of what truth is.8

1  Vincenti 1990 [1993] p. 51.

2 See Section 6.1 (Cultural theory: practice and form).

3 Classically, hermeneutics and rhetorics were confined to the more narrow phenomena of text and speech, but I use them in their modern versions, in which the theories are formulated so as to apply generally to any cultural phenomenon. In this I follow the philosophical hermeneutics of Hans-Georg Gadamer, and the “new rhetorics” of Chaïm Perelman and Lucie Olbrechts-Tyteca. For hermeneutics, see Chapter 9 (Understanding); for rhetorics, see Chapter 7 (Writing programs).

4  Mallery et al. 1987: “Hermeneutics: From Textual Explication to Computer Understanding?” Massachusetts Institute of Technology Artificial Intelligence Laboratory.

5  Aranda 2010 p. 3, p. 89.

6  Ibid. p. 111, p. 95.

7  Ibid. p. 42 f.

8 See sections 9.4 (The concept of understanding) and 9.9 (Ethical and technical knowledge).

1.3 The cultural aspects of programming

It is common to distinguish between culture and nature, or between human factors and physical factors, and it is even common to view them as being in opposition. While the distinction is useful, the notion of opposition is not congruent with how technological development actually takes place.1 Human activity always has a cultural as well as a natural, or physical, side: in this regard, culture and nature are different aspects of the same activity. The relationship between the two is an important concept at the base of cultural theory of technology.

Cultural studies often deal with subjects that are difficult to define in an exact manner, and where the relevant research questions are not all clear. This diffuseness can be unsettling to researchers with a background in technology and the natural sciences. However, with the right application of cultural theory it is possible to tackle diffuse and hard-to-define cultural questions in a systematic and exact manner.2

Applying cultural theory to the study of programming is like applying mathematical theory to a problem in electrical engineering. This is fruitful because mathematical theory is well suited to describe relationships between quantities, and those quantities can be defined and measured in terms of electrical circuits. When it comes to the study of why people do what they do – that is, the study of culture – there are rarely any measurable quantities or fixed relationships that can be described with something like a mathematical theory. Cultural theory, therefore, is concerned not with things that are certain but with things that are uncertain: how meaning arises, and the relationships between people. Just as mathematical theory is an abstract way of describing necessary relationships, and is useful for understanding quantities, so cultural theory is an abstract way of describing how meaning is made, and is useful for understanding human activity.

Cultural approaches to programming are not unheard of, though they are a rarity within academia. Outside academia, the popular blogger Joel Spolsky, for example, has described the difference between Windows programming and UNIX programming as a difference between two programming cultures.3

Spolsky argues that UNIX programming evolved in a time and environment where most people who used computers were programmers, and very few were users without programming knowledge. Consequently, the UNIX programming culture assumes that a user is also a programmer and knows how to modify the program to his liking. In contrast, the Windows programming culture developed among programmers who were making programs for users who are not programmers themselves. Therefore a typical Windows program is easier to use for a non-programmer, but a programmer will find it harder to modify for his own purposes.

Besides computer science, the academic background for this treatise is ethnology, which has a long tradition of work studies. Ethnological research from the late 1970s and early 1980s focused on work practices in their societal context. An example is Billy Ehn’s study of factory workers in Stockholm in 1977-8, which includes detailed descriptions of work practices and their influence on the workers’ existence. Another example is Gudrun Gormsen’s study of the diary of a Danish heath farmer from 1829 to 1857.

The research presented in this treatise can be said to fall within an older tradition of classical ethnology that has work practices as its primary focus. Examples of this kind of research are Ole Højrup’s 1967 book Landbokvinden (“The Rural Dwelling Woman”) and U.T. Sirelius’s classic work on Finnish fishing from 1906–8. The aims and the methodological challenges of this older research are different from those of this treatise, but the underlying ethnological perspective is essentially the same.

1 See Latour 1987 chp. 2.c, p. 94 ff.

2 Take, for example, the work of the Danish ethnologist Lone Rahbek Christensen, who has written about the arguably diffuse question of what it means to live life as a woman. Rahbek Christensen shows that the subject can be approached in a clear, systematic, and logical way. See Christensen 1987.

3  Spolsky 2004 chp. 18.

1.4 What is left out

This treatise studies programming as work. There are of course other reasons to program: for example as a hobby, as art, for the sake of education, or for fun. Though these reasons may be important, we will not consider them here.

Furthermore, only professional programmers are studied here. This excludes professionals in other areas that are programming as a part of their work, but whose programs are primarily used by themselves. Professional programmers are thus considered to be those programmers whose programs are not meant to be used by themselves: that is, their task is given by another party, directly or indirectly.

There are a number of aspects of programming that will only be considered tangentially, even though they would be interesting to study in their own right: what kind of people programmers are, and how they live their lives;1 the management of programming, the economic and business aspects of programming; and the programmers’ identification with their job. These aspects of programming will be considered, but they will be subordinate to the central theme of work.

Sherry Turkle has written about how people imbue technology with meaning. She writes:

“When people repair their bicycles, radios, or cars, they are doing more than saving money. They are surrounding themselves with things they have put together, things they have made transparent to themselves.” 2

Turkle shows that this is as true of computers as it is of bicycles and radios. She also examines programming styles in different situations and identifies three types of programmers: “hard style” programmers are objective and abstract; “soft style” programmers are artistic and immediate; and “hacker style” programmers are primarily concerned with “winning”, and keep themselves apart from non-programmers. We will not be using these categories in this treatise but they illustrate one way in which research can take an approach to programming that is not focused on work.

It is not my aim to quantify or study what is typical within programming. I have aimed for a certain amount of cultural variation in the few situations I have chosen to study, but have not attempted to cover the range of possibilities in a systematic way. Every cultural situation is unique in the sense that what happens depends on the free will of the persons involved. This means that it is not possible to make general rules that can say with certainty what people will do in a given situation – not even probabilistic rules are very useful. In other words, cultural studies are historical studies, even if they are only concerned with the present.

Since the validity of cultural research cannot be decided by numbers, the task becomes essentially one of argumentation. I will argue that the proposed cultural explanation offered by this treatise is consistent with the data, that it makes sense, and ultimately that it has something interesting to say about programming.

1 In ethnology this is sometimes referred to as life modes. See Christensen 1987.

2  Turkle 1984 [2005] p. 176.

1.5 Definition of programming

The word program, or programme, comes from the Classical Greek prógramma (πρόγραμμα), which means “a public proclamation”. It is derived from the verb grápho (γράφω), which means “write”, and the prefix pró-, which means “before”, also in the sense of “forth” or “publicly”. Thus, prográpho can mean either “write something before”, at the head of a list, for example; or it can mean “give a public announcement”.1

In the ordinary use of the word, a program is a sequence of steps carried out in order to achieve some purpose. An example is a program for an evening concert, where different musical pieces are performed by the musicians over the course of the evening. Another example is a training program meant to increase prowess in some sports disciplines, by specifying exercises. These are both examples of programs that are meant to be carried out by people. Programs can also be carried out by machines, if the machine is designed to be able to execute sequences of steps. We speak then of automation.2 An example is the Jacquard attachment to the drawloom, which was developed during the period from 1725 to 1801.3 Via a collection of punched cards, the machine could be programmed to produce a given woven pattern when the loom was operated; and the punched cards could be dismounted and saved for later, if the weaver wished to reuse a certain pattern (see Figure 1.2).

Figure 1.2 – A drawloom with Jacquard attachment. The punched cards are visible at the top. Source: Glazier 1923, reproduced in Wilson 1979 p. 64.

It is not always possible to distinguish clearly between the use of a machine and the programming of said machine. In the case of the drawloom, before the introduction of the Jacquard attachment a so-called drawboy would perform the instructions contained on the punched cards. The drawboy would then in effect be executing the pattern program by operating the loom. The degree of automation before the Jacquard attachment was of course lower, but even with the Jacquard attachment the drawloom was not fully automated. Thus, automation and programmability is a matter of degree rather than a question of either/or.

This treatise is concerned with a certain type of machine – namely, computing machines. In computers, the possibilities of computation and those of automation are combined in a way that makes the use of computers very flexible. It is of course possible to have computing devices that are not automatons. The abacus and the slide rule are examples of this. On the other hand, the Jacquard loom is an example of an automaton that does not perform any computing.

In a computer the aspects of computation and automation enhance each other, although practical uses of computers will often be inclined more towards one or the other aspect. A spreadsheet application, for example, can be said to be a use of computers that is dominated by the computational aspect, while a microcontroller for a car brake can be said to be dominated by the automation aspect.

With these remarks on the meaning of the term “programming”, we can define the concept in the sense that it will be used in this treatise:

Programming is the act of instructing computing machines.

The term “coding” is often used to refer to the specific part of programming that is the writing down of the instructions, and we use the word in this sense here. The term “software development” can be used to refer to programming as well as a wider range of activities that are necessary to programming, for example, sales. We use the term in this sense here, to denote programming and the necessary supporting activities.

1  Liddell, Scott, and Jones’s lexicon.

2 See Latour 1987 p. 130 f. for a discussion of the concept of an automaton.

3  Wilson 1979 [1982] p. 62 f.