13

Why We Must Read the Code: The Science Wars, Episode IV

Mark C. Marino

During the 2012 Super Bowl, an ad by Republican Senate candidate Pete Hoekstra attacked his rival Debbie Stabenow with a video of a young Asian woman riding a bicycle through a rice paddy. The woman stops and, speaking to the camera, thanks Stabenow for spending so much money that the United States has to borrow from her country, leaving the U.S. economy weak and sending jobs overseas. The rhetoric of the commercial is fairly conventional for fomenting light xenophobic panic, situating the foreign threat as feminine and the country’s development as backwards by seating her on a bicycle, which, ironically, U.S. cities are scrambling to accommodate as Americans seek alternatives to commuting in gas-powered vehicles.

However, the most provocative part of this ad may be the code that delivered this video. On the web page for the ad, the HTML code to display the picture reads:

The first part of that tag, “img,” inserts the image into the web page. The second part, class="yellowgirl," activates a style sheet reference that indicates how the image should be displayed. The campaign later explained that “yellowgirl” was short for “yellowshirtgirl,” marking her by her clothing, yet that excuse came too late to stem the tide of the online backlash with respondents for whom the code manifested the underlying racism of the ad. Regardless of the intention of the programmers, this episode made one thing very clear: code is not just a list of instructions for the computer. It is a layer of discourse, a text to be accessed by computers, programmers, and many others, and more important, code is a text with connotations that are in conversation with its functioning. In other words, this incident is another sign that code has become a text that programmers and increasingly nonprogrammers are discussing and interpreting.

Critical Code Studies (CCS) names the practice of interpreting what I call the extra-functional significance of code, “extra” here meaning “emerging from” rather than “outside” or “beyond.” The practice answers a call within the digital humanities from N. Katherine Hayles and others for “Media Specific Analysis,” which is the examination of an artifact with specific attention to the affordances and limitations of the particular medium in which that object has been created and presented (Hayles and Burdick, Writing Machines, 29). CCS does not merely look at the source code but uses the code as a central axis for accessing and analyzing the digital object. At times, it explores existing programming paradigms, but it also questions the choices that were made, examining among other aspects the underlying assumptions, models of the world, and constraints (whether technological or social) that helped shape the code. CCS scholars have taken up questions that are familiar to computer science, such as the history of programming languages or the notions of “beauty” and “elegance” in code, and have also ventured into more controversial topics, such as imagining a feminist programming language or exploring the postcolonial implications of a programming language based not in English but in Arabic.1 Due to these more provocative topics, CCS has been taken, at times, as an assault on the realm of programmers.

Of course, this “yellowshirtgirl” reading is fairly straightforward and arguably superficial. It is also overtly political, dealing with an election and the topic of international trade. It does not go very far into the realm of computer programming. What is being called into question here is the name of a style sheet class, not even a command from the programming language. But what happens when the relationship of the code and the meaning is less straightforward? What happens when CCS begins to interpret the specific tokens of a programming language? What happens when one finds meaning in the way functions are implemented? What happens when the political reading involves challenging social norms? Interpretation is the provenance of the humanities, but when humanities scholars extend their reach into the realm of computer science, their entry is met with suspicion. What makes Critical Code Studies seem like an affront to computer scientists, and how can the fears and alarms that it trips be silenced before it stirs up another science war?

There Goes the Neighborhood!

Several years ago, the assistant director of R&D at the Maryland Institute for Technology in the Humanities, Travis Brown, wrote a post about Critical Code Studies on Lambda the Ultimate, a forum focusing on computer programming language theory. In his post, he presented the basic definition of Critical Code Studies along with a list of three concerns. First, he saw CCS as relying too heavily on “crit-theory jargon,” with which he professed only a moderate fluency. Second, he argued that the readings seemed to focus exclusively on imperative programming languages—a criticism that no longer holds true, given the growing diversity of examples subjected to analysis. The third point argued that no one associated with the blog has a CS degree, a point which was false but perhaps not obvious from perusing a mere list of names. However, Brown’s comments and the discussion that followed point to a particularly sensitive area at the intersection of computer science and digital humanities scholarship, one that scholars ignore at their peril.

Although the language of Brown’s initial posting was fairly neutral, the early round of comments made it clear that at least some members of the community were taking the post as “red meat”—incendiary material posted by an outsider intended to provoke indignant rants. The primary question seemed to be summed up in this comment:

This comment identifies a pervasive misconception that literary criticism concerns itself only with the symbolism and aesthetics of poems, plays, and prose, a view that overlooks the role of historical and social scholarship in literary studies, not to mention the impact of semiotics and cultural studies in expanding the sense of what counts as a text for interpretation.

Most upset was a contributor named Thomas Lord, who parodied the academic language of Critical Code Studies, writing:

Lord’s parody of academic philosophy mocks both what he views as its pompous style and its pseudo-intellectualism, a result of layering interpretations upon interpretations. While Lord and others involved in this discussion do concede that there is a meaning in code and that philosophical and political readings are also important, the sarcasm in early reactions against CCS express a sense of the interpretive incursion of CCS as an assault on a protected domain. Rather than a distrust of literary interpretation, this defensiveness seems to be a response to the premises of the philosophy and the leanings of the politics, in the broader sense, being applied to code.

Here and in his other comments on the thread, Lord, perhaps inadvertently, emphasizes the specialized language of two divergent discourse communities. On the one hand, he is enraged by the use of an obfuscated philosophy-speak that is being used to express fairly simple and obvious truths. On the other hand, he resists humanist forays into the explication of “the complexities of technical vocabulary formation.” As he explains, “Here in programming land, we also use other ordinary language words in strange ways. We talk about correctness, expressiveness, abstraction, composition,” although he admits that “in and around programming languages, we manage to not confine our use of those terms to their strict technical sense.” So while he calls for the use of “plain English,” or a critical discourse without specialized terms (aka jargon), he builds a bulwark around the specialized language of computer programming against the barbarians of critical theory.

Certainly, CCS needs to attend to the specialized vocabulary of computer science as well as appropriate usage, both formal and informal, of this vocabulary within a variety of communities. However, what is at stake here has little to do with plain speech; rather, the threat comes from the left-leaning political points of view encoded in the particular “jargon.” Plainly, what irks some programmers about CCS is not its highfalutin language, but the politics that the ideological language of critical theory brings to the putatively pure, functional language (computer source code). Such programmers are invested in a vision—a fantasy, CCS would suggest—of their work as apolitical, completely outside the context of social and political culture. Indeed, that is a political fantasy that the methods of Critical Code Studies can dispel, but not without creating some discomfort.

A Worm Named Annakournikova

The discussion on Lamda the Ultimate appears at first glance to be a general reaction to the incursion of humanities-style interpretation of code into the culture of programming, but the specific source of the hostile response was an essay I wrote that analyzed a computer worm named annakournikova, along with several works of code poetry, through the theoretical lens of heteronormativity. Circulating at the turn of the millennium, the annakournikova worm arrived as an e-mail seeming to offer photographs of Anna Kournikova, the tennis player known just as much for her modeling career as for her domination on the WTA Tour. Opening the file, which was actually Virtual Basic Script, executed code that reproduced the file and sent the e-mail to the victim’s entire address book. In my essay, I positioned the code poetry as being disruptive to existing social norms while, by contrast, I claimed, the worm operated in a manner analogous to heteronormativity. To accept any part of this argument, the reader would have to at least entertain the premise of heteronormativity—a prospect that would mark me, the essay’s author, as what conservative online communities refer to as a SJW or Social Justice Warrior, their label for actors with progressive agendas and, implicitly, baseless arguments.

However, it was not only the ideological critique implicit in the term “heteronormativity” that was provocative; so, too, was my actual analysis. For rather than arguing that heteronormativity is merely present in code, I argued that the annakournikova worm operated with the logic of heteronormativity.3 The parallel works something like this: like a malware worm, norms of society are registered and accepted by members and are then repeated and circulated by them without their conscious awareness. The worm that circulates through the unwitting participation of those promised pictures of the tennis ingénue (with a wink) is not just similar to heteronormativity, it epitomizes that reproductive logic. Consider a similar line of argumentation that Tara McPherson presents when she examines the way the logic of Unix conflicted with the socially progressive changes of the Civil Rights movement. Such interpretations are based on abstractions of underlying logic both in their discussions of technology and society, rather than the denotations of specific software processes. In other words, the annakournikova worm was not built on heteronormative code (whatever that might mean) but was instead an agent of a heteronormativity that reproduces itself across a computational system in a way analogous to how heteronormativity reproduces itself across human culture.

The offensiveness of these structural readings—as evinced by Lord’s response to my heteronormativity argument—is rooted in their theoretical framing. But there is a deeper level of suspicion here, a sense that criticism performs a kind of sleight of hand with technological objects, imposing and inscribing on them political dynamics by means of an obfuscated set of rhetorical moves. Theory acts, as it were, like another worm replicating itself throughout the academy. Surely, this caricatured narrative battle between left-leaning humanists and conservative scientists has been depicted for decades, reemerging periodically in the discussion of absurd-sounding titles of Modern Language Association (MLA) papers or reports of radical art projects that have garnered paltry federal grants. But critiques of Critical Code Studies often reference a particular moment in literary history—the debate between scientific theorists and postmodernist critics known as the “Science Wars.” Lane Wilkinson writes on his blog, Sense and Reference, “I’m baffled by the silliness of some of the Postmodernism 2.0 stuff like ‘Critical Code Studies,’ ‘The Ethno-Hermeneutics of jQuery,’ or “Postcolonial Client-Server Architecture.’” Wilkinson’s attack is not on the general aspects of this poststructuralist reading, but particularly on the application of countercultural critiques to the field of science. By joining the jargon of literary criticism with arbitrary aspects of programming, he presents the methods of CCS as equally arbitrary.

It is not my intention to reignite the Science Wars by renewing the attack on scientific knowledge—if there ever was one. Bruno Latour and C. P. Snow have presented many ways to bridge that divide, as have other writers, including those appearing in this volume. Instead, I would argue, in the plainest possible language, that scholars working in the realms of science should not fear that critical theory is out to get them or to trivialize scientific discovery through the hocus pocus of hermeneutics. We cannot build a velvet rope around code (and other artifacts of science) to protect it from the interpreting hooligans and marginalized peoples of the digital humanities (or who wish to transform it), perhaps most definitely because, in increasing numbers, those hooligans and marginalized peoples are writing code of their own.

Code Reading in Action

Over the past decade, Critical Code Studies has proved itself to be more than mere free associations on the constructs of programming or a progressive political assault on the realm of computer science. Strong code readings are grounded in a thorough understanding of the functioning of the code, the software and hardware constraints that shape it, and the history of its development and circulation. The word “critical” underscores the role of theoretical humanistic lenses even as it emphasizes the importance of interpretation to this work. The critical stance supports the questioning of existing power structures that influence and are enacted through production of code. However, its interpretations of the sign systems of code are not limited to a particular political perspective. Instead, its methods and interpretation offer a bridge between the disciplines of computer science and the humanities. By treating code as something that is not an inevitable, natural, or purely objective structure, it moves beyond the progress narrative of pragmatics, asking what forces, social and material, shaped the development of the code. It explores the rhetoric and semiotics, the connotations and contexts, uncovering histories and assumptions as well as consequences and implications of the choices made in developing code, programming languages, and programming environments. The following examples demonstrate how Critical Code Studies does not serve merely to document the social history of code, but also to illuminate new ways of presenting and exploring the origins and structures of code and the way its form complements and complicates its functioning. 

Transborder Immigrant Tool

Critical Code Studies has continued to examine provocative—and politicized—works of media art, such as the codebase of the Transborder Immigrant Tool.4 This mobile phone application, written by the Electronic Disturbance Theater (EDT), is an example of software whose authors considered the code part of the poetic work and expected it to be read and interpreted, another sign of the impact of the growing community of CCS scholars. The tool aims to sustain undocumented border crossers by directing them to caches of water in the desert and by playing them poetry that discusses a range of content, including practical techniques for surviving in the desert. The code was written in Java Platform, Micro Edition (J2ME) for a Motorola phone and was made available online during the 2010 CCS conference at the University of Southern California (USC) by co-developer Brett Stalbaum.

Before a scholar can build a CCS interpretation, he or she must first know how the code functions. My interpretive process thus began by tracing through the functioning of the code, consulting with Stalbaum when I had questions about how it operated. In Stalbaum’s code, I explored unusual structures and naming conventions, and I was struck by the use of what seemed to be a metaphor of water witching that appeared in one of the method declarations:

This call to “witchingEvent” is triggered when a water cache has been located near the current position of the phone. Water witching or dowsing names the practice of searching for water by walking around with a stick and waiting for it to be drawn toward the water. Surprisingly, this high-tech, GPS-driven location device drew its conceptual metaphor from a folk practice that relies not on the latest mobile-phone widgetry but instead on wood sticks that seem to know where water is hiding. Divining through the history of TBT’s source code, so to speak, I found that this section was written by then-undergraduate Jason Najarro, for whom the witching metaphor was so resonant he created presentations about it.5

In using the metaphor of dowsing, the programmers were doing something both political and provocative—they aligned the tool with the Mayan technologies that the EDT group learned from the Zapatistas.6 These are the technologies of cultures that cannot be contained within Western epistemes, technologies of disruption and provocation that Rita Raley calls “tactical media.” The function call and its calculations, re-envisioned as an act of divination, shape the meaning of the tool.

Is such a reading of a metaphor an affront to programmers? It shouldn’t be, but because the reading hinges on what computer scientists would call an “arbitrary” portion of the code—that is, a human-specified value that has no significance in the programming language—it may be prone to criticism. After all, the function could just as easily have been named “XYZZY.” Function names are unlike primitives such as “public” or “void,” which have fixed syntactical values in Java. In fact, in a discussion on the HASTAC Scholars forums, Evan Buswell warns against CCS grounding its interpretations in these arbitrary aspects. In his comment, he imagines a future in which CCS is “wildly successful,” one in which “CCS practitioners are maybe brought into courtrooms to establish the evil intentions of some maniacal programmer bent on threatening democracy.” Buswell argues that should this scenario come to fruition:

In such a world, Critical Code Studies would be relegated to superficial critiques of arbitrary elements of code, leaving it incapable of speaking to the forces at work in technoculture. That is to say, it could speak to the ornamentation but not the architecture of the world of computation. To contribute fully to the analyses already under way in computer science, Critical Code Studies cannot merely dwell on the arbitrary elements or the comments included in code. It must pursue the aspects of the code that are fundamental to the chosen language and the structure of the specific program. It cannot rely merely on high-level abstractions of the logic of the program. At the same time, it should not neglect the arbitrary, for those elements are most explicitly written for human readers.

10 PRINT CHR$(205.5+RND(1)); : GOTO 10

The methods of Critical Code Studies are not dependent on large bodies of code or the names of methods and variables contained within it. A code reading can emerge out of even one line of code, using that line not as an end but as an entry point to an exploration of technoculture. Such a reading emerged from a discussion in the first Critical Code Studies Working Group, held online in 2010. In a “code critique” thread, Nick Montfort posted the code for a one-line program written in BASIC for the Commodore 64, one that produces what most people see as a random maze pattern scrolling on the screen. At first, I thought Nick must either be joking or performing a sneaky kind of trolling. “Interpret this!” he seemed to be saying, throwing down the gauntlet.

In this context, the methods of CCS as demonstrated here would not work so well. There were no variables with echoes of natural language, no controversial social context, and no comments. Yet if CCS could not handle this program, I believed, the approach would be proved intellectually bankrupt. The result: a book coauthored by ten people and published by MIT Press (and free to download7) and at least one other journal article. These works tackle many aspects of the code, including the pseudo-randomness of RND, the culture of one-liners, the PETSCII set of characters that makes this concise program possible, along with various cultural contexts such as the place of BASIC, the C64, mazes, and home computing in the early 1980s—all factors that add resonance to this tiny code snippet. Taken together, these projects provide an example of collaborative code reading by scholars with backgrounds in both computer science and the humanities.

One small example might illustrate the kinds of critiques we performed. While writing the book, we authors would often refer to the program as 10 PRINT. But at some point, we began to wonder why the 10 was there at all. Most contemporary programming languages do not use line numbers as BASIC did, yet unless a person was executing BASIC on the command line, she would need to number the lines. Starting with 10 and increasing by 10s was a convention, since it offered the opportunity to add lines before or after any given line. I can remember writing lines 15, 16, 17 of a program and worrying that I had used up all the intervening space.

In other words, while the 10 allows for the program to loop, the 10 itself was an arbitrary designation; it could have been 1 or 15 or 105, or the one-line program could have been written without the line number altogether. The 10, then, becomes a sign of the program’s partiality and potential. 10 PRINT is the first (or 10th) line of a potentially much longer program. This might seem to be a small insight, except that it indicates how all programs are partial and potential components of other programs. Code is not merely a discrete set of instructions and comments but a sign of possibility, akin to Barthes’s distinction between work and text, in which the Text is the infinite field of discourse, but the Work is a particular instantiation, always partial (“From Work to Text”).

Such theorization helps us understand the nature of code as a sign system. It is at once a practical system for programming and a semiotic system for communicating other messages, including possibility and even wit. The one-line BASIC program acted as a hub from which we could explore many spokes of analysis. Our readings did not challenge existing norms with fancy neologisms, nor did we dwell on provocative politics. Instead, we showed how a single line of code could provide access to its history and its hardware, and how a meditation on one line of code could serve as a heuristic for understanding computational culture.

While reading this one-line program might seem to be a conservative act, it in fact liberates code for additional readings. Within the world of computers, we were able to examine the historical moment that made this code so exciting, which included discussions of the platform, the advent of home computing, and the development and spread of BASIC as a relatively accessible programming language. Scholars wrote new code, including ports to other programming languages and a maze-walking program that tested the solvability of the on-screen puzzle. Beyond the realm of computer culture, moreover, we were able to reveal the connections between this influential program and other artistic and artisanal communities, from dance to stitchcraft, where this pattern-making knowledge was also required. To tie the computational artistry of a line of code to the material (but equally procedural) artistry of handicraft is a radical act, one that dissolves a conventionally held separation between digital and analog forms of art and between the modern technology of computers and the ancient technology of needlework. Interpreting this one line of code was not, then, an act of description or documentation, but of creating new and at times unexpected paths to understanding.

Project for Tachistoscope

Critical Code Studies can also reveal aspects of the functioning of a piece of software that are not apparent by observing its output, and consequently, change the way we understand the software itself. For example, in another collaborative book project, written with Jessica Pressman and Jeremy Douglass, I employ the methods of Critical Code Studies to interpret a work of electronic literature, “Project for Tachistoscope [Bottomless Pit]”8 by William Poundstone. “Project” is a work of Flash animation that presents the story of a massive crater that has opened up near a highway construction project. The story describes this inexplicable fathomless pit, the people who try to interpret it, and the community that must grapple with it. The interface of Poundstone’s project presents a noisy, pulsating swirl of color and images that make it difficult to understand the story, which is displayed to the reader one word at a time.9

The piece itself remediates the notion of a tachistoscope—a category of devices that typically display a single image for a short amount of time—by flashing additional words at the reader between the words of the story. Although these words appear too quickly to be fully comprehended, the reader can detect their presence, since the words of the story are displayed in black while these others are displayed in white.

We caught our first snapshots of these words when Jeremy created a sequence of screenshots of the piece. To discover what these words might be, we then used a Flash decompiler to access the Flash source file (.fla). Flash files must be compiled—or converted from source code to a machine-readable format—before they can be embedded in web pages or otherwise viewed. A Flash decompiler allows that viewer to examine the underlying source code by creating a functionally equivalent version of the original code. In other words, the resultant code is actually a re-creation generated by the decompiler, although images and sound files pass through unchanged. Thus the decompiled code is a kind of translation of the source file, lacking the specific programming choices of the original source file. The resulting code cannot be read as closely, since it does not contain the exact signs used by the programmer. Because of this limitation, we ultimately asked Poundstone to share with us the .fla file used to create the piece.10

While we had some sense of the subliminal words flashing on the screen before looking at the code, they remained unreadable. We assumed that they were being randomly selected to appear in the work at a random interval, based on the fact that the same words did not appear in the same place or order every time the work was executed. On inspecting the code, however, we discovered something unexpected: the words were not displaying on the screen at random intervals; instead, they were flashing continuously. What was random was when those words would appear in white and hence be more detectable to the human eye. Moreover, the words were not being presented in a random order but in the exact same order each time. The work, as it turned out, displayed a perpetual alternation between words: first a subliminal word (in black or white), then a story word.

This discovery completely changed the way we had been interpreting the work. Rather than seeing this work as the product of random combinatorics, we realized that the list of subliminal words was hand-curated—that is, the list was created knowing when each word would appear in relation to the story words, at least on the first pass through the piece.11 With access to the Flash source file (.fla), we discovered that the subliminal words always appeared in white, their most noticeable form, during an animation sequence entitled “fixation crosses,” in which four white crosses flutter by in four ordinal directions (NW, NE, SW, SE). These fixation crosses, we hypothesized, prepped the eye to notice the white text. That suggestive name “fixation crosses,” with echoes in optometry and cognitive science, would not have been available for interpretation without access to the code.

While the name “fixation crosses” is arbitrary, the ways in which the subliminal words are displayed is not. The name is “arbitrary” in the sense that its choice is not significant to the way the code is processed. But the arbitrary and the procedural both become significant when placed against this tale of, among other things, an indeterminate sign. The “Pit” of the story is a signifier whose signified cannot be determined, one that destabilizes every effort to measure it. Although neither the code nor the Flash file represent the “bottom” of the Pit, they do give us access to layers of signification of this work that the author/programmer fashioned while creating this piece.

At the level of the code, the work of the digital humanist is to interpret the significance of these particular choices against the paradigm of possible choices and within the context of their social and material traces. The danger is to pretend that the code “just works”—that the code’s construction lacks intention and, therefore, that we can avoid interpretation. Choices are made throughout the process of programming—choices made by people in complex social situations —and those choices are informed by a perspective on the world and will impact the world. This impact is registered not only explicitly, as in the case of code that models terrorist movements or climate change, but also subtly, as it communicates ideas and worldviews to those who read it. Humanists reading code are doing more than merely changing their own oil; they are learning the hieroglyphic systems that are the lingua franca of the digital age. Their ability to trace and explicate meaning will enhance the understanding of code and identify the messages encoded in each program.

The future of Critical Code Studies is married to the future of the digital humanities, even if both decide to change their names (again) down the road. That future will depend on the ability of those developing computational technology and those interpreting it to communicate with one another in a way that is, if not amicable, at least symbiotic. The two-worlds model may be encoded into many parts of our cultural self-portraits, yet we cannot let the suspicions and sarcasm completely derail efforts toward shared inquiry.

Notes

Bibliography