To Code or Not to Code?

Easter 1982 – thirty years ago! – was spent feeding my latest addiction. Like over a million others, I had acquired the Sinclair ZX 81, which popularised home computing in Britain. It had just one kilobyte of on-board memory; I soon invested in the upgrade to take it up to 16 kilobytes. You used your television as the monitor, and loaded the programmes from audio cassette tapes. My love affair with Sinclair only came to an end when even more awesome Amstrad PCW came along a few years later. Indeed, checking references just now, I came across the Sinclair ZX81 emulators, and began to feel some of the old passion stirring.

In order to get the Sinclair to do anything, you had to programme in the Sinclair flavour of Basic. Even to get a word to display on your television, you had to write and run a short programme. For some, this was a problem. One of the reasons why the BBC decided to use Acorn computers rather than the Sinclair machines to promote computer literacy in schools was that the producer of the BBC series The Computer Programme, Paul Kriwaczek, ‘did not believe that the future of computers lies in everyone learning to program in BASIC’. Yet, for me and I suspect many others, it was precisely the programming that was so fascinating about the Sinclair. As you sought to develop a programme that would, say, enable you to do some primitive word processing, the hours and days would disappear as you played with variables and loops. I became obsessed with trying to produce a programme to calculate the date of Easter. Dates in medieval documents are generally given by reference to religious festivals. Dating medieval documents involves cross-checking tables in a Handbook of Dates. This is obviously a process that can be automated and calculating the date of Easter would be a first step towards this. I honestly believed, in a fit of youthful delusion, that somehow I could produce an automated Handbook of Dates on a Sinclair ZX81. Of course, I was unsuccessful; amazingly, there still doesn’t seem to be an automated version of the Handbook of Dates online. I gave up when I realized how much time my addiction to Basic programming was consuming – I am convinced that I would have completed my PhD thesis two years earlier if I hadn’t purchased a Sinclair ZX81. I realized that I was spending all my time becoming a low-end computing hobbyist whereas I should be concentrating on becoming a reasonably accomplished historian.

My experience with the Sinclair ZX81 perhaps prefigures the debate which is still an active one within the digital humanities – namely the extent to which practitioners of the digital humanities should be hands-on programmers and the level of hands-on computing engagement we should expect from scholars of the digital humanities. Stephen Ramsay’s now celebrated intervention at the 2011 MLA ‘Who’s In and Who’s Out’ , refined by a subsequent post, ‘On Building’, argued that the creation of digital objects of all types should be a fundamental concern of practitioners of the digital humanities. Ramsay points out that humanities scholars are familiar with theorizing (say) maps as cultural artefacts, but that the experience of mapping in GIS gives new perspectives. He argues that ‘Building is, for us, a new kind of hermeneutic – one that is quite a bit more radical than taking the traditional methods of humanistic inquiry and applying them to digital objects. Media studies, game studies, critical code studies, and various other disciplines have brought wonderful new things to humanistic study, but I will say (at my peril) that none of these represent as radical a shift as the move from reading to making’.

The anxieties expressed in the discussion of Ramsay’s blog posts echo through the recent volume of Debates in the Digital Humanities (an extraordinarily Americo-centric volume for a discipline which claims to be highly collaborative and international in its scope and outlook). Indeed, Ramsay can be seen as anticipating recent wider arguments in Britain that coding should receive more attention in schools. Last Saturday, John Naughton launched in the Guardian a manifesto for teaching computer science in schools which emphasized the learning of code in a way that must have gladdened the heart of Sir Clive Sinclair. Indeed, the Raspberry Pi seems to take us back to the days of the ZX81, and has already proved very successful in making children understand how the digital devices which pervade their lives work. In my recent article in Arts and Humanities in Higher Education, I argued that it is essential for humanities scholars to become more than mere consumers of digital resources. If this is to be achieved, some understanding of the nuts and bolts of such resources is essential.

But does this mean that humanities scholars, in order to engage with the digital world, must become coders? Isn’t there precisely the danger that I found with my Sinclair machine, that I was becoming a poor coding hobbyist at the expense of good humanities scholarship? I think Ramsay’s use of the term building is important here. In creating Electronic Beowulf, Kevin Kiernan and I were completely dependent on the skilled help of a number of computer scientists and programmers, but we were nevertheless building something which was both a statement about the nature of Beowulf and a vision of what digital technologies can achieve. It is here that the collaboration which is seen as a distinctive feature of the digital humanities comes in. Something like Electronic Beowulf or the projects created by the Department of Digital Humanities at King’s College London simply cannot be achieved without a wide range of skills embracing not only humanities scholarship but also computer science, project management, programming in a variety of forms, interface design, server management and much else.

Much of my thinking about digital projects is informed by my experiences at the British Library in the 1990s, and in particular the Library’s work in designing the original automated systems which gave catalogue access and allowed automated book ordering in the St Pancras building. A naïve user (aka a humanities academic) would assume that to build those systems you either bought a piece of software or got some programmers in to build the system. But building a robust bespoke automated system is more complex than this. Librarians, as users, define the need. An army of analysts define the logical structures required to meet these needs and asses the array of technical possibilities available. These logical definitions are then broken down into units of work. The system was actually designed in an enormous amount of detail on paper, with a mass of flow diagrams, before a line of code was written, and this was in many ways the intellectual heart of the development. An army of programmers then built the various modules defined in the project specifications. The crucial element in this process was not the coding, but rather the design on paper. The analysts who produced this design were the most important (and highly paid) people in the whole process, yet generally they had very limited programming skills. The coders who actually built the system were at the bottom of the food chain, producing elements of the system to order, frequently with only limited understanding of how the whole system worked.

My experience at the British Library taught me that automation should not be equated to coding. In many ways, it is providing the overall vision and defining – on paper – the steps by which that can be realized which is they key part. This, after all, is what computer scientists spend a lot of their time doing. Such a process requires an understanding of the tools and methods available, but is not wholly focused on the creation and deployment of these tools. Again, an analogy from the library world is I think helpful. It is essential for all librarians to have an understanding of cataloguing standards and methods, but it is not necessary for all librarians to be cataloguers. A scholar in the digital humanities should be sufficiently well informed about the technical environment to develop an independent and critical approach to the use of digital methods and resources, but does not necessarily need to be a hands-on programmer.

I worry that an emphasis on coding, and even on building things, is holding the digital humanities back as an academic discipline. We emphasise collaboration, and collaboration is certainly necessary for practitioners of the digital humanities, to build the innovative digital activities, bit are our patterns of collaboration always the right one? The Department of Digital Humanities at King’s College London has worked with dozens of academic partners both at KCL and elsewhere to realize an impressive portfolio of projects. The Department quite rightly stresses collaboration as at the heart of its philosophy. Yet I have been struck in the few months that I have been working in the Department by how often our external academic partners assume that they are the driving force in the collaboration. For them, the humanities scholar is always the person who calls the shots; the digital humanities specialist is simply there to do the donkeywork of programming the machine to do what the academic wants. Collaboration turns out to be a mask used to disguise the true nature of much of the Department’s work which is too often the kind of software development or infrastructural maintenance normally provided by a University service department. Now, it could be argued that academics should not see themselves as superior to information service departments, and I would strongly agree with such a proposition, but it is nevertheless sadly true that academics perceive themselves as at the top of the university tree, and most humanities academics evidently regard digital humanities units (even when these are constitutionally defined as academic departments) as representing something lower down the higher education food chain.

Among the controversies to be considered by The Cologne Dialogue in the Digital Humanities later this month is the question ‘Do the Digital Humanities have an intellectual agenda or do they constitute an infrastructure?’. My colleague Willard McCarty will be presenting an impressive defence of the intellectual component of the Digital Humanities, but one wonders whether the question is correctly put here. The issue is not whether, as Anthony Grafton put it, digital media are always means rather than ends. A lot of tne problem is (as Willard will be suggesting) one of confidence – scholars in the digital humanities too often see themselves as serving longer established academic disciplines and lack the chutzpah to develop their own intellectual programme which doesn’t need topay so much attention to others. The question is how Digital Humanities stops presenting itself as an element of infrastructure, as something which helps other scholars realize their visions, and realizes that it doesn’t need to be dependent on classicists or historians or literary scholars to keep going. Part of the reason why Digital Humanities is treated by other scholars as a support activity is because of its interest in programming and coding – it becomes the gateway by which scholars can gain access to this new digital world. One of the many threats confronting the digital humanities is that it will increasingly become part of the service infrastructure. The suggestion that the term digital humanities will soon disappear as all humanities scholarship becomes digital is predicated on the idea that the digital humanities represents a form of specialist support activity which will soon no longer be required. Certainly, the digital humanities should build things – it should be pioneering the creation of new forms of scholarly discourse in a digital environment – but it should not simply be building things for other scholars, and that has too often been the case.

Indeed, it could be argued that the digital humanities as a whole has fallen into exactly the same trap I was concerned about with my Sinclair ZX 81. By insisting on building things ourselves, we simply come up with slightly amateurish packages which fail to make a large-scale impact or simply repeat existing procedures across different subject domains. The pioneering days of digital editions were very exciting and innovative, but having established what we think of as an accepted procedure, we now repeat that again and again and again in different subject domains for different groups of scholars. When practitioners of the digital humanities are going to build things, these objects should be truly innovative and should restate our sense of what is possible in a digital environment. In the recent Institute of Historical Research seminar on ‘The Future of the Past’, I was very taken by Torsten Reimer’s call for the digital humanities to renounce the sort of digital photocopying that is commonly associated with the creation of digital editions and rather seek to develop genuine innovation that moves into new territory both our cultural engagement and sense of the possibilities of computing. The deployment of TEI and its role in the development of XML were truly innovative and helped create the modern web, but that was nearly twenty years ago. Since then, what true innovation has emerged from the digital humanities? Zotero? Citation managers were available before it appeared. Crowdsourcing? Simply borrowed from other domains. The digital humanities has little to show in the way of true innovation, yet all those engaged with the digital humanities know that the complexities of the humanities offer endless possibilities for the creation of innovative technologies in areas ranging from imaging to nanotechnology. Consider the hyperlink. What a crude mechanism it is. Any textual scholar could imagine more complex and interesting possibilities. The digital humanities could readily look to develop the next stages beyond hypertext. Yet it doesn’t – because it is too busy preparing digital editions for historians who don’t otherwise have access to programming resources.

If the digital humanities is indeed to start realizing its own intellectual agenda, it needs to rethink the nature of its collaboration. It must avoid like the plague that service activity which purports to be collaboration – the sort of Antechrist of the digital humanities. It should instead develop collaboration within the digital humanities, genuine collaboration which is all too rarely seen. To achieve this requires some fundamentally rethinking. Digital humanities centres are certainly part of the problem. Frequently dependent on soft funding, they have perforce to pursue research projects in which the role of the digital humanities is often subservient, and fundamentally a service function. It would be better to have smaller digital humanities departments which have more stable income streams from teaching, and aren’t forced by financial necessity to seek out research projects which reduce the digital humanities element to have a service function. The nature of our projects should change as well. We urgently need to start developing more experimental and risky projects, which challenge existing methods and standards and reach out into new areas.

In short, we should code and we should build, but for ourselves and because (like my experiments in trying to create a Handbook of Dates on the Sinclair ZX81) they feed our own intellectual interests and enthusiasms, and not those of others.