Notes for Adrian Mackenzie Cutting Code: Software and Sociality

Key concepts: art-like situations, between-place, bitrot, blip, circulation, code, cognitive stickiness, convolution, covering over, fieldwork in philosophy, involutions of agency, lifted-out spaces, multi-sited ethnography, neighborhood, pastiche, sociality, software, software repressive hypothesis, technological unconscious, Unix philosophy, variable ontology, virtualization.


Related theorists: Arjun Appadurai, Pierre Bourdieu, Geoffrey Bowker, Judith Butler, Martin Campbell-Kelly, Wendy Chun, Gilles Deleuze, Michel Foucault, Mathew Fuller, Clifford Geertz, Alfred Gell, Donna Haraway, Bruce Janz, jodi, Friedrich Kittler, Scott Lash, Bruno Latour, Benjamin Lee, Lawrence Lessig, Edward LiPuma, Alex McLean, George Marcus, Paul Rabinow, Eric Raymond, Rob Shields, Susan Leigh Star, Bruce Sterling, Lucy Suchman, Nigel Thift, Trigg.

Acknowledgments
(i) This book came out of the years between the mid 1990s and 2002. Code and software grabbed hold of me as a philosopher-turned-programmer. Working in academic and commercial settings, the properties of code as a material-form became very palpable.


Chapter 1
Introduction: Softwarily

(1-2) This book explores software as a social object and process. . . . The main reason, however, is that software embodies a mixture of mutability, contingency and necessity symptomatic of recent time.

Hard to represent materiality and sociality of software.

(2) Software's fringe existence seems to corroborate the commonsense notion that it is “intangible” rather than physical, that it is something more like a social convention or rule than machine-thing. The characteristics of software as a material object, as a means of production, as a human-technical hybrid, as medium of communication, as terrain of political-economic contestation—in short as socialityseem hard to represent.

Code:Transforming symbolic forms
(3) One way to resist an abstracting turn away from software is to attend to its code-like character. Attending to code as practice and material thing might show how software becomes invisible, how its occlusion from analysis occurs and how it nonetheless becomes at times very visible and significant.

Software as neighborhood rather than intangible formalism.

(3) Following the movements of code shows that many objects, practices, environments and behaviors are becoming more software-like. Software itself, however, looks increasingly like a neighborhood rather than an intangible, abstract formalism.
(4) Despite appearing “merely” technical, technical knowledge-practices overlap and enmesh with imaginings of sociality, individual identity, community, collectivity, organization and enterprise. Technical practices of programming interlace with cultural practices.

Software as relation, operation or ontology

Code as cultural object.

(5) While theoretical computer science sometimes treats software as a quasi-mathematical-logical entity susceptible to complete formalization, code itself inevitably slips into tangles of competing idioms, practices, techniques and patterns of circulation. . . . Code can be read as permeated by all the forms of contestation, feeling, identification, intensity, contextualizations and decontextualizations, signification, power relations, imaginings and embodiments that comprise any cultural object.
(5) Whereas a computational ontology is meant to provide a way of designing and organizing the operations and processes a computation will perform, my ontology of software has other, more contested ends in mind. Instead of introducing a consistent model of a complicated set of relations, it seeks to make inconsistency and lability conceivable.

Ontology as resistance to abstraction
(5) The purpose of this new ontology might be, as the anthropologist Paul
Rabinow recently suggested, to provide ways of responding to “a world experienced as contingent, malleable, and open” (Raginow 2003, 67); that is, an ontology is a conceptual ensemble designed to make sense of empirically felt variations in experience.
(6) What software does is very intimately linked with how code is read and by whom or what that is, by person or machine. Sociologists and anthropologists of technology have established that any formalization needs to be understood “in-use.”

Defamiliarizing software-like situations
(7) First, the ontology should register some of the mutability and contingencies associated with software rather than reducing them to stable forms. Second, the attraction of formality has to be accounted for through the specificities of code as a material articulated, felt, shaped and changed in practices, whether located in communication, entertainment, commerce, government, production or science.

Alfred Gell art-like situations, involutions of agency applied to code; anthropological theory of art as index of agency.

(7) In art-like situations, a visible, physical, material thing triggers a “cognitive operation” that attributes agency to something. Art-like situations are differentiated by social relations obtaining in their neighborhood. Concretely, these relations exist as actions they authorize and perform. With respect to software, the analogous question would be: What makes something a “code-like” situation?
(8) Art, as [Alfred]
Gell argues, is an involution of agency that forms part of any cultural environment. If software matters, and if power, law and art are associated with software, then code as a material has become a significant way of distributing agency.

Attributing actions
(8) The possibility of attaching agency to software is essential.
(9) Contrary to the idea that software obscures these agential transactions, code renders some of them very vividly.
(9) Today, the distribution of software throughout the interstices of urban life and its growth in new forms of media and communication such as the web cannot be understood in terms of older “big-iron” (Raymond 1996, 64) models of technology.

Agency distributed in kaleidoscopic permutations.

(10) We recognize other people as agents (to a lesser or greater extent) because they have the capacity to act. But in milieus populated with bodies, things, systems, conventions and signs (and this is virtually everywhere), agency distributes itself between people or between people and things in kaleidoscopic permutations.

From formalism to a neighborhood of relations
(11) Is there not more specificity to the agency of software? From the perspective of an ontology of software modeled on Gell's anthropological theory of art as index of agency, at least four different entities stand in relation in software: code, originators, recipients and prototypes.

1. Code as index
(11-12) Gell's anthropological theory of art focuses on how indexical signs or “the index” found in art-like situations permit “abductions of agency,” that is, nonlinguistic inferences of social agency. To understand the adhesiveness of code, the rules comprising any body of code can be treated as indexical, as a “natural sign from which the observer can make a causal inference of some kind” (Gell 1998, 13).

Bitrot.

(12) Like anything else, software does not grow or exist in isolation. Left alone, it tends to fall apart because all around it hardware platforms and other software change. Software, despite its algebraic-ideal image, needs carefully maintained niches. . . . The constant arrival of new versions, updates and patches both conceals and highlights the brittleness of software.
(12) As later chapters will show, software participates in a more general invisibility of technical infrastructures and enters into a certain historically specific “technological unconscious” (Thrift 2004b).
(13) However, for every controversial or well-publicized event concerning software, so much more was taking place less visibly and introducing algorithmic processes into the infrastructural backgrounds of movement, perception and memory. . . . Computing hardware has not been subject to anything like the scholarly interest that it merits. Its production is largely hidden in chip fabrication plants in Southeast Asia, and semiconductor design is hard to study ethnographically.

2. Originators
(14) Software also refers to its producers. Someone or something codes it; there is an
originator. . . . The incurable ambiguity of the term “hacker” in popular representations of software as both criminal and creative attests to conflicting ideas of what making software entails.
(14) The producers of a given contemporary technology are regarded as part of an engineering, corporate or research elite whose activities like outside the domain of popular culture or everyday life. While this divide between elite and popular cultures may exist for some kinds of production, it does not accurately describe the production of software.

3. Recipients
(15) Although reading and writing are key practices attached to code, and although the “readability” of code has consistently concerned programmers since the 1950s, what is at stake in reading and writing code is not “meaning” in any commonly accepted sense. Rather, the readability of code relates to execution, to how it circulates, how quickly it can be read and understood by other programmers, and how it affords revisions, modulations and modifications.

4. Prototypes
(16) Finally, software sometimes resembles or represents something else, a prototype. . . . The prototype may reflect highly fictive imagining, as in software for artificial life (Kember 2003; Helmreich 2000), or it may represent something as prosaic as a desktop.

Permutations of agency
(17-18) As symbolic forms coalesce in massively networked code formations, the agential relations in software become highly involuted and recursive.

Involutions of agency: Force, value and feeling in software
(18-19) This book treats software as a multi-sited associative or concatenated entity. The anthropologist George
Marcus (1995) describes multi-sited ethnography and research as “designed around chain, path, threads, conjunctions or juxtapositions of locations in which the ethnographer establishes some form of literal, physical presence, with an explicit, posited logic of association or connection among sites that in fact defines the argument of the ethnography” (105). . . . Substitutions, translations, attributions and displacements of agency in and through code constitute a nexus out of which software comes. Significant differences in agency arise from the involutions and distributions of relations in code.

Code structured as distribution of agency; compare material specificity of sociological approach to David Sterne ensoniment. Linux and personal floss exemplify this autochthonous operation. Working code fits distributed nexus human machine material specific involutions of agency.

(19) This account diverges from a general sociology of technology in highlighting the historical, material specificity of code as a labile, shifting nexus of relations, forms and practices. It regards software formally as a set of permutable distributions of agency between people, machines and contemporary symbolic environments carried as code. Code itself is structured as a distribution of agency.
(19) By understanding code-like situations as involutions of agency, it becomes possible to situate these debates in relation to other questions of power, identity and democracy.


Chapter 2
Opening code: Expression and execution in software

(21) During the 1990s, making the code in software visible or “open” became a significant and diversely manifest project taken up by artists, hackers, corporations, government and non-government organizations.
(21-22) Even if code can be made visible or legible, how could baring the code predicate an “alternative kind of biopolitical production,” as Berry suggests above, in reference to Foucault's account of contemporary formations of power?
(22) For now, the virtue of using code-based artworks as a way into software cultures is that they simplify the problem of analyzing software in some respects.

Code as law, art, life focus of Ars Electronic festival.

(22) Even as they narrow the field of analysis, software artworks make instabilities and slippages in agency associated with code more obvious. They slow the slippages down enough so that they can be situated in relation to other norms, forms and conventions associated with law, power, communication and language. When the 2003 Ars Electronic Festival for Art, Technology and Culture held in Linz, Austria, for instance, adopted the theme “Code, the language of our time. Code = Law Code = Art Code = Life” (Stocker and Schopf 2003), the three equations between code and law, code and art, and code and life designated fields within which code has become a problem, something to be contested as well as taken for granted.

The uneven visibility of code
(23) In comparison to the high profile aspects of cyberculture (virtual reality, artificial intelligence, the web, gaming, online communities), code objects have had uneven visibility and significance.
(23) There are many aspects to this increasing invisibility of the interface to code objects, and their opacity has not itself been well analyzed.

Code and ordinary language
(24) Amplifying
Kittler's take on code would mean tracing, on a smaller scale, what kinds of “ordinary language” articulations are being eroded.
(24) The surfaces on which code is inscribed are heavily technologically sedimented and layered.
(24-25) The spawning, mutating and cloning of different idioms of code, and indeed of different versions of similar software applications or “solutions” generates code babble.

Code part of Thrift technological unconscious.

(25) The inaccessibility is also temporal, as the duration between reading and executing code falls beneath the threshold of perception (that is, millions of instructions per second). . . . Code is so ubiquitous that it should be an important material for cultural practices and representation, but it is relatively invisible, backgrounded and forming part of what Thrift (2004b) terms a “technological unconscious,” an “atomic structure” that produces forms of positionings and juxtapositions.

Making code readable
(26) Like canvas and paint, code as material becomes visible as a problem, as something whose visibility or readability is questionable from different angles, including those of “law” and “life.”
(27) From most standpoints, Perl poetry is kitsch art, the computing equivalent of dabbling in paint-by-numbers. It does, however, touch on two issues around reading and writing code: whether code is a craft, and just how much creativity is involved in it.
(27) Reading and writing code are governed here by norms and notions of agency derived from literary art forms.

Who is allowed to read and write code?
(28) Legal constraints on the visibility of code it at the center of some significant legal events.
(29) Code meant to be read by machines is made readable, in principle, to a literate public. The [DVD decryption] poem and the t-shirts are two of the many “artworks” arguing that code should be protected under freedom of speech.

Code as execution
(30) The question of whether code is speech (and therefore art) or merely a technology has not been tested in higher courts.
(30) Most of the responses supporting the defendant in the deCSS case maintain that code is on a continuum with “human language,” even if not exactly “ordinary language,” even if only a “small number” of skilled people will understand the machine-level formulations of it. The question of code's functional aspects, the effects or events associated with execution, remained unaddressed.

Code is law
(31) For [Lawrence]
Lessig, software was no longer another object of regulation, but itself a form of regulation or law. . . . rather than being regulated by government legislation or international agreements designed to protect intellectual property, code itself is law, it is an authoritative norm.
(32) In almost outright contradiction to the eminent amicus curiae brief, Lessig's argument framed code as something that possessed authority.

The authority of code: Executing software art

Compare to arguments from codework to working code.

(32) “Acknowledging execution” is the critical difference between code poetry and software art.

How does software run?
(34) Cultural theory has argued that the authority of any utterance depends on how it invokes and repeats a prior set of conventions (Butler 1997, 51; Derrida 1982).

Transgressive Perl fork program.

(34) The artist Alex McLean suggests that forkbomb.pl be seen as producing a “watermark” of the functional coupling of an operating system and hardware platform. Every operating system and platform will produce a different output. Even the same computer will produce different outputs depending on what other processes are running at that time (Cox, McLean and Ward 2002).
(35) In effect,
forkbomb.pl relies on the presence of a “fork” operation within the programming language Perl (not all programming languages have such a construct).

Fork: The interpenetrating contexts of code

Operating systems quintessential lifted-out spaces that entail nexus of norms and authority.

(36) If, as sociologist Scott Lash points out, operating systems are one of the most important lifted-out” spaces within contemporary technological cultures (Lash 2002), forkbomb.pl can only be transgressive within a system of norms already practically understood as a form of regulation. The question here is: What nexus of norms and authority does something like an operating system entail today?
(36) Here the transgression concerns not so much a state-supported legal system to regulate the reproduction of digital media but rather the operating system as a privileged technological site regulating conduct within contemporary technological culture.
(37) Software and struggles over how it is intentionalized are rooted in the impossibility of reading and writing code at the same time.

Code is life
(37-38)
Jodi's work illustrates the third equation from the there of Ars Electronica 2003, “Code = Life.” If previous artworks treat code as speech (deCSS haiku) and code as law (forkbomb.pl), jodi's work turns to the relation between code and interface. . . . More importantly, however, linking code to life might involve exploration of how communicative processes are invented, produced, regulated and controlled through power relations present in code. This would mean understanding how “users” are objects governed within regimes or biopower (Terranova 2004; Lunenfeld 2005).
(38) Rather than performing any kind of innovation involving code, this work can be regarded as a creative misuse of code. . . . These works challenge the framing of code through interfaces that intentionalize code in the name of a user.
(38) What counts as a fault or error is related to norms, to existing functions of software, and to the social and technical agencies software is meant to perform.

Code moves inside and outside the computer
(39) Just as Rauschenberg and other twentieth-century artists addressed the framing and support of the image in order to render visible hitherto unseen historical conditions of visuality, jodi's work with code can be read as seeking to make visible some hidden conditions of computability.

Lives crossing into code
(41) Mathew
Fuller (2003) proposed the notion of “blips” as a label for the dense relationality of certain events associated with software.


Chapter 3
Algorithms: Sequence and convolution

(43) Sometimes, algorithms, which specify how to transform a given set of inputs into a desired output, are treated as the formal, static essence of software.
(44) An algorithm naturalizes who does what to whom by subsuming existing patterns and orderings of cognition, communication and movement.
(44-45) Algorithms bring a different level of contestation of agency into software by virtue of what Alfred Gell describes as “
cognitive stickiness.” . . . An “agential” effect results from the impossibility of freezing perception: intricacy invites the attribution of agency.
(45) This chapter tracks how algorithms materialize in a specific domain, bioinformatics, a contemporary knowledge enterprise intensely preoccupied with sequence, position and repetition.
(45) Attachment or stickiness occurs through involution of agency, through a sometimes labyrinthine entwining of movements and spaces addressed and condensed in algorithms.

Moving sequences in bioinformatics
(46) Although bioinformatics may contain nothing new from the standpoint of software, its conception of life as prototypically algorithmic renders it uniquely apposite as an unexpectedly literal way to explore how knowledges and practices of sequence and position become convoluted in software.
(47) The name “bioinformatics” illustrated the strategic situation emerging as what we call the body lost some of its corpuscular, organismic character and became a nexus of different political, medical, economic and scientific actualities that provisionally congealed as biotechnology.
(48) The software manipulation of sequence data opens living systems to subsequent determiantion, whether as commodities in a biological knowledge economy, as elements in some other assemblage (such as a patented biomedical diagnostic reagent), or as elements in a transformed biological process (such as a genetically modified organism, plant or animal). . . . These processes can be seen as typical of how code textures worlds more generally. Hence, bioinformatics is treated here as symptomatic of the “soft control” (Terranova 2004, 114), “flow-worlds” (Knorr-Cetina and Bruegger 2000, 141) or “processual contexts” (Thrift 2004a, 590) crystallizing in and through software.

Bioinformatic problems and attachments
(50) Unlike other domains of the social field in which fine-grained schemas of addressability (Thrift 2004a) have entwined with everyday life over the last few centuries, sequence data is unformatted. Other labeling information must be attached. Pure sequence data will not be stored in the database. Rather, databases store sequence data in standard annotated formats.

The time frames of an algorithm
(51) Algorithmic time is framed by the computational resources supplied from the biological knowledge economy, and in this respect, algorithmic time is social and machine time.
(53) Bioinformatics, when it works on comparing sequences, cuts across genealogical descent and historical unidirectionality, albeit at the cost of restricting its focus to biological fragment such as proteins, enzymes and genes.

Imagined movements and alignments
(55) Analogous to physics' principle of conservation of energy, bioinformatics holds as a founding axiom that optimum alignment expresses similarity or kinship between biochemical entities.

Abstract movement in algorithmic time: “Build an appropriate Manhattan”
(55) The Needleman-Wunsch algorithm, dating from the 1970s (Needleman and Wunsch 1970), provided an early and critical intervention in the sequence alignment problem.
(56) Rather, the quite small repertoire of algorithmic design techniques used in contemporary software—dynamic programming, exhaustive search, divide and conquer, graph-based approaches, heuristic techniques, genetic algorithms, probabilistic algorithms—contains different forms of movement that can be propagated or concatenated across different domains. The transformations in computational time wrought by dynamic programming proceed via a process of abstraction that needs to be explained rather than simply attributed to software.

History as directed traversal of information
(57) Coding is an abstraction that spatiotemporally reorders existing movements. Well-known code constructs such as loops, conditional tests and data structures (arrays, queues, stacks, dictionaries) in popular programming languages afford this concentration or intensification of movements.
(58) Sequence comparison cuts short many other kinds of biological research. Stories of how years of research have been cut down to weeks abound in the bioinformatics literatures.
(59) Bioinformatics suspends recourse to living bodies in laboratory systems, instead searching in the sequence databases for similar contexts.
(59) Moving sequences into alignment with other sequences seems relatively formal and abstract in comparison to working with live cultures. However, every sequence alignment algorithm incorporates a history of prior alignments. . . . Sequence comparison seems easy because this work has been subsumed into the algorithm.

Algorithm and enterprise
(59) By annotating, cross-linking and reformatting biological information sources so that connections between them become accessible on the space of a single computer screen, bioinformatics potentiates living bodies as knowable and transformable.
(60) Enterprise-wide systems figure heavily in the “new” mode of “discovery science” following in the wake of large-scale gene- and protein-sequencing projects. . . . The names of such software—ISYS (integrated system), Ensembl, Apollo, GeneOntology, DiscoveryCenter, BioNavigator, SRS (sequence retrieval system)--highlight contemporary imaginings of fly-through, in-the-round, drill-down, scaled-up biological-knowledge synthesis.
(61) Significantly, the project of building enterprise-wide systems now transpires as a new mode of doing science or producing knowledge. [Donna]
Haraway's (1997) phrase “Nature enterprised up” emphasizes the inseparability of business and biological problems.
(61) Discovery science strains to encompass an increasingly fine-grained technical plying of living processes (“corporealisation”) on one hand an an increasingly mobile, abstracted set of property arrangements validating “mental effort” on the other.

Articulating diverse realities
(62) These systems marshal a comprehensive corpus in whose heavily annotated cross-hatched margins many different sources of biological data can be traversed via the itinerary-making capacities of bioinformatic algorithms. . . . At these interfaces, an inventor-researcher's mental effort and authorial personhood closely accompany movements across biological data. Any promising connection or similarity can be quickly named, stored and retrieved. . . . In their tracking and recording of paths between data sources in all the mechanisms for searching, labeling and annotating these systems provide, moments of invention of hybridization became nameable.
(63) Following [Geoffrey]
Bowker, any claim that life is information covers over the complicated social, technical, political and economic nexus where exchanges among living bodies, technical practices and economic value occur.

Agency of algorithms
(63-64) For an account of the contestations of agency associated with software, three general implications can be elicited from how bioinformatics treats sequence and order. The first concerns the process of abstraction intrinsic to algorithms. Algorithms do not simply speed up computation; they institute a composite time and space in which existing orderings and sequences are both preserved and reconfigured.
(64) The second important implication concerns the entwined framings at work in algorithms. . . . The incorporation of prior knowledges, codings and practices within the sequence of operations attaches specific frames and patterns to the relatively abstract space and time of algorithmic process. . . . Regarded algorithmically, even the most sophisticated, distributed, multitier software is nothing other than a coalescence of positioning and sequencing conventions, some relating to social conventions, some, as in the case of bioinformatics, relating to physical processes.
(64-65) The third implication concerns the points of attachment between algorithms and other movements and spaces. Algorithms are not neutral formal procedures. . . . Algorithms themselves are animated: they induce movement between inputs and outputs, and are themselves caught up in diagonal movements between biological knowledge and property value, movements characteristic of the new media biotechnology economy.
(65) Here the contestation of agency pivots on the composite, concatenated patterns and orderings that algorithms condense.


Chapter 4
Kernel: Code in time and space

(68) Although software developers do not in any large measure regard themselves as a disenfranchised nomadic underclass, and property rights have not collapsed (in most domains), software increasingly attracts the complex collective orderings that [Bruce]
Sterling describes [in Distraction].

The agency of distributed objects
(69) This chapter investigates some involutions in agency associated with the polymorphous Linux kernel.
(70) The problem of understanding distributed, “open” objects is not new. Alfred Gell (1998), in an innovative treatment of Polynesian funerary artworks and of artists' oeuvres (221), handles such ensemble entities—entities with components widely scattered in space and time—by attaching them to a cognitive process, itself distributed in time. The core idea is that the temporal modifications of mental states (for instance, of a social group or an artist over the years) are externalized in the relations between the objects composing the ensemble (the paintings composing the oeuvre; the gradually modified production of funerary carvings in Marquesan cultures).
(70) From the standpoint of the temporality of cognition, code objects are not to be read as static forms, but as temporal entities made up of relations between different mental states.

Linux kernel as indexical icon recursively referring to its description while performing what it describes.

(71) Linux represents software-associated collective agency in the process of constituting itself in the production and circulation of code. . . . The social organization of code work, and the operating system itself as operational object, constitute a coupled process in which describing, and enacting what is described, coalesce. . . . Glossing Gell's suggestion that collections of objects are an index of cognition in time, it can be argued that the Linux kernel functions as an intricate indexical icon, something that recursively refers to a description of itself, and in doing so performs what it describes.

The operationality of software
(73) Within technological cultures, operating systems and server software become cultural by virtue of the density of the mediations and relations that run through and texture them. . . . Increasingly representing and regulating differences in some ways and not others, once-infrastructural matters (like operating systems, protocols, algorithms and code) figure as singularities.

Linux challenges distinctions of Johnson cultural circuit.

(73) The very existence of an operating system such as Linux, which cannot be easily located within any existing sector of the software industry, challenges the analytical distinctions among production, circulation and reception (consumption, use, spectating or audiencing) relied on by social sciences and humanities.

Technical performance and performativity
(74-75) Performativity rests on extralinguistic dimensions of linguistic praxis. The wide ranging discussions in social, political and cultural theory of performativity over the last decades (
Butler 1997) have sought to emphasize this pragmatic dimension. . . . Linux's singularity consists in how it valorizes practices of coding or programming, configuring and executing code. But its uneasy relation to different commodity hardware computing platforms remains in the background.
(75) Insofar as it appears as free and technically superior to other operating systems, Linux succeeds as a speech act. However, the success of Linux as speech act is contingent upon another layer of performativity attached ot code, to what [Benjamin]
Lee and [Edward] LiPuma (2002) term “circulation.”
(75-76) Lee and LiPuma argue that circulation also produces performative effects. That is, processes of circulation themselves objectify praxis, albeit in different ways. They enact something. If information and communication networks constitute a central value for the performativity of important contemporary forms of power, then the circulation and exchange of software and code participate in the performativity. From this perspective, explicit claims about Linux's technical performance as they appear in advertisements, editorials, newsgroups, how-to manuals and popular press accounts spin off the primary, collective performativity of practices circulated as computer code.

Circulating, distributing and coordinating code
(76) A feedback loop between technical performance and performativity mentioned above plays an important role in the life of Linux because it triggers constant modulations both in the object itself and the practices associated with that object.

Distros”: Repeating and citing Linux
(77-78) As in the software artworks discussed earlier, in making the source code visible or in this case audible, “RadioFreeLinux” signals a change in the status of code as “source code.” . . . The title of the work, “RadioFreeLinux,” suggests that source code could circulate or be broadcast like radio news.
(79) Linux circulates as artwork, as a commercially packaged commodity sold by many different companies, and as freely available source code files, constantly worked on and exchanged using sophisticated software mechanisms of coordination, scheduling and organization, mechanisms usually running on Linux servers.

Linux: An object out of control?
(80) Distributions permit Linux to transit between hardware platforms and between cultural, institutional and national domains. Each new distribution and each successive release of an existing distribution incorporates and repeats the conventions embodied in the Linux kernel, but adapts those conventions to a slightly different situation.
(80) Social and cultural studies of science and technology (Latour 1996; Haraway 1997) have sought to analyze why certain contemporary technological objects are “out of control,” why they generate unexpected consequences. . . . Lash (2002) argues that such objects get out of control as an unintended consequence of modern rule-regulated reflexivity.

What Linux covers over
(81) As Linux became publicly visible during the 1990s, hacking or programming with or on Linux came to be seen as a form of life that challenged norms of property ownership and corporate organization of work (Moody 2001; Himanen 2001).
(81) Performatives work not only by citing, or enacting through describing, but by also “covering over,” as in my earlier quote from Butler, the “authoritative set of practices” that lend force to what they do.
(82) By copying or citing Unix, Linux sediments a complicated relation to proprietary hardware and software. But Unix was and remains not just another piece of software dating from the late 1960s; it adapts and continues a set of coding, software design and system administrative practices sometimes referred to as the
Unix philosophy.
(82) One side of Linux faces back towards Unix as an authorizing set of practices, but the other faces towards the Internet, the digital economy and proliferating new media.

Authorizing context I: Interaction and economy
(83) The Unix philosophy is precisely the heterogeneous mixture of practices, names, strictures, conventions and habits characteristic of any performative nexus.
(84) Not only were the features and functionality available in Unix suited to programmers, Unix was itself coeval with a particular programming language, C, which became an academic and software industry standard language. . . . The notion of everything (printers, keyboards, diskdrives, network connections, displays, other programs or users) as a “file” (Kernighan and Ritchie 1978, 2) and the notion of “the process,” plus many discrete tools and utilities for accomplishing specific programming and system development tasks, still pervade Linux.
(84) The history of distribution of Unix lies at a complicated conjunction of organization of capital, state regulation of communication, and the technical work of programming.
(85) Unix existed for a long time as software that U.S. government legislation prohibited a telecommunications company from commercializing, so AT&T Bell was compelled to give Unix away for free. At the same time, because there was no maintenance support, adopters of Unix did their own maintenance and development, turning Unix into an experimental and pedagogical platform used to teach computer science students about operating systems during the 1970s and 1980s. Because it came with and was written in its own programming language, C, Unix was highly mutable and reconfigurable: computer scientists used it to explore new protocols, data structures and hardware architectures. Unix was crucial to infrastructures of networked computers in the late 1970s, infrastructures that grew during the 1980s into the Internet.

Authorizing context II: Coordinating and communicating
(85-86) There practices intimately linked producers and users/consumers of operating systems. . . . If Minix emerged in response to the licensing restrictions of Unix source code, Linux was defined in relation to the proprietary nature of commodity hardware.
(86-87) Linux, according to Torvalds, was also a “program for hackers by a hacker” (Torvalds 1991), just as Unix was, according to Kernighan and Ritchie, a system by programmers for programmers' convenience. . . . By using the task-switching capabilities of the Intel platform, Torvalds could build a concrete implementation of the fundamental “process” abstraction. . . . In its grafting onto mass-produced consumer computing hardware, the conventional object Unix metamorphosed into something more dynamically distributed.

Demarketized approach to proprietary hardware specificities illustrated with code snippets.

(87) In Linux, a new mode of commodity consumption occurs through coding: the proprietary hardware specificities of different computational devices and peripherals are addressed in a demarketized form.
(88) The increasing illegibility shows something important. These instructions read and write to specific spatial locations on the Intel x86 family of CPUs: the input/output (IO) ports. Some of the very first lines of the Linux kernel are very closely tied to the deeply embedded specificities of the Intel 80386 chip.
(88) As widening streams of kernel code encircle new proprietary hardware specificities, a patchwork of subprojects and parallel development fold into the kernel.
(89) The Linux kernel is deeply tied to a gendered corporeal set of practices of programming work. The mention of “all-nighters,” of a time when “men wrote their own device drivers,” reminds us that Linux is above all a program by men for men who like to play with computing hardware. . . . Anthropologically speaking, these desires remain somewhat unexplained.

Moderating the movement of code
(89-90) The Linux kernel displays symptomatic features of the material culture of information. The technical performance of Linux versus other operating systems is a matter of endless contestation. Its capacity to enact what it represents or describes, however, depends on an isomorphism between distribution of work and distribution of code. . . . Linux stands at the confluence of coding practices in academic research and software industries (embodied in Unix) and the large-scale production, circulation and consumption of computers as consumer electronics.
(90) In claiming that “programs” do what they say, Latour attributes performativity to objects because they “realize” specific social actions. The complicating gloss that Linux adds is that realizing “programs in action” is provisional and open-ended in both time and space.
(90) The obvious feature of Linux in this respect—the credits listing is almost without exception male—shows that performativity synthesizes some things with great novelty but keeps others static.


Chapter 5
Java: Practical virtuality

(91-92) I turn, then, to argue against the “
software repressive hypothesisfound in many accounts, academic and nonacademic (Lohr 2002; Ullman 1997; Campbell-Kelly 2003). According to the software repressive hypothesis, software remains invisible, infrastructural and unspoken, although it should be brought to light (Graham 2004). In contrast, this chapter explores the “steady proliferation of discourses,” as Foucault (1984, 302) put it, emerging around software. These discourses of software have specific forms and objects that reconfigure the code nexus and permit different attributions of agency to software.
(92) In the main, notions of the virtual now look like exaggerated representations of certain relational potentials of computer-mediated communication. . . . Instead of insisting on the virtual, new media assume the Internet is no more transcendent than markets, nations, cultures, institutions or identities.

Deleuzean virtual as unstable relationality of real.

(93) Principally associated with Gilles Deleuze's thought (and elaborated in Shields 2003; Lister et al. 2003; Grosz 1999; Delanda 2002; Massumi 2002; Rodowick 2001; Levy 1998; Wark 2004), in this new understanding, the virtual designates something real that involves an unstable relationality or difference.
(93) [Rob]
Shields discusses virtuality in art, economics and religion; some writers strenuously resist the equation between virtuality and digital technologies.

Fieldwork philosophizing with Java programming language study follows Janz question how does one do philosophy in this place rather than transposing concepts from other disciplines.

(93-94) The trajectory of a specific quasi-technical process of “virtualization” began in the mid-1990s. In examining this trajectory, rather than transposing the concept of the virtual from cultural theory or philosophy onto new media, I undertake some “fieldwork in philosophy,” as Pierre Bourdieu termed it (quoted in Rabinow 2003, 84-5), via Java, a programming language and software platform dating from the mid-1990s. Virtuality, I would argue, is a practical project of detachment, lifting-out or disembedding actions from existing social, organization and communicative contexts—a project that produces new forms, practices, interpretations and subjectifying effects in response. The process of abstraction in Java code and programming, as we shall see, removes or brackets some things (such as hardware or operating system specificities), but makes other relations possible.

Code as practical virtuality
(95) While it would be difficult to exhaustively list the applications of Java, the breadth and variety of its circulation suggests that Java embodies a concentrated scaling-up of a particular kind of technical mediation (Latour 1996) within contemporary new media and information cultures.
(95-96) In the assemblage of code, trademarks, documents, technical models and abstractions, categories, standards, practices and events collectively named “Java,” software infrastructures, coding subjectivities and differences of rhythm and speed provisionally coalesce. . . . The practical virtual of Java begins from the minimalist technical computer science definition of the virtual as a collection of resources emulating the behavior of an actual machine, and progressively encompasses resonances and interactions between a widening circle of actors. “Virtualization” of the virtual is problematic: the process of lifting out and disentangling connections brings new configurations connected to other realities.

Software as variable ontology
(96) If it is not possible to isolate Java as an object, it might be more productively approached as a project. . . . Java is a typical variable-ontology object or project (Latour 1996, 173). The term “variable ontology” suggests that essential nature of the entity is unstable.
(98) This goes well beyond anything envisaged in Project Green a few years earlier: Java applications “are able to execute anywhere on the network.” A strong challenge to the prevailing mode of existence of software was implicit in this recontextualizing claim. If software applications can execute anywhere on the network, then they are freed or decontextualized from the notoriously localized configurations and specificities of hardware.

Solving the problem of the platform?
(99) Java complicates the picture because it figured itself as a metaplatform, a space lifted out from the already-lifted-out spaces of the Windows, Mac or Unix platforms. . . . The act of writing software, a complicated, highly labor-intensive activity, was detached from one existing context, the proprietary computer platform. As we will see, the program changed, too, becoming an “architecture-neutral object” rather [than] an architecture-specific one.
(99) Java's migration from consumer electronics to Internet programming language navigated a narrowly technological but critical passage via the web browser.
(100) We could say that in transmuting into a web browser plug-in, Java formed part of an assemblage that included the practices of web browsing and the burgeoning domain of the web itself.

Installing and implementing everywhere
(101) The “write once, run anywhere” branding of Java promised new mobility for software and software developers.
(101-102) A significant asymmetry exists between Java as a platform-neutral architecture or abstract machine and Java as a programming language. . . . The platform was designed to support a programming language it “knows nothing” about. The coupling between the programming language and the platform, even an architecture-neutral platform such as the abstractly defined JVM, runs from the language to the machine, but not in the opposite direction.
(102-103) Although the JVM was in principle supposed to “know nothing of the Java programming language,” in practice it soon became apparent that in order to work around the various limitations and problems of getting Java code to perform effectively in specific applications, programmers would have to know something about the way the JVM executed code. . . . At the same time, working from the opposite direction, it also became desirable that actual JVM's should know something about the code they were executing. . . . The separation between the layers—of language, abstract machine and actual machines—were being distorted and blurred. Implementations became shaped by what programmers wanted to code in Java, and programming changed in response to the specificities of Java implementations.
(103) Microsoft's innovations only highlighted that the coupling between Java and commodity computing hardware was abstractly defined, and that Java as an actual, executable code object was inherently unstable.

Books, screens, machines and networks
(103) In contrast with the Linux kernel, where the interplay between a collaborative Unix philosophy and the momentum of constant commodity-hardware innovation cause code to circulate, in Java's case the process of abstraction called virtualization generates the agential effect of Java software.
(104) Rather than remaining black-boxed, unrelated abstractions as defined in the specifications, both the programming language and the JVM became complex circulating forms from which other projects, promises and contexts constantly spun off.

Syntactical pastiche of other languages, texts, and especially API code reuse key to Java.

(104) Through pastiche, the borrowing of elements from other writers or texts, the JVM could both support a familiar-looking language and yet “know nothing” about it. Existing knowledge of C and C++ syntax could recirculate through Java.
(105) Not only is the language syntax itself a pastiche of C++ (and other languages, such as SmallTalk and Modula), but writing Java code relies heavily on a controlled form of pastiche. One technical term for this is “code reuse.” Another is to say that the language is “object-oriented.” . . . More concretely, Java programs are structured around invocations of existing pieces of code (objects) organized in a class hierarchy descending from a single generic class at the top called “Object.” . . . Programming work in Java often entails deciding whether a pre-defined class offers the desired behavior, and then either invoking instances of that class in a program or extending that class by creating a modified version of it (Gosling, Joy, and Steele, 1996 128-133).
(105) Once programmers have learned Java syntax, much of their programming work revolves around reading APIs and drawing together different pieces to construct a useful program. If there is a commonly interpreted text underlying the production of Java code, it includes not only Java language syntax and idioms, but also, as a central component of that text, the class hierarchy documented in the APIs.
(106) By virtue of the citational practices associated with Java (syntactical pastiche and API code reuse), Java programming forms an anchor point for practices of reading and writing code that extend well beyond the onscreen frame of the code editor and the development environment of the programmer. The APIs solidify and modulate Java both as a coding practice and as a heavily marketed software platform.

Programmers: Agents of (new media) history or new consumers?
(107) An analysis of how Java IDEs are used to code and integrate Java programs with other software would help extend the concept of virtuality to the social relationality of coding work. The “organizing devices” (Button and Sharrock 1996) that IDEs contain augment the processes of pastiche and citation.

Intense marketization of coding work itself; programmers become agents of contemporary innovation.

(107-108) While software production has long been an object of management planning (Campbell-Kelly 2003), Java arguably represents the first occasion on which coding work itself became an object of intense marketization. . . . [Scott] McNealy claims that by coding in Java, Java programmers become agents of contemporary innovation: coding in Java, they inhabit the new millennium. In his understanding, programmers are agents of cultural and technical innovation, subjects of history.

Sites of attachment
(110) If web-based applets were the front-end application that elevated Java to semipopular status via the graphical web browser, Java servlets were the infrastructural software components that allowed increasingly complicated dynamic institutional and corporate websites to move away from the ad-hoc CGI (Common Gateway Interface) Perl scripts that prevailed during the early 1990s.
(111) The character of the JVM implementation changed correspondingly. JVMs for specific purposes such as running servers or enterprise-wide functionality appeared. . . . Migrating inwards from the publicly accessible side of corporate-institutional websites, Java percolated through the burgeoning and perhaps commercially important structures of business process re-engineering and business-to-business (B2B) applications.

Virtuality overcomes separation?
(112) What is generalizable from this case study for the purposes of an ontology of software? The simple equation between virtuality and digital technologies that characterized some mid-1990s accounts of the Internet seems hardly tenable anymore.
(113) At a minimum, the marketing and strong branding of Java, key adjuncts to its virtuality, need to be analyzed.
(113-114) Usually, software works or does something independently of how the code was written. With Java, that separation between production and consumption comes into question. . . . Coding becomes something more than work, a way of keeping abreast, of being contemporary within the flow of innovations. The cost of code mobility, however, is attachment to brand.


Chapter 6
“Pits” and “traders”: Infrastructures in software

(116) Software is located somewhere in an information infrastructure, and its location has consequences for contestations of agency attached to code. . . . This chapter examines the relationship between code and infrastructural locality, using the software that manages telecommunications infrastructure as a case study. . . . At the most general level, I argue that an awareness of modifications of an embodied self and its relation to other bodies constitutes an important facet of the meeting between code and infrastructure, and thus of software as a neighborhood of relations.
(116) Methodologically speaking, the only way to meet the challenge of self-decontextualizing or “vectoral” processes (Wark 2004, 316-45) such as telecommunications is to reassess the work done by locality itself.
(117) If, as [Arjun]
Appadurai claims, most ethnographies treat locality as ground, then ethnographies of software are particularly vulnerable because the “ground” of software is already figured as deracinated, that is, as the product of “immaterial labor” (Hardt and Negri 2000), as virtualized-commodified operational object (Lash 2002), or decentralized control (Galloway 2004). Where is the “structure of feeling” that Appadurai names “inertia” in relation to software?

Where are “these things they call systems”?
(117) RAMOSS [Rural Access Multiplexing Operational Support System] existed at the time of my study (February – October 2000) as a software project in process, a collection of disparate documents, code fragments, gadgets, servers, cards and plugs. . . . RAMOSS was meant to be a piece of second-order infrastructure, an operational control system designed to monitor, control and configure a digital telecommunications infrastructure scattered over rural Australia from a bunker somewhere in North Sydney.
(118-119) RAMOSS mainly appeared as diagrams on whiteboards and in numerous documents on the computer monitors of the Forge developers. As a figure, it would never take on a very palpable or distinct form apart from the complicated, densely patterned control screens designed to be viewed by telecommunications technicians.
(119) The very figure of system entails an imagining of movement. System thinking imagines alignment, integration and connection between things that lack a more substantial or tangible unity or essence. The integrity of a system has to be projected or imagined because it cannot readily be seen.

RAMOSS crosses boundaries
(120) RAMOSS as a software system moves in a broader field of relations that Appadurai called “technoscape.”

How are boundaries crossed?
(122) Just as Java faced the problem of moving executable code between different parts of the Internet, RAMOSS faced the problem of moving digital information between different network infrastructures, the Internet and POTS. . . . If RAMOSS goes ahead, new remote unit cards (RU cards) will be installed in thousands of roadside pits, junction boxes and rural exchanges. These cards perform the one-to-many work of multiplexing.
(122) Each connection that runs through one of these cards to a local telephone loop will need to be individually configured, and each card will need regular monitoring and occasional software updates.

Software between-places
(123) The experience of building ANTOSS, an operational support system for a different telecommunications network, changed Forge itself as locality. Forge became a kind of “
between-placewhere diverse telecommunications realities encountered each other, a place that facilitated imagining movement across boundaries.
(124) In the server room, Forge turned itself into a miniature version of the national telephone infrastructure, or at least of some salient facets of it.
(124) The Internet and POTS stood apart from each other within this densely equipped and computationally patterned place, just as they did nationally. In order to open up new movements within that infrastructure, and to afford the geographical/technical boundary crossing which the RAMOSS project imagines for rural Australia, the separate elements would have to be interlaced with each other. . . . These walls, in short, must move closer or be folded into each other, gradually interlaced through a lightweight fabric of code and protocols.

Between-places created by software and system integration projects illustrates variable ontology as well as afford boundary crossing of more fixed assemblages.

(125) The “between-place” is made with a view to crossing boundaries and divides: it is neither inside nor outside. . . . The work of software and telecommunications engineers, web developers, project managers, system administrators and technicians brought those walls into contact by coding a tissue of partially imagined and partially materialized connections.

Mobilizations: Process in software
(125) In principle, Forge software developers and telecommunications engineers wanted to read and write code that would permit controlled, predictable and scaleable movement between the walls of the server room. Their many drawings, diagrams, models, and discussions of code, objects, classes, methods, variables, “config files” and so on sought to marshal those movements along certain lines.
(126) “Process talk” constituted a strongly valorized way of imagining or projecting RAMOSS as if it were already a system sitting in the server room.

Parallels to Latour Aramis study; infusion of ambient theories of project management.

(126) We could regard this talk about “Forge process” as part of a parasitic “quality management” discourse, a symptom of Forge's localized microvision of modernity. Latour (1996) suggests a different view: “ . . . it plays the same essential role that strategic doctrines play in the conduct of wars. . . . Writing a project's history also means writing the history of the ambient theories about project management.” (113)
(126) “Forge process” was heavily infused with ambient theories of project management.
(127) The phases, steps and stages for implementing RAMOSS were an important way in which people at Forge projected what RAMOSS would be. . . . New software developers, eager to begin cutting code when they arrived, instead started by learning about Forge process, and as they took on the modeling skills and practiced documentation, they became part of that process.
(127-128) The “
collaborative craftwork(Suchman and Trigg 1992, 173) of producing the documents, specifications, architectures and class diagrams required by Forge process did not move RAMOSS effortlessly or evenly. . . . [However] Nearly all traces of the fairly complex negotiations over how the system should work on a very specific point would disappear, replaced by a formal abstract diagram of boxes, arrows and labels.
(128) The proliferation of formalisms produced large “documentation trees.”
(128-129) Drawing more directly on RUP (rational unified process), the unified modeling language (UMI) guided the production of “class diagrams,” the object-oriented software models of low-level components of RAMOSS, and “sequence diagrams,” diagrams showing the planned order of events meant to occur when the system ran.
(129) While the developers gradually wrote and rewrote RAMOSS as a program, a somewhat static description of a projected thing in the world, the program ultimately becomes a system only by becoming a process or processes.

Variable ontology of software includes documents, tools, and human agents; virtual static central subject position meant to coalesce in in media res (Chun).

(129) It exists somewhere between the relatively visible projections and descriptions embodied in documents and jostling technical fragments—software tools, implementations of different communication protocols, network cards, virtual machine implementations, and executable/readable code on developers' computers. Progress seeks to compact those fragments together and increasingly restrict their movements—to establish a static central subject position. The team, to the extent that it collectively embodies the effects of the imperatives issuing from process, is meant to identify with, if not occupy, that position.

RAMOSS imagined remotely
(131) Quotidian imagining materialized prosaically in the developers' suite. Modular workstations faced the walls, and mugs, stuffed toys, books, baseball caps, assorted pamphlets and books littered the bookshelves above each workstation. These artifacts flagged the imagining of other relations running through RAMOSS. . . . Just like the “gimme” souvenir mugs, toys, pens and caps, which constitute seductive minor mediations of the products they promote (ORACLE databases, Orbix 2000, the JavaOne annual conference), the websites and books constantly consulted by the developers attest to something important about the fabric of RAMOSS as system. RAMOSS includes or cites many other systems, conventions and artifacts. . . . Almost nothing in RAMOSS started from scratch.

Contrary to early software industry where everything was written from scratch, now imported protocols, standards, and branded components proliferate to create inner space inhabited by software developers, leading to notion of code as collective imagining.

(132) Thus developers inscribe internal boundaries in the system that derived less form technical, operational or geographical problems than from a vision of flexibility and configurability attached to imported protocols, models and architectures. These imported models, architectures and protocols, moreover, are subject to fashion, are evaluated as “cool” or “uncool,” and can therefore be seen as bearers of contemporary collective imaginings of flexible, configurable and intercommunicating code processes from outside the process. . . . These imported protocols and standards arrive via electronic journal and periodical articles and thick computer books published by O'Reilly or Addison Wesley. In addition, imported standards and protocols flow in and out via software modules used as prefabricated components of the systems.
(132) [quoting Bowker and Star] “
Infrastructure is now the great inner space(319). In a vital sense, the protocols, models, code patterns and standards in RAMOSS crystallize an inner space inhabited by software developers.

Flexibility and mobility as collective imagining
(135) The incorporation of different models, standards and protocols means that the system gradually takes on an open yet highly interlocked texture of different metaphors or tropes, many of which bring associations quite remote from telephone networks and rural network access.
(135-136) Watching software developers at work reveals how the code they write is modulated from afar by a certain vision of flexibility or reconfigurability figured via social or communicative conventions such as request, transaction or notification.

The formation of relations in software
(137) Although obstacles and difficulties do arise, figures of imagined flexibility, free movement and open communication pervade software and modulate software from a distance.
(138) The Forge process projects the ideal of a system as the output of series of stages, following in order and gradually merging into an integrated system. Yet the cross-cutting imaginings of mobility and reconfigurability—embodied in programming languages such as Java, platforms such as Linux, and in standards, protocols and specifications such as Corba (themselves embedded in software tools, documents and websites)--constantly suggest new connecting pathways, open new perspectives and introduce new interfaces and obstacles.
(138) A key point of this chapter is that detours might simultaneously contextualize and decontextualize software.
(138) Code understood as a collective imagining seems a long way from code as a program of instructions for a machine to execute. However, practices of imagining are not purely mental operations; in no way does imagining reduce to a detached, abstract fantasy. It constitutes collective relational realities. Software attaches different localities to each other because it diffuses relations between them. The composite texture of software is reliant on unfinished exchanges between code and coders. Imagining generates relations over time, a sort of unfinished business, in which “delay or lag between transactions” (Gell 1998, 81) results in binding social force.


Chapter 7
Extreme programming: Code as prototype for software

(140) Rather than dealing with increasing abstraction, programming is constantly beset by conflicts between different processes of abstraction. Analyses of new media and information cultures that predicate abstraction as a key process (Wark 2004; Hardt and Negri 2000) need to address this apparent contradiction between abstraction and specificity in software. This chapter addresses some ways in which programming work resists its own abstraction through an ethnographic case study of a popular software development methodology called “extreme programming” (Auer and Miller 2002; Beck 2000; Jeffries 2004; Succi 2002; Wake 2001).
(140-141) When, as in extreme programming or XP . . . software development allies itself to extreme sports, when it strips down to a bare minimum of equipment, the hope is that programming could be disentangled from an overly gadget-enhanced, system-managed experience. . . . The effort to sustain the primacy of programming in software production triggers new permutations in the agential relations associated with code.

Unwanted equipment
(142) In their account of why highly formalized or structured systems of collaboration fail, the sociologists Susan Leigh Star and Karen Ruhleder argue that the obstacle to generalized systems of collaboration usually resides in local practices.
(142) Importantly, XP promotes selected elements of local practice into production processes, as if programmers have learnt a lesson on how to construct constellations of interwoven elements as local-global hybridizations.
(143) Rather, ethnographic observation should help us understand an encounter between a programmer-centric software-production discourse and a group of actual programmers. The aim of such an investigation is not to develop general models of ordinary activity, but to examine the hybridization between densely embodied local practices and abstract, infrastructural or formal elements.
(143) When my study started in mid-2001, a software development project was well underway at Knowledge Management Systems (KMS), a software production house in Manchester Science Park, which is situated near the universities east of Manchester's city center in northwest England. A small, somewhat fluctuating team of software developers, testers and managers (six to twelve people) were working on a knowledge management system called Deskartes Universal. . . . It organizes documents within a heavily keyworded, cross-referenced repository that can process and “learn” from natural language search queries.

When the cards are down: XP as a game of software development
(145) Some of these features—the snack food, the mobile phones and handhelds, the thick semipopular computer how-to books—are common to software development teams. Yet the environment at KMS was patterned to ensure that software systems were developed in certain ways and not others: the build machine at the end of the rectangular table, the memo board with colored cards, the chairs rolled together and the arrangement of the tables into a central island signify a somewhat unusual organization of software development.

Programming itself” (with just a few small things added
(147) Looping or iterating, a fundamental formal structure of most programming languages, becomes in XP a rhetorical tactic used to refigure all software development as something akin to coding. It seeks to shield coding from being overtaken by the dangers that Ellen Ullman refers to when she laments the “dark, unspecified areas.”

Cardboard as programming tool
(148) In discarding those sophisticated software-based tools for an archaic graphic medium like index cards, in replacing “requirements engineering” with “gathering stories,” XP scales software development back—and shields it from management scrutiny.

Calculating time: “Ideal Graham days”
(149) The weight of a story card—its worth—was worked out by developers through a complex set of negotiations carried out in team meetings. The stories had been written by Dave, the team leader, in collaboration with Mike, the XP “customer” or notional user of Universal. At KMS, story cards were read to developers during planning meetings. Afterward, the tasks composing the story needed to be worked out.
(149) A story underwent translation onto blue task cards through spoken interactions between different members of the team.
(150) References and reminders of code already written for previous tasks form an important component of the exchange. The conversation brought new cards into circulation, and at the same time, the future circulation of those cards in the group was foreshadowed.
(151) The cards circulated thereafter as tokens of that structuring of group and system achieved in the meeting. Problems, unanticipated difficulties and implications emerged later, but they were partly framed by a collective cognition already developed in the group.

Nested loops and relations with others
(151-152) Although programming is what programmers know best, in XP they are also asked to relate to software development in another way: their work process is metaphorically treated as programming, as setting up and running loops over time. Each level of nested loop takes into account different kinds of unpredictability, runs over different time frames and makes use of different ways of organizing communication within the developer team. A “release” cycle will run between two and six months and involves writing stories; an “iteration” will involve programming some stories and last one to four weeks; a “task” will take a few days; and writing “unit tests” and code in pairs will take a few hours.
(152) XP promises to put the system into service in the “real world” right away, in its first release loop.

Exiting the loop
(153) If programmers collectively turn their work into a form of embodied program based on loops executed over weeks and months, how is execution linked to production of software?
(153) The other guiding metaphor for XP, driving, is as Beck (2000) says, “the paradigm for XP”: “software development is like steering, not like getting the car pointed straight down the road. Our job as programmers is to give the customer a steering wheel and give them feedback about exactly where we are on the road” (28). In principle, the practices that organize work within loops include the planning game discussed above, frequent releases of the software, an aversion to overly complex software designs or architectures, tight limits on working time, and unusual approaches to coding work such as pair programming, collective code ownership, continuous integration and writing tests for the software before the software itself (Beck 2000, 54). Via these practices, the programming team turns itself into a car, presumably an expensive one, driven by the “customer” or client.
(154) In XP, a number of crucial relations in the production of code converge on unit tests. . . . Developers commit code to the repository only on the condition that all existing unit tests have been passed. Writing and running code in the form of unit tests allows melding of changes to the shared code of the system itself to become a frequent and relatively uneventful process.
(154) KMS used a simple software tool, JUnit, develoepd by Kent Beck, to automatically run the tests.
(155) Rather than just testing their own code, developers typically ran all the tests written to date to ensure that hidden conflicts between changes and other parts of the system became visible as early as possible. . . . The practice of testing merges in this example with continuous integration, so that production becomes something more, like continuous modulation. As Latour (1996) writes, “By accumulating little solidities, little durabilities, little resistances, the project ends up gradually becoming somewhat more real” (45-46).

Programming talks code into existence
(155) For programmers, pair programming seems to be the most startling feature of XP. It forces them to forfeit coding autonomy.

Pair programming forfeits autonomy of individual programmer and foregrounds dialogue.

(156) These changes in the workplace setup generated a great amount of talk about code and coding. Usually programming and software development are seen as solitary and cerebral rather than oral.
(157) Without an articulation of how the system works, programmers cannot code as a pair. By this simple measure, XP attaches talking and intersubjective communication to programming.
(159) Small knots, kinks or hitches that snag the execution of code loops in the XP process are not just problems to be ironed out. They indicate where different materializations of agency are at stake, where who does what is decided.

Timing between development and production
(159) “Will the system hand together?” doesn't loom large because the continuous integration entailed in writing and running unit tests has pre-empted that question.
(160) Continuous system integration includes complicated temporal coordination between members of the development team and shared spontaneous articulation of contingent interpretations of the current state of code development.
(162-163) The status of configuration work, a topic that has been of substantial interest to sociologists and anthropologists of technology, remains uncertain in XP. . . . Like a harmful “goto” statement, configuration work can produce tangles. Configuration work of “setup hell” incessantly troubles software systems, as well as many other technical practices (Suchman 1987).

The problem of the doppelgänger: Simultaneous versions
(163) Whereas XP predicates the release of a quick succession of versions, it does not envisage simultaneous execution of different loops.

The upshot
(165) Several striking features of software production and the contemporary codescape emerge from extreme programming. Firstly, the potential significance of handwritten index cards in XP should not be underestimated. . . . Without the cards, the nested-loop structure through which work was organized at KMS could not have been maintained. Taking, swapping, signing-off and putting back cards—these acts made visible markers of work available to everyone. They allowed visual, almost immediate appraisal of collective work progress.
(166) XP insists strongly on the value of co-location, even as it works on software that might be itself highly distributed. . . . Something as simple as a set of cards in conjunction with a small piece of software like JUnit can be used to synthesize forms of practice that inhabit organizational life differently.
(166-167) Suchman and Trigg wanted to counteract abstract models of mental operation predominant in AI research with the concrete, localized and embodied practices of AI researchers. Through their analysis of craftwork in the production of AI models, they sought to render visible the dark matter of AI research, especially as it transpires in the course of conversations and whiteboard writing. From a different direction, XP does something similar for software development. Rather than leaving “behind the logic of its own production and use,” XP effectively turns the coordinated craftwork of hands, eyes, keys, screen and signs into the basis of a situated practice that resists formalism.
(167) Much more than technical risk, the projection of dialogue, argument, agreement and evaluation onto software production through the lens of programming moves communication into the heart of making.


Chapter 8
Conclusion

(169) Here is some Java code that belongs to the ordinary software, OpenOffice 1.1 (OpenOffice 2004), of which I am a user.
(170) It is readable, and with less difficulty that might appear at first glance.

Agency, materiality and sociality in software
(171) My attempt to say what software is runs in the wrong direction, as if it had a counterhistorical bent: instead of becoming more precise, it becomes broader. . . . Three primary facets of the composition of software can be found in the code fragment above: agency, materiality and sociality.
(171) Intentions as the origin of social actions have been replaced by understandings of actions emerging from networks of relations between bodies and things (Clark 1997; Latour 2004; Law and Hassard 1999).
(172) The multiplicity of relations assembled in code triggers an unpredictable dynamism that intricately alters our sense of matter or stuff.
(173) What counts as matter, and the outlines of what we touch, see and hear, are now regarded as a social historical zone of contestation (Crary 1999). Perceptions of materiality and the materialities of perception figure centrally in relation to software.
(173-174) From this general perspective, a primary object of software design and programming work is sociality itself, and how sociality can be transformed, redistributed or deployed. . . . If software is central to the construction of increasingly complex barriers, thresholds and gateways on the web, code and coding can begin to provide a different perspective on the topology of that space.

Java code fragment illustrates cooperation and embedded presence of others.

(174) Perhaps more importantly, we can see within code how communication itself becomes a productive force. . . . Scanning the lines of the code sample above, the prevalence of terms such as “manager,” “service,” “resolver,” “helper,” “context,” “query,” “interface,” “remote” and “local” suggests just how basic cooperation has become to the very fabric of software. Code dissolves and crystallizes the presence of others.

Ordinary and singular coding

Examine portrayal of programmers in film; go back to War Games.

(175) On the [one] hand, as the scene from Swordfish figured it, coding work is highly valued because it is somewhat arcane and otherworldly in its abstraction. . . . Correspondingly, the figure of the programmer has altered since the mid-1990s. A comparison between Dennis, the systems programmer in the film Jurassic Park (Spielberg 1993), and Stan, the programmer in Swordfish (Sena 2001), two films separated by almost ten years and the growth of the Internet, indicates some important differences.
(175-176) On the other hand, as chapters 4, 5 and 7 argued, the agency of programmer as originators is managed, contested and even itself commodified in various ways as the work of programming becomes more widely relevant. . . . Programming work is constituted and accompanied by its own style of organizing code. The development of the Linux kernel was characterized by a distributed, concentric circulation of code spiraling outwards and gradually becoming less adaptable as it fell behind the expanding perimeter of files that represent the latest kernel version. . . . In contrast to the distributed space and time of the Linux kernel, the Java Virtual Machine and Java programming language mobilized the ideals of cross-platform mobility in the promise of virtuality: “Write once, run anywhere.” . . . Highly recursive, extreme programming treats “the program” as both the object and model of work.

Program as ideal repetition
(176) The perception of coding as a programming relies on an idea of software as program. . . . Rather than the abstract relations and operations on sets of entities envisaged by theoretical computer science, actual algorithms display a composite or mosaic texture that concatenates different regions and neighborhoods of relations. . . . Furthermore, the repetition and circulation of algorithms themselves, the way in which their style of operating is imitated, is highly unstable.
(177) The presence of an Internet-style architecture gives pause for thought. If the program epitomizes predictable, mechanical repetition of operations, it also represents what cannot be fully predicted: it might allow new forms of identity, sociality, materiality, communication, politics, production or consumption to emerge. . . . In terms of the software ontology explored here, code, the material that lies at the core of software, is unstable because it is both expression and action, neither of which are materially nor socially stable.

Does code do what it says? Force and form in code
(178) Because they increasingly embody hidden states or folds, algorithms construct “microworlds” (Thrift 2004a, 584) from concatenations, collections and paths they bring into mosaic conjunction. . . . In the case of Linux, the social relations between programmers—grounded in reading and writing code—coalesce with the social force of Linux as an alternative to mass-market software industry products. Performance of code cannot be separated in this instance from a description of that performance lodged in the code itself.
(178-179) As a form, code supports many idealizations, such as Java's write-once, run-anywhere claim. . . . Code itself as a material is organized by many forms of idealization borrowed from mathematics, logistics and information sciences. . . . In this respect, every programming language is already an ontology.
(179) But code's ideality is perpetually undercut by contestations of coding work that come both from programmers themselves and from the far-from-ideal situations to which software is exposed. . . . In the case study of extreme programming, this between-place of software development is also contested. In XP, system architecture and coding style are no long the primary concerns; rather, relations between programmers themselves become the primary preoccupation of coding work.

Software discourses
(179-180) Whenever software becomes widely visible, a discourse concerning code and coding is attached to it. . . . Often, the producers of software put themselves at the center of these discourses (Knuth 1968; Himanen 2001; Graham 2004; Raymond 2001) as the originators of software.
(180) However, sometimes what becomes discursively salient is not the prototype or originators but some aspect of the code itself.
(180) All software development processes adopt prototypes: models, situations, hardware or persons that elaborate a more or less explicit representation of something that code stands in for. Nonetheless, these prototypes, as implied in the mixture of types found in the OpenOffice code sample, are often hybrid entities.

Convolutions and involutions of agency
(181) One implication of the software ontology we have been discussing is that the “writing of technology” is by no means universal; the opaque and stubborn places do not lie simply beneath technology, but are wrapped around an in it. . . . No particular symbolism, socioeconomic order, territorial unity or politics absolutely dominates in software.
(181-182) Although it is very hard to ignore the dominant figure of the individual user that accompanies much popular software, even the identity and capacities of the user are contested figures in software, perhaps just as much as the consumer is in advertising. . . . The anthropologist Clifford
Geertz used the term “involutionto describe the increasingly elaborate cultural production that occurs in certain socioeconomic conditions (Geertz 1994). . . . One of the effects of involution of agency in code is that software takes on increasingly self-referential aspects. Software generates discourse because involution tends toward self-identity.
(182) The other principal patterning of agential relations could be termed “
convolutionbecause it takes existing relations and combines them into a composite relation that blurs or echoes the starting relations. . . . The specificity of software, if it exists, consists in the convolutional production of these relations in a material with particular properties and practices associated with code.

A general dynamics of software?
(182-183) In a significant and relevant sense, software could be seen as the epitome of work under the conditions of “new capitalism” (Sennett 1998) or as “immaterial labor” (Hardt and Negri 2000, 293). . . . Analysis of code as the material of software cannot be detached from analysis of coding as making software.
(183) The kinds, folds, tricks or slippages that imbue software with a specific texture are also styles of relation, ways of connecting and concatenating actions and events in commonplace or generic ways.

Immanence of social space within productive machine.

(183-184) There is much to elaborate in this quote [from Hardt and Negri 2000], but the part that is particularly relevant to software concerns the “immanence” of social space within the “productive machine.” . . . The introjection of communicative relations in extreme programming, the formative role of process in software engineering, and the commodification of coding itself as a productive activity can all be seen as transporting a social space into the “networks” of software.


Mackenzie, Adrian. Cutting Code: Software and Sociality. New York: Peter Lang Publishing, Inc. 2006. Print.