Ben Allen
Patsy Baudoin
Sandy Baldwin
John Bell
Paul Benzon
David M. Berry
Michael Black
Stephanie Boluk
Philippe Bootz
Mez Breeze
Kevin Brock
James J. Brown, Jr.
Evan Buswell
micha cardenas
Hugh Cayless
David M. Cecchetto
Scott Dexter
Craig Dietrich
Jeremy Douglass
Kevin Driscoll
Max Feinstein
Paul Fishwick
Leonardo Flores
Federica Frabetti
Alex Gil
Matthew K. Gold
Kevin Gotkin
Wayne Graham
Fox Harrell
Brendan Howell
Dennis Jerz
Steve Klabnik
Inés Laitano
Clarissa Lee
Garrison LeMasters
Patrick Lemieux
Jason Lipshin
Elizabeth Losh
Judy Malloy
Mark C. Marino
David M. McClure
Richard Mehlinger
Julie Meloni
Todd Millstein
Jarah Moesch
Nick Montfort
Lisa Nakamura
Jacob Peters
Jessica Pressman
Rita Raley
Stephen Ramsay
Amit Ray
Casey Reas
Aaron A. Reed
Daniel Rehn
David M Rieder
Ben Robertson
Eric Rochester
Julie Levin Russo
Warren Sack
Laila Shereen Sakr
Mark Sample
Braxton Soderman
Frances Van Scoy
Annette Vee
Timothy J. Welsh
Zach Whalen
Roger Whitson
Mark Wolff
Jichen Zhu
Gregory Zobel

Poet Amy Sara Carroll of the Electronic Disturbance Theater said something quite provocative and evocative via Skype during a discussion of the patently provocative Transborder Immigrant Tool (TBT) at USC last Friday.  Actually it wasn’t something she said but a combination of statements that has set my mind into this thread.

First, she said that she had told (Poet) Brett Stalbaum that the code was the poetry of the project (despite the fact that she has written a set of texts called “poems” that are embeded in the project).

Second, she talked about a lack of understanding of conceptualism in various discourse communities (though I need to go back to the video to see which ones).

Conceptualism.  Conceptual Writing.  

These words stuck with me (and I realize I am late to this particular party).  What if the code were poetic not primarily because it possessed semiotic patterns that mirrored and reflected those of conventional poetry, as in the case of some codework, but because it is conceptual writing?  

A little background in case Wikipedia is down (and excuse the abysmally hasty gloss): Conceptual Writing is a genre formally introduced by Craig Dworkin in 2003, which builds upon a tradition of “non-expressive poetry” and notions from Kenneth Goldsmith.  As Dworkin writes in the intro to UBUWEB:

But what would a non-expressive poetry look like? A poetry of intellect rather than emotion? One in which the substitutions at the heart of metaphor and image were replaced by the direct presentation of language itself, with “spontaneous overflow” supplanted by meticulous procedure and exhaustively logical process?

I’ll stop the quote there, as the hyphora seems to be pointing straight at such code as that in TBT.

For a while now, I’ve been trying to understand how code can be posited (by its authors) as poetry  – beyond the realms of the intentional poetic play of coding genres such as Perl Poetry or, again, the cool creole of mesangelle.  Conceptual writing may be a main answer.

But certain questions persist.  Is the code become conceptual poetry merely by being framed as such? And more troubling: Could any code be taken as conceptual writing?  (Campbell’s soup cans all art now, of course.)

In the midst of these open musings, I am also a bit concerned about clouding the discussions about code in general in the broader work of Critical Code Studies.  (These 500 or so words will no doubt mean that someone will have to write 50,000 words to contextualize these comments and tamper their side effects.)

But as I pour through the code of The Transborder Immigrant Tool and think through the place of code written by artists within artistic projects, projects with aesthetic goals in mind, I think I have just had an ah-ha moment.

Photo Credit: Kinsee Morlan

When I approach programmers about interpreting their code, a wry smile loads on their lips. After a bit of discussion, it becomes clear that they expect me to read their code as a high school English class would read a poem by Keats or a sonnet by Shakespeare. The smile also reveals their own ambivalence about their code.

On the one hand, they tend to dislike their code, feel a certain degree of shame about functions patched together or inelegantly assembled under severe time constraints. On the other hand, they are bemused that I would try to understand them through their code, like one reading their tea leaves or espresso grinds. However, Critical Code Studies does not have to map the mind of the inspired computer programmer. Some may pursue that tack, but the study of code does not depend on such speculation. In fact, this image of interpretation marks a moment of miscommunication between humanities scholars and computer scientists.

Interpretation is a sticky word in CCS. It means totally different things to programmers and humanities scholars. For computer scientists, interpreters are the programs that execute the high level code and interpretation allows the program to run. For the humanities, interpreters are all scholars and interpretation is a way of producing meaning about a text. Even in the English class, I would argue, interpretation isn’t what it used to be.

Interpretation, at the start of the twenty-first century, is not that search for what the author secretly meant, that bizarre scavenger hunt that computer scientists probably recall from their Ms. Finetooth’s midterm essay questions. Instead, it is the systematic exploration of semiotic objects in order to explore culture and systems of meaning. The subtle difference is that while many scholars still focus their attention on specific sets of authors, authorial intent is and a single absolute meaning are not the ends of interpretation. Rather the cultural object becomes an opportunity to talk about something else. Just what that “something else” is depends on the disposition of the scholar, though the topic should be deeply tied to the work itself.

The shift from the quest for the hidden meaning of the romantic author to the use of the object as a cultural text for exploring systems of meaning and culture is largely the result of the influence of semiotics and Cultural Studies, the field that grew from the Birmingham school and Stuart Hall. Semiotics, or the study of signs and signification, opens up the interpretive process to examine all systems of information and meaning, what some might call communication, though that term is perhaps too strongly associated with another disciplinary disposition. Unlike literary studies which tends to focus on the artistically rendered collection of words (or performed text), Cultural Studies examines every object as a text for study.

The distance between the Haiku and the can of Coca Cola as texts marks the shift between the study of artistry and the broader study of signification. The Cultural Studies scholar does not ask what the Coca Cola Corporation intended by choosing red for the color of its cans and logo or what meaning it hi in the signature-style of the words on the can. Instead, she performs a semiotic analysis on the possible meanings conveyed by those details (the color red, the cursive script) of the can in the contexts of the many surrounding sign systems and discusses what the can and, by extension the company, have come to signify.

In some ways, this type of analysis reverses the process by which the can of Coke came to be, as it was designed by artists quite likely with feedback from other corporate executives in consultation with focus groups and consultants. At this point, one might note that the can is an object of commercial exchange. That aspect too becomes part of the cultural analysis. Would the critic have any less to say about a cultural artifact that had a less purposeful marketing purpose, like a user’s manual or a recipe in a cooking magazine? Probably not, but a reading of that text would require putting it in the context in which it is communicating: manuals, recipes, cooking culture.

So what is culture? Recently, I had a discussion with a scientist about Critical Code Studies, and I raised this notion of coding culture. He mentioned the high number of Indian programmers working in this particular part of the country and suggest I speak with them about the way their cultural background appears in code. While that inquiry would no doubt lead to some interesting investigations, his suggestion revealed something to me: for him, “culture” largely signified “ethnic culture.”

When a humanities scholar evokes “culture” she is typically referring to any social sphere, from particular workplaces to activities (skater culture, knitting culture), from regions of the world to virtual worlds (World of Warcraft), from realms of production and commerce to realms of scientific and academic inquiry. In programming, these cultures emerge around coding paradigms, languages, roles, and specializations just as much as they emerge from work environments, labs, and schools of thought. All of these cultures, or subcultures, possess rituals, discourse conventions, meeting grounds, et cetera. As a result, any artifact, object, or text, offers a glimpse or imprint of the culture in which it was produced and circulated.

This interpretation of a code as a cultural text, therefore, grows out of a very different analysis than the close examination of a lyric poem that seeks to answer some riddle hidden in the text by the author. In this context, even that poem is a cultural text whose meaning emerges not from a teasing author but from its engagement with systems of meaning (lyric poems, poetry in general, the literary tradition, the English language), cultural contexts, and the implicit associations of its readers based on their expectations and reading habits.

By this definition, both humanities scholars and computer scientists should be able to much more easily begin to interpret code together — or to use code as a starting text for discussing other aspects of culture and in that process come to a fuller understanding of both the texts and its contexts.

The Humanities and Critical Code Studies Lab is the first university space to pursue the exploration of the interpretation of computer source code using the methodologies of Critical Code Studies. Based at the University of Southern California, the HaCCS Lab will promote the development of critical vocabulary, case studies, and cross-disciplinary dialogue, specifically between the humanities and computer science.

According to the essay that initiated the field, Critical Code Studies is the application of humanities hermeneutics to the interpretation of the extra-functional significance of computer source code. Examining digital objects primarily through the lens of the code, Critical Code Studies explores the rhetoric, material history, style, and culture of code — aspects that have previously been only marginally discussed in computer science courses and scholarship. In this way, CCS offers to bridge computer science with scholars in the areas of letters by opening up discussions about the implications of the source code that directs so much of contemporary life. CCS extends the pursuit of code analysis beyond what the code does to ask what the particular configuration of signs means for the culture at large.

USC has been at the center of Critical Code Studies since its inception in 2006. It held the first conference in Critical Code Studies and facilitated the 2010 Critical Code Studies Working Group. The proceedings from the first conference appear in USC-based Vectors journal. Although CCS is a discipline that is spreading across the country as well as internationally, the founding of the lab at USC will help to foster the development of code scholarship at an institution that has played such a pivotal role.

The HaCCS Lab has been established to serve as a resource for scholars embarking on critical code studies, by building bibliographies, directing research, and pursuing grants for the development of the field. It will promote the learning of programming languages and coding paradigms by humanities scholars as well as the “translation” of humanities hermeneutics into the conceptual paradigms of computer science. The Lab will also work to articulate Critical Code Studies with the related fields of Software Studies, Platform Studies, and Media Forensics.

The HaCCS Lab will promote dialogue by organizing conferences and symposia that bring together computer science and humanities researchers in order to establish a common vocabulary.

The HaCCS coordinates its efforts with a variety of campus units, including:

• The Institute for Multimedia Literacy
• The Center for Scholarly Technology
• The Center for Transformative Scholarship

HaCCS Lab Members & Affiliates:
Mark Marino, Director, USC
Tara McPherson, Senior Research Associate, USC
Craig Dietrich, Senior Research Associate, USC
micha cárdenas, PhD Candidate, USC
Laila Shereen Sakr, PhD Candidate, USC
Max Feinstein, Research Affiliate, Harvard/USC

Affiliated Researchers:
Sandy Baldwin, Senior Research Affiliate, West Virginia U
David M. Berry, Senior Research Affiliate, Swansea University
Wendy Hui Kyong Chun, Senior Research Affiliate, Brown
Federica Frabetti, Senior Research Affiliate, Oxford Brookes U
Dennis Jerz, Senior Research Affiliate, Seton Hill
Elizabeth Losh, Senior Research Affiliate, UC San Diego
Mark Sample, Senior Research Affiliate, George Mason
Stephanie Boluk, Postdoctoral Affiliate, Vassar
Evan Buswell, PhD Candidate, UC Davis
Patrick LeMieux, PhD Candidate, Duke

International Advisory Board
Philippe Bootz, University of Paris 8
Cathy N. Davidson, Duke
Jeremy Douglass, UCSD
Matthew Fuller, Goldsmiths, U of London
N. Katherine Hayles, Duke
Pierre Lévy, University of Ottowa
Jessica Pressman, Yale
Rita Raley, UC Santa Barbara
Steven Ramsay, U Nebraska – Lincoln

Affiliated Labs:
Archeological Media Lab (AML), UC Boulder
Center for Transformative Scholarship, USC
GreaterThanGames, Franklin Humanities Institute, Duke
Humanities, Arts, Science, and Technology Advanced Collaboratory (HASTAC)
Maryland Institute for Technology in the Humanities (MITH), UM
Paragraphe Laboratory, University of Paris 8
Transcriptions, UC Santa Barbara
centerNet: international network of digital humanities centers

Find the proceedings at: http://vectorsjournal.org/thoughtmesh/critcode

You’ll notice that the proceedings were published on a unique platform called Thoughtmesh, which was developed by USC’s Vectors journal and presenter Craig Dietrich in particular. Thoughtmesh was chosen for its ability to present and connect publications in much the same way that you’d expect from a live conference. I’m particularly excited about the Peer Review feature, which allows users to create conversation in and around the papers on the site.

I encourage you to explore the proceedings and continue the CCS conversation in the Peer Review area on Thoughtmesh. Happy meshing!

Here are the slide in .pdf form: Transborder Immigrant Tool Talk MLA. Below I offer a few notions from the presentation and an extension of the conversation. I welcome suggestions particularly on characterizing the java.

You Say T.B.T., I say T.I.T.

Critics of CCS (not the practitioners but the skeptical) argue that CCS deals with the “arbitrary” or insignificant aspects of code, such as variable names or even comments. This point is nicely media-specific, attentive to the difference between source code and other sign systems; however, it misses a few key points. First, these aspects are only 2 of the elements CCS interrogates. Second, this notion of “arbitrary” while accurately characterizing the nature of the signs in one dimension of their existence neglects a very important human dimension, one that gave rise to the MLA itself.

This sense of these choices as “arbitrary” comes from a very literal application of that term, “arbitary” from the POV of the computer, a POV programmers perhaps try to take on as they imagine how their code is being processed. To not acknowledge it would be to ignore a core tenet of programming. It is important to acknowledge that a variable called ofGrammatology could just as easily be called sZ. However, the difference between these two names speaks, well, volumes. This dismissal of the “arbitrary” short circuits interpretation by denying the discussion of the natural language affinities of the code for the programmer and anyone else who reads it (see Jeremy Douglass’ Week 2 of the CCSWG — forthcoming in electronic book review).

During our panel, the three presenters and two chairs, started calling each other (and ourselves) by different names. Some laughed at this play; others groaned. (See the Twitter chatter). Another cohort were just confused because they neither knew us by sight nor the owners of the names we were invoking. As with many (every?) instance of naming, those who knew their relevance experienced the interplay completely differently from those who did not know them. Nonetheless, just because one part of the audience did not know their significance of the names did not make their value arbitrary — arbitrary in that other sense, implying that the nature of their selection was without (intended) significance or purpose. The panelists referenced the names “Ian” and “Nick.” While an outsider reporting on the scene (or someone who was not aware of the meaning of these names) might waste a little time arguing that we meant “Ian McKellen” or “Ian Somerhalder,” he or she could still, without knowing their intended reference, correctly note the predominance of male names (on the panel and in the play) and might have begun to question the gender dynamics/imbalance/inequity of either the game or this particular group of presenters. Of course, that doesn’t mean the person shouldn’t ask, “Hey, who’s Ian?”

As a scholar who examines language and semiotics, I deal in the analysis of arbitrary choices from a paradigm within the context of a syntagm adhering to a langue, to borrow some terms from semiotics. As a scholar of code, code that is processed by computers but read by humans, I see significance in the way the signs appear. However, since higher level computer languages have so many natural language affinities, the significance reverberates across multiple registers. When I read code, my goal is first to find out what the code does. My favorite way to read it, though, is with someone intimately connected with the project, though unaffiliated programmers offer interesting insights. As we trace through the code, I listen for reactions that are unconnected to the function of the code. If the unaffiliated programmer laughs at a line of code, like a foreigner, I ask them to explain what they were laughing at. In their laughter, I find something else that is being communicated through that code. Just to offer one example.

At MLA 2011, I applied CCS to the Transborder Immigrant Tool. Interestingly many news accounts of the Transborder Immigrant Tool refer to it under the initials TBT. I find this acronym to be highly unlikely and that its use, like much of the project, calls attention (with ironic force) to one of the themes of the project as it attempts to sustain life at the most fundamental level, as it reaches toward material not digital connection, not hegemonic power to subjugated, mother and infant, not satellite and receiver, but knowing branch and hidden water.

T.I.T. is a mobile phone application that helps border-crossers who are in danger of dehydration find caches of water as they cross from Mexico to the United States. Along their journey it also provides them with poetry, that contains within it additional hints for survival along with the sustaining force of its prose. The tool has been the subject of media coverage which stirred up a bit of reader fury, leading ultimately to a UC investigation of the project’s directors, Ricardo Dominguez,

though investigating for his previous work with the Electronic Disturbance Theater, work that earned him tenure in the same system, btw.

The team includes Micha Cárdenas, Amy Sara Carroll, Elle Mehrmand , and Brett Stalbaum (who wrote and has posted the code openly), an eclectic group of artists and activists who collaborate in the collectives, b.a.n.g. lab and Electronic Disturbance Theater.

What do you get when you look at the code?

My own path through the code narrates the potential experiences of border crossers. Walking through it with others helps me imagine the border issue from a different perspective. This may have pedagogical implications but also theoretical implications on how we make sense of code — how we narrate effects of the code as we read through it. As Brett Stalbaum walked me through the code, I had to construct a mental model of the potential user, their dehyrdration, their response to the tool and its signals, and the user’s search for water.

The code is java drawing on Java2ME libraries to be used on a Nokia IDEN platform. Java being open source serves well. In my presentation, I mentioned that I was given pause to think of JAVA developed by SUN now a part of ORACLE. This lead me to one of my more contentious, though at MLA fairly conventional, moves of CCS where I pause to reflect on the allusions within those names — thinking about framing metaphors, George Lakoff, et cetera. Their choice of Java stems from the mobile-phone platform they chose in order to keep the cost of T.I.T. as low as possible.

JAVA relies on a particular naming convention that comes from the folder structure of the piece. In the case of importing classes, the convention is to set up the folders so that the namespace location is the reverse of the domain name. As a result, the domains get written into the code, but those are no arbitrary signifiers.

import net.walkingtools.javame.util.AudioArrayPlayer;


So in the case of “import edu.ucsd.calit2.TransBorderTool.international.*;” The program will import all of the types (signified by the wildcard *) of the international folder in edu->uscsd->calit2->TransborderTool where the -> represents the folder structure.

These types carry with them the hierarchical (in terms of organization but also affiliation) structures from which they originate.

Compare
import edu.ucsd.calit2.TransborderTool;
with
import net.walkingtools.javame.util.AudioArrayPlayer;

The institutions are thus literally written into the code: UCSD, JAVA, WalkingTools. UCSD, the institution that both tenured and investigated Ricardo is here. Sun is also here in the Java library, though Java’s open source life is perhaps more relevant to the ethos of the project. The last source, WalkingTools.net, however, is a separate library, also developed by Stalbaum and others. It does not live under the flag of UCSD or CalIT2. Importing from this source, marks the conscious choice of the designers to build and implement a separate library outside of the UC institutional infrastructure.

Dowsing & Witching

Here is a 21st century phone application. It uses GPS and modern day, though inexpensive hardware. It calculates distances based on maps downloaded into these phones before deployment. And yet the code frames itself not in this GPS narrative but within another paradigm: dowsing. That metaphor is written into the code — or perhaps the source code is encoded with the metaphor.

When the widget discovers a water cache within range it calls a function in the following line:

dowsingListener.witchingEvent (mc);

Here is more of the context:

It calls the witchingEvent function that is part of the dowsingListener class. (Although this gets a bit more complicated through the use of an interface I will discuss later.) That central function plays the alerts and presents visuals on the display to lead the dehydrated traveler to water. So here, at its core, the discovery of water nearby is framed as “witching,” a witching that it has been listening for. Dowsing and witching appear throughout the lines of code: in the names of files, variables, and interfaces. Nonetheless, the programmers had to work to make this line read as it did. A small example is that the variable dowsingListener is assigned the dowsingCompassListener, shortening the name, removing the compass metaphor from the expression in the code.

Dowsing and witching have been written into the code. “Witching” is dowsing or divining water using a stick of witch hazel. So those who are interacting with these lines of code, as they are working their way through the desert of the IDEN platform, are thinking about map coordinates through the metaphor of dowsing, a practice that puts nature in quest of nature, the stick, the wood, the plant that knows where the water is, it feels it in its bones. A return to the paradigm brings all of the other metaphors that could be used in the code here: detection, identification, discovery, completion, mining, scoping, harvesting, pinpointing… not to mention the (infinite) range of nonsense or completely un-related character combinations that could have been used. Nonetheless, this code has been written with reference to a conceptual framework of a magical folk practice, where nature is called to nature, the dead stick is drawn to the water that would have saved it, depending, of course, on one’s view of dowsing….

In many cases, we have the software without access to the code, but since this software is installed only on the phones of those who are building the software or making this perilous trek, reading the code is a primary way of giving people the experience of the software.

Q & A
Matt Kirschenbaum served as the respondent to the panel and he raised a few points that I’d like to address here.

• CCS should not take code as the ultimate ends. This point came up in CCSWG and is best addressed IMHO in Wendy Chun’s forthcoming book. There are other layers of the code, the code is compiled into something else, the code is just an abstraction. All of these concerns should be taken into consideration when discussing code.
• CCS should not take code separate from the system, the hardware. And this tied in well with a concern from Richard Grusin that we not talk about the code separate from its effects. Certainly, we do not want to consider the code as a standalone object, yet that does not mean we should not look very closely at the code itself. Keep in mind that CCS picks up where discussions of the processes and systems leave off.

For my part, I may seem to be focusing exclusively, but really primarily, on the code because I know there are other scholars working on ways of reading hardware and software, though in my longer explorations I try not to omit these aspects. I am in search of ways of reading source code because I have not found many models. Fortunately, the CCS Working Group and the forthcoming HASTAC Scholars forum have brought together incredible talents to tackle these questions and their code critiques generating more ways of reading and more code critiques.

Richard Grusin also expressed concern that my reading was “New Critical.” I replied that by taking into account the social context in which the code was created, distributed, and functioned, my reading could not be aligned with the closed or blindered approaches of the New Critics.

However, as you can see above, one of my goals is to see the meaning that is layered onto code, and we can learn a lot about “close reading” from the New Critics that to me is intimately tied to the act of deconstruction as well. So my readings rarely stop at what the thing does but instead ask how does the way this code is written, how do these paradigmatic choices within the langue of the language, operating system, hardware, and other constraints, layer meaning upon the code which resonates with or is perhaps intention with the way that it operates. (We discussed this inside/outside or means/ends, form/structure tension in the CCSWG.) In that way, I do spend a good deal of time looking closely at the signs, not to be a Scuttle parodied by a Sokal, but to look closely for resonance, a resonance I have been trained to find when I close read sign systems of all sorts, be they textual, visual, haptic, ludic, legal…

[p.s.]
During Q&A I mentioned that CCS is often like photography. The photographer might capture the chance pairing, the wrinkled hand on the arch, the sleeves of the homeless indigenous woman on the steps of the embassy. Photography notices, it finds as Mark Sample mentioned (referencing Barthes) a punctum even when the standard way of framing that vista might have missed it. In CCS we do a lot of reframing, and that often involves putting that code in context of its circulation and creation.

(I have to stop here as this is rapidly increasing into a much longer project. Should be sufficient content for discussion here. )

I have also cross-posted this at my own blog, Clinamen.

Close Reading Campaign Rhetorics: Procedurality and MyBarackObama.com

It is now commonplace to argue that the Internet has fundamentally changed the nature of political campaigning. The Howard Dean, George W. Bush, and Barack Obama campaigns have shown us how fundraising, “Get Out the Vote” activities, and volunteer mobilization all change significantly when certain new media technologies are deployed. But in addition to providing easier ways to connect and communicate, these technologies enable campaigns to make arguments in novel ways.

This presentation examines the Obama campaign in terms of what Ian Bogost calls procedural rhetorics. Software enacts procedures. In addition to presenting text, sound, and video (say, the brochure-like material often presented on candidate websites or campaign commercials), software involves the crafting of computational procedures. And as we will see, the authoring of procedures is not confined to software. While one of my focuses will be the Obama campaign’s social networking software, MyBarackObama.com (hereafter referred to by its popular shortened name: “MyBO”), we can also locate procedural arguments in the phone-banking scripts that the campaign provided to volunteers.

Some of the procedural arguments I locate are not in line with the strategic narratives presented by the Obama campaign, but it is not my aim to play a game of rhetorical “gotcha.” Rather, I hope that this presentation can show how the analysis of text, sound, and image can be usefully supplemented by an analysis of procedurality. Further, understanding procedural rhetorics offers citizens one route to a more meaningful engagement with software.

Procedurality and Campaigning

Bogost develops his theory of procedural rhetoric in Persuasive Games. He argues that videogames use procedural expression to make arguments; gamers interact with those arguments and are asked to make decisions. Immersed in a model of a world, we are asked to embody characters and learn how the model works. But in his discussion of political videogames, Bogost argues that most political games fail to tap the affordances of procedural expression. Rather than making it possible for players to “embody political positions and engage in political actions that many will never have previously experienced,” most contemporary political games are little more than gimmicks (135). In an attempt to more effectively use procedural expression, Bogost teamed up with Gonzalo Frasca to design a videogame for the Howard Dean campaign. Players of the game were tasked with recruiting volunteers and distributing campaign literature, just as they would as volunteers for the Dean campaign.

While the game succeeded in making an argument about grassroots activism, Bogost explains that “it inadvertently exposed the underlying ideology of the campaign” (139). That ideology was, in the words of one critic of the game, more about the numbers game of Get-Out-The-Vote activities and “handing out leaflets” than about Dean’s policy positions: “I have to believe there’s more difference between any two candidates than the image on the front of a brochure or the name on a sign…If handing out leaflets for Dean is the same thing as handing out leaflets for Kucinich, why should I vote for either of them?” (139).

MyBarackObama.com

While my own discussion here does not examine videogames, it does locate procedural arguments in the “MyBO” social networking software and the campaign’s phone banking scripts. Much like the Howard Dean game, the procedural rhetorics of the Obama campaign “inadvertently exposed the underlying ideology of the campaign.” During the campaign, the MyBO user’s home page featured a point system.

In an August 2007 blog post, Chris Hughes (a founder of Facebook who left the company to work for the Obama campaign) explained the points system: “Just about every action you can take on My.BarackObama now will give you points to make it easier to see all the hard work you’re putting in to make this campaign succeed.” (Hughes). By assigning higher values to particular activities and by publishing a list of those with the highest point totals, the campaign made procedural arguments about which campaign activities were most important. This point system led game designer Gene Koo to call MyBO “one of the most important game titles of 2008.” But Koo also pointed out that the game was far from perfect and that it tended to reward certain kinds of activities while devaluing others. He explains that his own volunteer efforts involved driving to South Carolina and working “in the trenches,” and such activities were not accounted for by the site’s point system (Koo).

The point system was scrapped in favor of the “Activity Tracker” in August 2008 (this was upsetting to some of the point leaders). The Activity Tracker provided a 1-10 scale that reflected not only the volunteer’s number of activities but also how recently she had contributed her efforts. While the first iteration of the point system was purely cumulative, the new system made a different procedural argument by continually asking: “What have you done for me lately?” Sustained activity kept the index at 10, but a slow week of volunteer efforts would mean a drop in that number.

Phone Banking: The Procedural Rhetoric of a Script

If we were to convert an Obama campaign phone banking script to PHP programming code, it might look something like this:

This code is fictional in a number of ways. For one, it’s not operational. There are some statements missing, and we would need to create some additional files in order to make this code run. But my main purpose in including this little bit of fictional PHP code is to demonstrate that both the Obama campaign’s software and its phone banking scripts make procedural arguments.

Further, I want to show that the answer to the question that opens this procedure—“Who do you plan on supporting in the upcoming election?”— instantly determines how long the call will last and how involved the conversation will be. If the potential voter indicates that s/he is a John McCain or Hillary Clinton supporter, the call may very well be over. The campaign volunteer is instructed to thank the person for their time and hang up the phone. If the potential voter is a strong Obama supporter, the procedure continues through a series of if-then statements. The caller asks questions, provides information about absentee ballots or polling locations, and sometimes even recruits a new volunteer. Many (not all—some scripts were more involved) of the scripts provided by the campaign offered few instructions for how one might persuade a McCain or Clinton supporter to change his or her mind.

But Obama volunteers were not computers, and they didn’t just run the campaign’s code. Rather, they authored their own procedures. For instance, one volunteer experimented with a change to his script by adding arguments about Obama’s experience (recent soundbytes had featured disagreements between the candidates about who was more experienced). Upon doing this, he found that women were not persuaded by the argument:

I wondered if it was the new line [about Obama’s experience]? So I tried calls without it. I replaced it by saying that ‘I’m spending my time reaching out to my neighbors on Obama’s behalf because I believe that he’s the only candidate running in either party who can genuinely bring us together to get things done at home and abroad. I’m calling because I believe in him[.]’ It was a total 180. Suddenly, the women I [talked to] weren’t hanging up on me, and some were asking ‘why do you say that?’ Boom. I was in. (Hussein)

This volunteer crafted his own if-then statements and worked through a new procedure, and he also shared his script with other volunteers on the MyBO website. The Obama phone banking script is not evidence that the campaign was programming its volunteers. Instead, it is evidence that volunteers engaged with the campaign’s procedural arguments by editing, revising, and extending them.

Cultivating Procedural Literacy

The Obama campaign often relied on two key narratives. The first was that President Obama would engage opposing arguments. During a debate sponsored by CNN and YouTube, candidate Obama said that he would be willing to meet with leaders of Iran, Syria, Venezuela, Cuba, and North Korea without precondition. Obama also expressed admiration for Doris Kearns Goodwin’s book Team of Rivals, which details how President Lincoln filled his cabinet with people who had run against him. And Obama did nominate one of his most fierce rivals, Hillary Clinton, to the post of Secretary of State. The campaign’s second key argument was that Obama campaign volunteers were part of a peer-to-peer network of community organizers. The “Yes, we can” mantra of the campaign made the argument that the campaign was a purely grass roots movement.

But a closer look at some of procedural arguments made during the Democratic primary and the general election reveals a more complex and sometimes contradictory stance. The procedural argument of many phone-banking scripts encouraged volunteers to bow out of agonistic exchange with supporters of McCain and Clinton. This argument runs counter to much of the campaign’s rhetoric about conversing with enemies or foes. In addition, we have seen that the MyBO software’s procedural arguments reveal a delicate dance between hierarchical control and peer-to-peer interaction. While the campaign spent a great deal of time describing volunteer efforts as peer-to-peer activities, it also exerted control from the center.

A closer look at the procedural arguments mounted by the MyBO campaign allows us a full picture of the campaign’s arguments and motives, and these conflicting arguments indicate that a deeper understanding of procedural rhetoric offers ways to understand all types of arguments, political and otherwise. Further, users can both interact with and author procedural arguments. This discussion of procedural rhetoric signals the importance of developing critical software literacies. Procedurality opens up new possibilities for persuasion and expression, and this invites us to think carefully about software as it becomes simultaneously ubiquitous and invisible.

For six weeks last Spring, over 100 scholars from around the world convened to discuss many facets of Critical Code Studies — for example, how do we read code? What code is worth reading? These and myriad other questions were flushed out in six weekly discussions, each kicked off by different presenters offering unique perspectives on humanities-style interpretation of computer code. Now ebr is publishing the main discussion threads. While it may be too late to join that original group, you can catch up on and react to the exchanges that took place at that foundational online meeting.

The Working Group’s opening remarks and an introduction to the first week’s presentation were provided by the organizer Mark Marino. Working Group members received Marino’s presentation with a volley of illuminating discussions, all of which can be found in the ebr publication. Proceedings from the five other weeks will continue to be posted on ebr over the next few months.

Join us at here at the Critical Code Studies blog to discuss and extend those productive and provocative exchanges.

Critical Code Studies @ USC
July 23, 2010
Hosted by The Center for Transformative Scholarship & The Institute for Multimedia Literacy
Keynote: Wendy Hui Kyong Chun, Brown University