Reading the digital

In this section, a method is outlined for digital reading and writing, or iteracy that can form the basis of an approach in critical theory for reading code and opening these black boxes.

Testing is a hugely important part of the software lifecycle and links the textual source code to the mechanic software and creates the feedback cycle between the two. This is linked to Boltanski and Thevenot's (2006) discussion of ‘tests' - implying that it is crucially the running of these obfuscated code programs that shows that they are code at all (legitimate tests), rather than nonsense. Boltanski (2011) outlines three kinds of test that can be used as a basis of such critique,

The truth test unmasks a universe of signs by exhibiting it in its plenitude and consistency.... In and through acts, the reality test unmasks the powers concealed in the interiority of beings.... The existential test, unmasks the incompleteness of reality and even its contingency, by drawing examples from the flux of life that make its bases unstable and challenge it.

The fact that code objects are often unreadable by humans and yet testable on a number of dimensions is very suggestive. These three ways of approaching a critical testing of software bring to bear another method to complement what we might call the close reading of code, or the distant reading of interface analysis, to engage with the processual nature of algorithms. However, I want to outline a further method of testing drawn from Heideggerian phenomenology. This approach, using the pragmata of code, its materiality and agency to do things, combined with its implicit temporality and goal-orientedness allows us to think about how software works by the notion of coping tests that I develop here. For Heidegger, ‘coping' is a specific means of experiencing that takes account of the at-handiness (zuhandenheit) of equipment that is being used. We ‘cope' with objects in the world. Therefore, coping tests enable us to observe the breakdowns of these objects, they are the moments when, in this case, code objects stop working either partially or completely. So software/code is a happening or a project rather than static text on a screen. The implication being that we can learn a lot about software by deliberately breaking it, glitching it, hacking it and generally crashing its operations (see Alleyne 2011). This is a technique that has a long and respected history, as tinkering with technology, taking it apart and rebuilding it. For software, the fun of running ‘coping tests' is exactly to see the extent to which the software under investigation is able to cope with the pressure exerted upon it by the tester. For example, the practice of ‘data moshing' is essentially hacking the ‘P' and ‘I' frames of digitally encoded videos; not only does the effect produce startlingly arresting images and aesthetics, but it also shows how video functions as software. Indeed, as explained on the ‘Know Your Meme' website,

Digital video compression (such as MPEG-4 part 2, h.264, VP8, etc) works by recording the first frame (known as the keyframe) as a complete image, and recording the subsequent frames as only the changes from this first frame.

This technique is also surprisingly simple, requiring nothing more than video­editing software, a selection of videos to splice together and experimentation. The glitches and errors thereby introduced show us how our software enter­tainment systems are structured, and how they cope with graceful failure.

The nature of coping that these tests imply and the fact that the mutability of code is constrained through limits placed in terms of the testing and struc­ture of the project orientation (Berry 2011a: 65-6) also allow the researcher to explore where there are restrictions that serve as what Boltanski and Thevenot would call 'legitimate' tests, which themselves are reflexively played with in terms of clever programming that works at the borderline of acceptability for programming practices (hacking is an obvious example of this). Here, it is re­quired that the researcher works and thinks at a number of different levels, of course, from unit testing, application testing, UI testing and system testing more generally in addition to taking account of the context and materialities that serve as conditions of possibility for testing (so this could take the form of a number of approaches, including ethnographies, discursive approaches, etc.).

For critical theory, I think coping tests are an immanent method as an alter­native (or in addition to) the close reading of source code or software objects. This can be useful in a humanities perspective for teaching some notions of code through the idea of 'iteracy' for reading code (Berry 2012b) in relation to critical readings of software/code opened up through the categories given by critical theory. But this is also extremely important for contemporary critical researchers and students who require a much firmer grasp of computational principles in order to understand the economy, culture and society which has become softwarized, but also more generally for the digital humanities, where some knowledge of computation is required to undertake research.

One of the most interest aspects of this approach, I think, is that it helps sidestep the problems associated with literary reading of source code, and the problematic of computational thinking in situ as a programming practice. Coping tests can be developed within a framework of 'depth' in as much as different kinds of tests can be performed by different research communities, in some senses this is analogous to a test suite in programming. For exam­ple, one might have UI/UX coping tests, functionality coping tests, API tests, forensic tests (linking to Kirschenbaum's [2008] notion of forensic media) and even archaeological coping tests (drawing from media archaeology, and partic­ularly theorists such as Parikka [2012]) - and here I am thinking both in terms of coping tests written in the present to 'test' the 'past', as it were, and in terms of an interesting history of software testing, which could be reconcep­tualized through this notion of coping tests, both as test scripts (discursive) and as software programming practice: more generally, social ontologies of testing, testing machines and so forth. We might also think about exploring software epistemologies through the testing of the boundaries of knowledge collected, processed and stored in computational systems.

It is something that I have been thinking about too in relation to the concept of digital Bildung (see Berry 2011a). I would like to suggest that iteracy might serve as the range of skills used for understanding computation - as indeed literacy (understanding texts) and numeracy (understanding numbers) do in a similar context. That is, iteracy is specifically the practice or being able to read and write texts and computational processes, rather than the more extensive notion of digital Bildung (see Berry 2011a: 20-6). In contrast, digital Bildung is the totality of education in the digital university, not as a subject trained in a vocational fashion to perform instrumental labour, nor as a subject skilled in a national literary culture, but rather as a subject that can reconcile the information that society is now producing at increasing rates, and who understands new methods and practices of critical reading (such as code, data visualization, patterns, narrative) and is subject to new methods of pedagogy to facilitate it (Berry 2011a: 168).

The function of the university cannot be to simply offer prospective students a catalogue of “skills” from which to choose. For, were that its function, then the university would have to assume that the students who come to it have already become whatever it is they are to become. The university would then be quite correct in seeing the student as a kind of market basket, to be filled up with goods from among the university's intellectual inventory. It would be correct, in other words, in seeing the student as an object very much like a computer whose storage banks are forever hungry for more “data” But surely that cannot be a proper characterization of what a university is or ought to be about. Surely the university should look upon each of its citizens, students and faculty alike, first of all as human beings in search of - what else to call it? - truth, and hence in search of themselves. Something should constantly be happening to every citizen of the university; each should leave its halls having become something other than she who entered in the morning. The mere teaching of craft cannot fulfill this high function of the university. (Weizenbaum 1984: 278)

Having a grasp of the basic principles of iteracy is crucial for reading code and for undertaking critical theory in the digital age.

Black writes: “to see a line of code as beautiful, one must be able to see why, of all the ways the line could have been written, this way is the most compact, the most effective, and hence the most elegant” (p. 127). Furthering an explicit comparison to the close reading techniques of 20th Century “New Criticism,” Black goes on to say that, in this pedagogical tradition, “A program's merit is assessed much the way a poem's would be, in terms of structure, elegance, and formal unity” (p. 131). (Wardrip-Fruin 2009: 34) Clearly, we have to be careful not to narrow iteracy to only formal program­ming knowledge. Indeed, I have found it very useful to explain to students that they are 'programming' a computer when they set an alarm on their iPhone or negotiate a menuing system in photoshop. This highlights that it is black boxes all the way down for computational systems - this layering within computational technologies we have come across before - but also that we need to be able to potentially open these black boxes all the way down. Iteracy includes the abstract principles of computational thinking, as well as the specifics of learning programming in terms of source code that becomes an 'executable'. This is important in order to highlight the disadvantages that confront individuals who do not have these basic skills for using computa­tional devices. Increasingly, I think 'iteracy' will be as crucial for operating in this computational culture - especially considering the ontologies that are delegated into the devices that surround us take for granted certain computa­tional principles of operation, such as real-time data and media streams - as numeracy and literacy have been.

Iteracy, therefore, also refers to the ability to read, write and understand processes, that is, following Wardrip-Fruin's (2009) notion of 'process descriptions'. To be able to create beautiful processual structures, for example, as found in live coding, but also in more mundane experiences of using technology. So, perhaps, two levels of writing are taking place here: the textual and the processual, which highlights the way in which we can think of these as two forms of digital writing: (1) code/text (deep) and (2) the process/ screenic (flat). This is a simplification, as the previous discussion about layers in computational systems demonstrates; however, it is a useful heuristic for thinking about the kinds of things we need to take account of in teaching and researching computational media. This also helps draw attention both to reading code and to reading processes. As Wardrip-Fruin argues,

there are important reasons that we should not depend on source code for our primary route to information about the operations of the processes of digital works. First, source code is available for only a small proportion of digital works. Second, source code is notoriously difficult to interpret— presenting a significant challenge, often, even to the individual or group responsible for writing it. Third, engaging with the specifics of the source code, while it allows us insight into issues such as individual programming style, is not always an important investment for understanding a work's processes. (Wardrip-Fruin 2009: 36)

While I think Wardrip-Fruin is right in pointing to the difficulty of source­code reading alone as providing a complete means of reading code, I do not think that consequently we can jettison code to focus on process. Indeed, something akin to the hermeneutic circle is needed here, whereby the code is understood not merely through a close reading of the text, but by running it, observing its operation and the processes it institutes, introducing breakpoints and ‘print to screen' functions to see inside the code while it is running, such as through the use of these coping tests. Programmers who have iteracy by education and habit are able to jump between these perspectives on the code (code as text, code as process, code as whole system), seamlessly backwards and forwards as they develop knowledge and understanding of the code. This is similar to a notion of a ‘fusion of horizons' but needs to be supplemented by critical readings that explore how code objects exist in a historical, political and socio-economic context and usually with a certain aim or intention (whether achieved or not).

Iteracy takes its name from the computational structure known as iteration. This is widely used in computer programming as a method of actualizing or implementing and algorithm by repeating a set of instructions. Iteration is a term used in computing to refer to the repetition of a command, code fragment, process, function, etc. Understanding iteration at a micro-level is a crucial skill for the programmer to develop, particularly as it is a method for re-using existing processes (such as in looping structures). Further, iteration itself at a macro-level, combined with constant improvements, is a key way of developing software/code (very much associated with agile programming, for instance). An example of iteration in Ruby code is:

This instructs the computer to perform the task text ‘Hello', or print Hello to the screen, five times in a repetitive loop, or iteration. Here though, I broaden the meaning of iteracy beyond mere looping structures in programming code. What other skills, then, might be associated with this notion of iteracy?⁵ I see iteracy as developing the ability to reason critically and communicate using

discourse to discuss, critique and study the medium of computer code.⁶ Particularly I want to relate this to the notion of a holistic digital education, or digital Bildung, more specifically as methods and approaches related to critical inquiry of the computal (Berry 2011a). I do think that iteracy has some heuristic advantages over terms like ‘code literacy', ‘digital literacy', 'information literacy' and so forth, especially the connotations that iteracy has with iteration, a key part of how code functions are read and written.

Some of the components of iteracy include: (i) computational thinking, or being able to devise and understand the way in which computational systems work to be able to read and write the code associated with them. For example abstraction, pipelining, hashing, sorting, etc. (see Wing 2011). (ii) understanding algorithms: understanding the specifically algorithmic nature of computational work, for example, recessions, iteration, discreti­zation, etc. (iii), understanding the significance and importance of data and models particularly of data, information and knowledge and their relationships to models in computational thinking. (iv) practices in reading and writing code which requires new skills to enable the reader/programmer to make sense of and develop code in terms of modularity, data, encapsulation, naming, commentary, loops, recursion, etc. (v) learning programming languages as understanding one or more concrete programming languages enables the student to develop a comparative approach and hones the skills associated with iteracy, for example, procedural, functional, object-oriented languages, etc. (vi) developing skills related to appreciating code aesthetics, that is the aesthetic dimension of code, software and algorithms, including notions of 'beautiful code' and 'elegance' as key concepts (see Oram and Wilson 2007), but also the question of the digital and aesthetics in relation to new media art and the new aesthetic. As part of iteracy we therefore have to teach how to program experimentally and learn by hacking within pedagogical contexts rather than coding uncreatively.

Here, obfuscated code is a helpful example. Obfuscated code is a computer source code that is functional but very difficult to read. This is not to demonstrate unreadable reading, or even for the spectacular, but rather as a stepping off point to think about the materiality of code through the notion of software testing (see Berry 2011a: 81-4, for a fuller discussion of this). Obfuscated code is a code deliberately written to be unreadable by humans but perfectly readable for machines.This can take the form of a number of different approaches, from simply mangling the text (from a human point of view) to using distraction techniques, such as confusing or deliberately mislabelled variables, functions, calls, etc. It can even take the form of aesthetic effects, like drawing obvious patterns, streams and lines in the code, or forming images through the arrangement of the text. It can also be productively used in programming as ‘code obfuscation or “information hiding”... to make code more modular and abstract and therefore easier to maintain... such is the fundamental contradiction: what you see is not what you get.... Code is never viewed as it is. Instead code must be compiled, interpreted, parsed, and otherwise driven into hiding by still larger globs of code. Hence the principle of obfuscation' (Galloway 2012: 67-9). Obfuscation and related principles of information hiding such as encapsulation, interfaces and black boxes are all useful means of exploring iteracy and also of applying the method of coping tests in order to determine and understand software functionality. Together, these offer critical-empirical methods for the reading of the digital, which can be developed reflexively to question the how, why, where, when and who of software and subjecting algorithms to critical examination.

One last thought: although I make the link between iteracy and looping/ repetition, I think it is probably more accurate to think of iteration not as a circle but as a spiral. That is, that learning builds on previous learning and skills in a virtuous upward spiral that develops competence and capabilities.⁷ While here, I have only been able to provide a schematic overview of the development of critical approaches to the digital, and how we might develop a constellation of practices that develop critical theories of the digital, it is clear that it is crucial to begin to think more seriously about the computal in a critical way.

The discussion of political imaginaries that mirror the development of black-boxed computer systems and obfuscation is, in this reading, a worrying development, such as government as a platform, massive comprehensive data collection by government agencies such as the NSA, open access and transparency as ideology, and engineering concepts transferred unproblematically into the political sphere. Additionally, the problem of cognitive capture by corporations through notions of augmented humanity and the computational intervention in pre-consciousness requires urgent critical attention. The important question becomes: how much computation can democracy stand, and what should be the response to it?

If these claims are true that an active citizenry will increasingly need to be a computationally enlightened one, avoiding what we might call the heteronomy of the algorithms for the autonomy of reason, then we must begin teaching the principles of critiquing the computal through notions such as iteracy and digital Bildung. This critical spirit is counter to the growing belief that the university is only useful for producing mandarins and workers, and highlights the importance of critical thinking in humanities and social sciences in a digital age (see Berry 2012b). Indeed, I now want to turn to discuss these issues in relation to these concepts in order to draw these strands together and develop a tentative outline of a critical praxis for the digital.

194