We would like to argue that technology affords not one but multiple ways of revealing being, and that the way we create technical artifacts - and software most importantly - heavily influences the cultural role they will play. Tools are not neutral; they integrate and propagate human values (Friedman, 1997). But these values are not necessarily those of technocratic reasoning as Heidegger would have it, the whole gamut of human apprehension is possible. Software brings technology closer to us than ever before and it is time to look at the practices that spawn what has become an important part of the constitutional fabric of our cultures.
Since the advent of modern computing in the late forties and especially the marketing of the consumer PC in the eighties, computers have come to be ubiquitous. But while the terms “computer” and “technology” have almost become synonymous and the basic technical principles have remained the same for the last sixty years, there remains an aura of vagueness around these machines. Herein actually lays their power. Computers themselves are functionally underdetermined; they need software to turn them into complete devices with distinct functions. While the hardware, the Universal Machine, coupled with peripherals like input/output devices, networks, etc., is the necessary mechanical base layer, the “specific” machine - a series of functions and procedures that manipulate information and, with proper connection, matter and energy - is the result of programming. Alan Turing stated that,
The importance of the universal machine is clear. We do not need to have an infinity of different machines in doing different jobs. A single one will suffice. The engineering problem of producing various machines for various jobs is replaced by the office work of ‘programming’ the universal machine to do these jobs. (1984, 4)
These words mark the technical novelty and yet another reason for the cultural significance of IT: somebody who buys a computer today gets not only the physical apparatus, but also gains access to a seemingly infinite world of logical machinery. These software programs spring from a burgeoning environment where work styles nowadays go well beyond the classical methods of engineering or even beyond the “office work” mentioned by Turing. Before we can get a closer look at these practices, we must first review some of the qualities of software.
While there has been a continuous reflection of what software actually is, this problem is still far from being completely understood. Despite the stability of the mathematical foundations of software since Turing, Church, and Shannon, the final jury on what we can really do with it is still out. As society changes, software changes and every day there are new applications that surface around the globe. It is possible, however, to specify some of the basic properties of logical machinery.
Unlike other technological objects, software is immaterial. It is similar to language with respect to structure and similar to technology with respect to effect. Written as
a text, it functions like a machine. Latour (1992) pointedly observes, paraphrasing Austin, that “how to do things with words and then turn words into things is now clear to any programmer.” The classical distinction made in engineering between designing, i.e., drawing the blueprints, and building, i.e., assembling the physical structure, does therefore not translate well into software programming. According to Jack W. Reeves (1992) writing the source code can be compared to designing but building is nothing but the automatic translation of source code into machine language by a compiler program. In contrast to classic (hardware) engineering, software is thus expensive to design - it takes a lot of time to write a functional piece of software- but cheap to build. From an economic perspective, we can even speak of an apparatus of production unlike other areas of technology, specific to the creation of software: except for the price of a computer, producing software is basically free, time becoming the essential cost factor. In this sense, software is again closer to literature or music than to industrial production - the workstation is the factory floor. This greatly facilitates people shifting from consumers to producers.
Like knowledge and information, software can be shared without tangible loss for the giver. The Internet transports and copies computer code as simply as text, sound, or images; algorithms, program libraries, and modules pile up at different sites, contributing to what could be seen as the equivalent of a fully equipped workshop with an unlimited spare parts inventory attached to it, accessible again at the cost only of time and skill. A general-purpose programming language like Java nowadays comes with thousands of ready-made building blocks and writing code is often closer to playing Lego than to the laborious task of manipulating memory registers it used to be.
Unlike the products of industry, a computer program is always tentative, never really finished or “closed”. Classic machinery also has to be tended, calibrated, and repaired, but with software the provisional aspect is pushed to the extreme. One mouse click and an entire subsystem can be copied to another program and the output of one piece of software can instantly become the input of another. We do not want to encourage in any way the view that holds that everything digital is fluid, chaotic, and auto-organized, but there remains the fact that this freedom from most physical constraints renders software easier to manipulate and handle than hardware objects. The only constraining factors are time and skill. This relative freedom is one reason for the production of software in practice being so unlike engineering by the book.
According to IEEE Standard 610.12, software engineering is “the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software.”77 The attempt to translate the strategies and methods of classic engineering into the area of software has never been entirely successful and has been criticized from several directions. We cannot possibly summarize all the different views expressed in this complex and long-standing debate, but there are several main critical positions that can be distinguished.
One argument holds simply that programming is based less on method than on skill, that it is craftsmanship rather than engineering, and that “in spite of the rise of Microsoft and other giant producers, software remains in a large part a craft industry” (Dyson, 1998). The main question for design, then, is not how to find the proper methods but how to acquire the appropriate skills.
Another argument is that software engineering has its place but that specific methods and strategies cannot be directly imported from traditional engineering, because building software is very different from building bridges and houses (Reeves, 1992). Debugging for example should not be treated as a hassle to be eliminated by using mathematical rigor, but as an essential part of creating computer programs.
Finally there are those who believe that software engineers should be supplemented by other professions, in particular by software designers who take inspiration from architects rather than engineers because buildings and software “stand with a foot in two worlds - the world of technology and the world of people and human purposes” (Kapor, 1996). In this view, building a computer program is not so much about technical problems, but about how to bring users and tools together in a meaningful way.