Rhetorical Genres in Code

[SLIDE 2] As rhetoricians interested in the study of digital media, we find ourselves increasingly interested in exploring the possibilities of those media—not so much to see what they allow us to perform “with” them but rather to see what we already do persuasively through them. That is, we want to take seriously the notion that we engage diverse audiences in the construction and manipulation of digital technologies; we propose to do this by examining the processes of software development related to, and the code texts that comprise, those technologies.

[SLIDE 3] If we want to argue that rhetoric occurs in digital environments, then either we should be able to identify such rhetorical activity through the existing vocabulary of critical inquiry or we need to develop a new vocabulary for it. We are interested first in investigating to what extent established critical approaches allow us to understand the persuasive composition of technologies. To pursue this investigation, we turn to rhetorical genre studies and its means of examining typified rhetorical actions and activities. We trace how genres in code produce and reproduce certain norms, values, and social actions through technologies.

[SLIDE 4] To attend to the existence of rhetorical genres in code, we work from an initial hypothesis that code, as a form of written communication, possesses features of persuasive effort similar to and entirely distinct from those of more traditional discursive writing. We examine how rhetorical activity unfolds within coding communities as means of creating social action by which software developers persuade one another to code in particular ways toward particular ends. Conventions and values of a development community are (re)instantiated, challenged, and negotiated by persuasive efforts across instantiations of typified, protocol-governed practices. Examining code genres is particularly intriguing to us because such genres illustrate persuasion in seemingly arhetorical venues. By attending to them, we can uncover how assorted values and ideologies circulate through the composition and distribution of code.

We began our inquiry by focusing on a set of related software projects, several spam control modules for the Drupal content management system (specifically, CAPTCHA, ReCAPTCHA, Captcha Riddler, and BOTCHA). We examined multiple versions of each project’s releases as well as discursive commentary about particular code contributions, as this combined body of texts illuminates how developers attempt to persuade one another—namely, contributing in certain ways to each project and promoting Drupal development more broadly.

Conventions and Compiling: A Genre-Based Framework

[SLIDE 5] Digital rhetoric scholarship has been intertwined with rhetorical genre studies at least as far back as Miller & Shepherd’s (2004) examination of weblogs. However, genre scholars often seem to struggle with questions of genre emergence and change in new media environments; as a result, they primarily focus on discourse genres, with few ventures into visual genres or the materiality of genres. Almost no accounts consider underlying technologies themselves as typified and recurrent (Miller, 1984). Further, rhetoric is still beginning to consider the vast number of communicative modes that operate within and surrounding digital activity and how to explore them (see, among others: Vee, 2010; Brock, 2012; Brown, 2014; Miller & Kelly, forthcoming). Of these, the most noteworthy is procedure or computation, due to its increasingly ubiquitous presence and significance but also because it is communicated through written representation as software code.

[SLIDE 6] Aristotle’s three genres of rhetorical persuasion—forensic, epideictic, and deliberative—served rhetorical pedagogy and practice for several millennia (Campbell & Jamieson, 1978), but the publication of Carolyn R. Miller’s “Genre as Social Action” (1984) provided genre studies with a rhetorical theory of genre founded on the social action the genre performs, offering important insight into rhetorical practices that shape our social worlds:

[I]n rhetoric the term “genre” [should] be limited to a particular type of discourse classification, a classification based in rhetorical practice and consequently open rather than closed and organized around situated actions (that is, pragmatic, rather than syntactic or semantic). (Miller, 1984, p. 155)

If we understand genre to be useful for critical rhetorical work, then we should be able to extend the concept to understand emerging modes of composing—e.g., programming—as situated and typified rhetorical actions and activities undertaken in response to recurrent situations or exigences.

[SLIDE 7] When code is written, it is not merely ex post facto transcription of an objective-material reality onto the screen and into the machine’s processor. Instead, composing code involves decisions with rhetorical, epistemic, and ontological consequences. How a program is designed to act, how it is understood to act, and who can or should manipulate it are all concerns that are articulated (in various ways) in its code. Meaningful communication takes the form of computational logic framed through code, shaped by the needs and constraints of the communities creating and accessing it. As Knuth (1992) has noted, “The computer programs that are truly beautiful, useful, and profitable must be readable by people. So we ought to address them to people, not to machines” (p. ix). Kernighan & Plauger (1978) and Kernighan & Pike (1999) have authored texts on composing code specifically to improve its readability and clarity for human audiences.

It is significant that many programmers already recognize their work as written communication and not just as an instrument for machine interpretation. While they may not use the vocabulary of rhetorical theory and criticism, they attempt to address rhetorical concerns in order to produce “better” code, code that successfully compels human readers to understand, accept, and interact with it as valuable and useful through particular ways of reading.

Drupal, Spam, and Recurrence

[SLIDE 8] Drupal is a free and open source software application package generally defined as a “content management system,” a system that provides infrastructural support for websites from small personal sites to large-scale corporate implementations. Drupal modules, developed by individual and sometimes overlapping communities, allow Drupal installations to be modified to suit specific contexts and needs, such as the prevention of spam account and content creation.

[SLIDE 10] Spam and spam control technologies evolve together; as some anti-spam approaches become ineffective and thus obsolete, there arise opportunities to develop new spam control technologies. One currently popular approach is CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart), which attempts to determine, based on user input, if a user is human or software (spam bot).

[SLIDE 11] Multiple CAPTCHA Drupal modules over the course of the last decade have innovated spam detection and prevention, such as by increasing the difficulty for non-humans to respond to tests—by obscuring text in response-prompt images (to fool optical character recognition, or OCR, software, which discerns text within image files) or by asking questions that require contextual knowledge to answer (e.g., “What is the three-letter abbreviation for the United States of America?”). We investigate how these modules are marked by recurrent rhetorical situations and typified structures and algorithmic procedures (c.f., Miller 1984) by focusing on four Drupal spam control modules: CAPTCHA, reCAPTCHA, Captcha Riddler, and BOTCHA.

CAPTCHA, ReCAPTCHA, Captcha Riddler, BOTCHA

[SLIDE 11] Of these four modules, CAPTCHA is the oldest (started in 2004), and it serves as the foundation on which ReCAPTCHA and Captcha Riddler are built, acting as much as an API for other projects as a standalone module. In addition, CAPTCHA is the single most downloaded and installed security module developed for Drupal.

CAPTCHA functions by generating a string of data against which user input is compared. There has been considerable persuasive activity among contributors over the last decade concerning how this data is generated, stored in a database, retrieved, presented to the user, and compared against the input string.

ReCAPTCHA is noteworthy in that it is a Drupal port of a project housed almost entirely within Google’s corporate structure. ReCAPTCHA uses the Google Maps databases to generate validation tests; before that, it used validation input to clarify text in Google Books’ digital archives.

Captcha Riddler differs from the main CAPTCHA module and ReCAPTCHA in that there is no randomly generated key against which user input is tested. Instead, Captcha Riddler provides a Drupal administrator with the ability to assign his or her own preferred questions and answers.

Unlike the other modules and despite its name, BOTCHA does not function as a CAPTCHA-style module. Instead, BOTCHA hides its input fields from human users but makes them available for spam bot users to complete and thus prove that they’re bots. BOTCHA follows a paradigm common to many contemporary software interfaces, that of “model / view / controller” or (MVC)—a model that manages application data, a view that represents output data provided by the model, and a controller that manipulates the model based on input data.

Social Action through Code Genres

[SLIDE 12] Despite the nature of code as a relatively new form of written communication employed in relatively new and emerging media, and building on Ridolfo & Devoss’ (2009) notion of rhetorical velocity as a strategy for composition, delivery, and response, we argue for what might be called genre viscosity, or the assorted tendencies of diverse forces within a rhetorical ecology to accelerate or resist the potential for dissemination and recurrent use of an argument or genre. Viscosity reflects rates of change in these assorted code genres within individual projects and across their larger categorical affiliations and hierarchical strata, e.g., individual program, spam control module, Drupal CMS platform, PHP language, web service/application.

Each module is comprised of code that, when examined across numerous iterations over time, reveals resistances between the service of Drupal-level rhetorical goals and those goals unique to the module’s development community. If the developers of a module cannot completely reject Drupal-imposed constraints that might be otherwise undesirable, they may at least articulate their preferences for alternatives through its code or commentary in code files.

[SLIDE 13] Broadly, these modules each demonstrate increasingly “localized” distinctions of code operations, such as the separation of test generation from validation, or the transformation of individual variables into more complex multi-element arrays to facilitate looping, iterative processes of data manipulation. The increase in modularity could suggest a number of persuasive goals. First, this might indicate an anticipation of the growing complexity of a given project, with the modular “explosion” of its code avoiding potentially unwieldy or complex functions. Second, it might reflect anticipated vectors of future expansion for the project—regardless of whether these are ultimately pursued and realized by the community.

[SLIDE 14] Drupal’s top-down influence/imposition of functional and organizational constraint upon individual module developments suggests a high genre viscosity across vertical levels of organizational hierarchy, such that smaller-scale agents (third-party communities) are unlikely to catalyze radical changes in larger-scale architecture. This viscosity also works against broader acceptance of any nonstandard procedural logic used in a module: many individual projects, especially those less popular than CAPTCHA or ReCAPTCHA, face considerable obstacles in changing community-driven typifications (demonstrated via organizational or syntactical changes in code) at the Drupal level.

For example, BOTCHA’s move to create URLs through the explosion of URL components into separate variables (and then an array for a “clean” recombination of relevant data) reflects a top-down desire to promote secure methods of transmitting information to the system’s database and prevent malicious injection of outsider code. However, the specific approach employed by BOTCHA developers resembles little the coding preferences of developers in other spam control module communities, but it functions successfully for the BOTCHA community.

[SLIDE 15] That said, individual projects do display varied rates of genre viscosity in influencing developers of other individual modules; such influence seems due in part to the overall lifespan and popularity of a given project. In 2007, CAPTCHA developers reorganized the module’s functionality based on a confluence of events—including numerous individuals developing their own CAPTCHA alternatives and a body of complaints about CAPTCHA’s bugginess—and established the module as an API, a framework upon which to build specific CAPTCHA variations without compromising the “life” of the initial project (hunthunthunt, 2007). In part this occurred due to the main CAPTCHA developers arguing that others “join forces,” per core Drupal development values (“Joining Forces,” 2015). In part it was due to alternative modules “forking” their projects from CAPTCHA, essentially using the pre-existing code as a base while innovating without CAPTCHA reaping the rewards of any particularly successful endeavors. The consolidation kept efforts more closely associated with one another and gave all involved “access” to examine and text proposed experiments with validation, security, and so on.

[SLIDE 16] By assuming a position as a framework with which others can associate themselves, CAPTCHA has gained a high viscosity, making it more difficult to change how the project (or any of its associated modules) functions at a fundamental level, although such changes may impact the development of a single application of CAPTCHA principles. This viscosity may differ greatly in the experience of would-be innovators involved with standalone projects, like the more recently established BOTCHA module and its model-view-controller setup. MVC is an incredibly common programming schema outside of, but not within, Drupal’s modules. Due to this organizational distinction, BOTCHA has the potential to draw in developers who might dislike Drupal’s conventional module structure, which might explain in part the number and frequency of commits to the project.

Over time, changes made to Drupal architecture are given little resistance by individual modules, so long as its developers remain motivated to maintain them; changes to the CAPTCHA API similarly face little resistance by its related modules, like ReCAPTCHA. In the example displayed, we can see changing development values inscribed into the module’s code as ReCAPTCHA is restructured to follow changes in CAPTCHA functionality across Drupal releases 5.0 to 7.0. Specifically, contributors demonstrate a turn to functional modularity (from the general variable_get() function calling data from a pre-existing server authentication to a session-specific fsockopen() verification check from Drupal 5 to 6), an increase in the use of arrays, rather than separate variables, to store related data, and the emergence of explicitly valued boolean variables (e.g., FALSE as the default value for static $_recaptcha_jsadded). Each of these decisions suggests a particular philosophy for approaching the construction and verification of a ReCAPTCHA test, understood through the continually changing (and variably viscous) constraints at the levels of the Drupal platform, the CAPTCHA API, and the larger ReCAPTCHA web service.

These examples demonstrate snapshots in time over the lifespans of these modules, and they do not fully reflect the number of relevant contribution attempts (failed and successful submissions accepted for inclusion in future code releases), splinter projects (“forks”) started by those who wanted to pursue alternative solutions or promote different values, or the surrounding discursive conversations about which changes should be accepted and improved upon.

[SLIDE 17] As genres in code, all of these modules demonstrate both considerable variety and recurrence in the procedural logics comprising their test generation and validation. While these tests have not changed much in any case, each project has, over time, increased the scope and variety of the implemented security measures surrounding its key generation procedures (e.g., restricting access to variables and data in the SQL database; setting and flushing individual session ID information; cascading multiple validation tests) as a way to establish the project as a reliable and trustworthy module for spam control but also as a way to promote, through clarification as well as obfuscation, particular goals for the community to achieve, value, and adhere to (or reject).

[SLIDE 18] If we want to claim that we are interested in the persuasive possibilities of emerging technologies, then we need to attend further to how the mechanisms of those technologies are communicated, perpetuated, and changed over time through their code by the communities of developers that engage them directly rather than focusing overwhelmingly on the experiences of end-users significantly impacted by the procedural arguments of development practices. Given that this is still very much a work-in-progress, we recognize the need to explore these texts in greater detail as well as the need to examine a far greater set of code texts if we are to reach stronger conclusions about how computational procedures mark typified persuasive appeals. However, from our preliminary analysis we suggest that the rhetorical concept of genre illustrates important features of typified texts, rhetorical decision-making in coding practices, and where the nexus of stabilization and change in coding practices might be found.

References

Brock, K. (2012). One hundred thousand billion processes: Oulipian computation and the composition of digital cybertexts. Technoculture: An Online Journal of Technology in Society, 2. Retrieved December 14, 2014, from http://tcjournal.org/drupal/vol2/brock

Brown, J.J., Jr. (2014). The machine that therefore I am. Philosophy and Rhetoric, 47(4), 494–514.

Campbell, K. K., & Jamieson, K. H. (1978). Form and genre in rhetorical criticism: An introduction. In K. K. Campbell & K. H. Jamieson (Eds.), Form and genre: Shaping rhetorical action (pp. 9–32). Falls Church, VA: Speech Communication Association.

hunthunthunt. (2007). Future direction of Captcha???. Drupal. Retrieved April 7, 2015, from https://www.drupal.org/node/154783

Joining forces with others and co-maintaining projects. (2015). Drupal. Retrieved April 7, 2015, from https://www.drupal.org/node/23789

Kernighan, B.W., & Pike, R. (1999). The practice of programming. Reading, MA: Addison-Wesley.

Kernighan, B.W., & Plauger, P.J. (1978). The elements of programming style. 2nd ed. New York: McGraw-Hill.

Knuth, D.E. (1992). Literate programming. Stanford, CA: Center for the Study of Language and Information.

Miller, C.R. (1984). Genre as social action. Quarterly Journal of Speech, 70, 151–176.

Miller, C.R. & Kelly, A.R. (Eds.). (Forthcoming.) Emerging genres in new media environments.

Ridolfo, J., & Devoss, D.N. (2009). Composing for recomposition: Rhetorical velocity and delivery. Kairos: A Journal of Rhetoric, Technology, and Pedagogy, 13(2). Retrieved March 25, 2015, from http://kairos.technorhetoric.net/13.2/topoi/ridolfo_devoss/intro.html

Vee, A. (2010). Proceduracy: Computer code writing in the continuum of literacy (Unpublished doctoral dissertation). Retrieved from ProQuest Dissertations and Theses Full Text. (3437088)