Annotations | Marino, "Critical Code Studies"

[ NB: "Annotations" are occasional posts that explore selections from my research reading—articles or books—in rhetoric, technical and professional communication, and related fields. ]

Marino, M. (2006). Critical code studies. Electronic Book Review.

This piece is a hallmark of the critical code studies movement; I believe that I first heard of this article at the CCCC conference in 2011, and I've finally taken some time to give the piece a read. It is important to note that Marino calls this a "proposal" in the penultimate section of the article, so I think it's fair to allow two caveats: first, since this was early days for critical code studies, it's important to keep in mind that some of these ideas needed room to develop (in other words, I don't want to blithely assume that this iteration of CCS is in any way equivalent to today's iteration of CCS; at the same time, this iteration is often seen as foundational); and second, Marino is clearly writing from the disciplinary perspective of literary studies, while I am responding to this work from outside that perspective.

Marino's brief introduction raises some thoughtful questions about an ontology of code and our relationship to programming languages as something more than executable files. Indeed, he notes that to "critique code merely for its functionality or aesthetics is to approach code with only a small portion of our analytic tools" (para. 4). His final question (and final sentence) of his introduction asks: "What would happen if we began to interpret the meaning of the code?" (para. 4).

In the section that follows, "Making the Code the Text," I become disheartened by what seems to be Marino's invocation of the standard literary paradigm for textualizing and then interpreting a given artifact, in this case code. However, my mind is open to the CCS approach, and this section is largely given over to reviewing previous work by individuals who have taken an academic or critical interest in programming languages and executables—Raley (2007), Cayley (2002), Cramer (2005), et al. Marino unpacks Cramer's (2005) expansive definition of software, a definition I resist since it seems to be formulated by a literary critic as opposed to a software engineer—a definition, perhaps, that allows said literary critic the latitude to fold an array of technical artifacts under the rubric of hermeneutics. Marino rejects Cramer's definition, suggesting that it "directs the discussion away from the direct analysis of specific source code" (para. 14).

Marino then argues that scholars eschew code as metaphorical text and instead suggests that "we begin to analyze and explicate code as a text, as a sign system with its own rhetoric, as verbal communication that possesses significance in excess of its functional utility" (para. 15). The last clause in that sentence prefigures the nugget of the article: a code artifact, however it's designed and whatever it actually does in the world, has some symbolic significance beyond its function. This seems very similar to a standard move in rhetorical criticism, where an artifact such as the Bill of Rights—a legal document with functional utility—is analyzed in a manner similar to what one might do with an exemplary text, such as an epic poem. At root, the artifact is abstracted in some important way from its actual context ("its functional utility") and seen as worthy of study as a stand alone object. From here, the rhetorical critic can apply all manner of clever analytic permutations that largely serve the rhetorical critic. But I'm probably cynical.

In a follow-on sentence, Marino suggests the potential value that humanities scholars might bring to computer science, but his piece seems to rest on the following argument: "I am proposing that we can read and explicate code the way we might explicate a work of literature in a new field of inquiry that I call Critical Code Studies (CCS)" (para. 15). That's precisely what I was afraid of when I first caught wind of critical code studies. Marino goes on to argue that "code itself is a cultural text worthy of analysis and rich with possibilities for interpretation" (para 16). I certainly don't disagree, but since I haven't seen any discussion of methods or methodology, I'm very skeptical that this is simply literary studies' next foray into appropriating and textualizing things for which they can be arbiters of cultural normativity. I also wonder at this point how many computer scientists have read this piece, and what they think.

In his next major section, Marino introduces the reader to CCS and maps out its import and relevance. This section is broken into several subsections, which include headers such as "What Can Be Interpreted?," "Why Study the Paint?," and "Code (most of it) Is Not Poetry." In the first sentence of this section, my growing trepidation is all but confirmed: "Critical Code Studies (CCS) is an approach that applies critical hermeneutics to the interpretation of computer code, program architecture, and documentation within a sociohistorical context" (para. 18). As I read these lines, my mind conjures a vision of early anthropologists visiting "savage" peoples—"we're here to examine your culture and tell the world what it means!" Marino, drawing an analogy to the framework of critical legal studies, claims that CCS will help "explicate meaning in excess of the document's functionality, critiquing more than merely aesthetics and efficiency" (para. 18). Yet we're still left with no discussion of methods or methodology, other than the vaguely hermeneutic methods implied in the phrase "critical hermeneutics," which I resist the urge to simplify as "literary interpretation."

And yet a couple paragraphs later, Marino likens CCS to literary analysis, "an interpretive process rather than an instrumentally proscriptive or solely descriptive process" (para. 20). Basically, in Marino's lit review on code as metaphorical text he distances himself from previous instantiations of code that is written as literature (e.g., Perl Poetry) and instead argues that we take extant code, produced by programmers, and analyze it as text, with a careful understanding of the professional nomenclature of software development (see para. 23, for example). We should, therefore, interpret code because "it is a form of symbolic expression and interaction" (para. 23). A couple paragraphs down, Marino hits on some of the most intriguing aspects of studying programming—the complex sociohistorical infrastructures at work in the everyday production of a given program or project. But rather than prying apart these infrastructures by actually studying how they're held together and enacted (as an ethnographer might), it seems that Marino is interested only in post hoc artifactual interpretation, and that's a methodology that seems to be tightly congruent with literary criticism; same approach, different texts.

In describing what can be interpreted in a CCS framework, Marino argues that "The goal need not be code analysis for code's sake, but analyzing code to better understand programs and the networks of other programs and humans they interact with, organize, represent, manipulate, transform, and otherwise engage" (para. 27). Again, this is a promising site of potential research for scholars in rhetoric and writing studies; one could take an empirical approach to studying these very things! But I fear that instead, CCS will foment new spins on things like intertextuality. Indeed, throughout the article so far, I don't recall that Marino has referred to programming as writing in any meaningful way (he does state that it has its own grammar and rhetoric). For Marino, quite simply, "code is not merely a means or a procedure, it is a text" (para. 33). In the work I've done with software engineers (both novice and expert), I've never once heard a participant refer to his, her, or their collaborative code as a "text," though my participants frequently (and sometimes reverentially) refer to programming as a kind of writing work.

As Marino moves to the next major section of his article, "Current Practitioners of Critical Code Studies," I'm still deeply troubled by the utter lack of discussion regarding methodology and methods. The methodology, it seems, is simply critical hermeneutics. This must be well known to literary scholars, but the methods of effecting critical hermeneutics are nebulous (or simply unspoken) in this piece. We've been given a definition of CCS, and a rationale for the approach. We've been given sample objects of study, and Marino has even provided a brief but nuanced treatment of the complex sociocultural infrastructures within which code may be produced. But how will the CCS researcher actually study code? In this section, Marino notes that "notable readings of code have" already been conducted (para. 41), and it seems that in this statement I am given an answer to the methods question: the CCS researcher learns the nomenclature of the programming he or she wishes to study, performs a close reading of a code artifact, and then tells us what it means (see para. 41; this is not an exaggeration).

Finally, in paragraph 42, we get an oblique reference to programming as writing, as Marino reviews the work of Cayley and Glazier (who cite Hayles). But this is short lived. In his penultimate section, "Cautionary Comments," Marino is right to point out the futility of exploring code without closely attending to "historical, material, [and] social context[s]" (para. 54). Yet his corrective is hollow: he recommends more close readings of artifacts related to coding contexts. In other words, keep doing literary analysis of the things near the thing you want to analyze, but make sure not to get your hands dirty by actually deploying a social scientific methodology to see how people actually act with programming technologies (see Kaptelinin and Nardi, 2006). I see no mention here of an obvious approach: working collaboratively with programmers to better understand their code.

It occured to me this morning that this is a prime example of the hammer/nail paradigm. If you wield a big hammer, everything starts to look like a nail. His final sentence says as much: "Let us make the code the text" (para. 57). This is an approach that's perhaps congruent with mainstays of rhetorical criticism, but few empirical (associational or sociocultural, for example) approaches to rhetoric and writing studies. In short, I don't see what this piece has to offer to researchers in technical and professional communication and writing studies, though I suppose the piece might be attractive to folks doing traditional rhetorical criticism.

Studying the work of software development is exciting and rewarding. In the studies that I've conducted, programming is a fascinating, rich, and extraordinarily complex professional activity. As I've written previously, collaborative work is tremendously important to programming, and writing code is knowledge work. Studying programming as knowledge work is incredibly complex—there's much writing and communicative work that never becomes manifest in either code or documentation, and yet these forms of collaboration would be near impossible to trace by simply performing a "close reading" of "code as text." Take a look at Alistair Cockburn's advice for describing methodologies, for example. This is crucial writing work that supports the production of code, and it's something that will likely only be uncovered by an ethnographer who spends lots and lots of time observing and working with a team of developers. This is where common methods in technical and professional communication shine, but I have serious doubts about a critical code studies approach after reading Marino's article.