Theory, Systems and Vino

I’ve been watching the current Theory Debate via Digital Humanities Now this past week or so with interest but have only just found the time to write down my reaction to it. It’s a topic that has been dear to my heart for some time now. It touches on the question of where the digital humanities stand in relation to the core tradition, and what direction it’s going to take as a practice (I’m not sure I’m keen for it to become a ‘discipline’ in the traditional sense of the term). I’ve often said that if DH is to be taken seriously by the analog humanities it will need to begin to engage with some core humanities practices, develop some kind of theoretical framework(s), identify some core methodologies, and  generally produce some writing that has recognizable intellectual ‘grunt’. We’re developing a new community of practice within a 2000+ year tradition that includes some rather weighty names, after all. We should attain to the development of a sub-tradition that draws on everything at our disposal. And that implies ‘a whole bunch of stuff’. A few years ago, while I was working in London, I actually started a website called d-hist, that aimed to united digital history with the core methodological and theoretical traditions taught in post-graduate History classes. I wanted to write a series of essays along the lines of ‘The Historical Dialectic and Digital History’ – the idea was just to get in the kitchen and start throwing ideas together. Unfortunately I was working in IT rather than academe and it went nowhere. My point here is that I’m by no means against Theory, which is crucial to the long-term viability of digital humanities.

As one of my professors used to say, though, ‘Theory is like wine. It’s best enjoyed when it’s of high quality, and even then only in moderation’. The problem with humanistic theorizing, of course, is that it can have a stultifying effect. I love it, but it’s also a good part of the reason why the humanities are in such a dire position in today’s intellectual world. I won’t open that can of worms any further, except to note that my understanding is that ‘DH Culture’ (such as it is) has been resistant to theory partly for this reason. Many early DHers fled to the practice precisely to avoid overly-theorized colleagues arguing in ever-decreasing circles. We enjoyed being incubated from the culture wars of the eighties and nineties, and it’s possible to argue that if this hadn’t been a guiding assumption in those post-Netscape years we wouldn’t be in as good a position as we are today. The argument would go that DH is fresh, new, and untainted from the (I think necessary, if also painful and destructive) battles of the 1980s and 1990s. If we provide hope to embattled colleagues and can be described as a healthy and rare green shoot for the humanities now, it is at least in part because we’re free of the theoretical baggage that is sinking (or has sunk) other humanities disciplines. We need to tread carefully, and although we should encourage digital humanists to emphasize humanities content over computer science, that doesn’t necessarily mean we should subvert our vital connection with computer science by theorizing for the sake of theorizing.

To perhaps grossly over-simplify things, the current conversation seems to me to hinge around two poles that can be broadly characterized as ‘Theory versus Code’, on the one hand we have an understandable desire to make our practice more recognizably humanistic by wrapping it in the kind of critical analysis that is grist to our mill (which requires Theory as the bedstone), on the other we have a commitment to code because our facility with this is the thing that marks DH as a fundamental and exciting departure from the main tradition. Natalia Cecire has represented the former position very well over the past couple of weeks, and it is one that deserves respect. The other side of the equation is perhaps best represented by Tom Scheinfeldt’s comment that ‘DH arguments are encoded in code‘ and don’t need elaboration. As the paragraph above might suggest, I’ve got a lot of time for this position. DHers who believe we should focus on virtualmachines and code take a pragmatic stance that doesn’t proscribe Theory, but implies that ‘the code is the theory’, or at least ‘the code is all we need’. The implication is that the empowering feature of DH is that it puts the means of production into the hands of humanists by developing skill at a code level. Such a position implies that DH is primarily about making and hacking: I suspect there’s a deep-seated concern across the community that if we lose that focus in an attempt to theorize the domain we risk sliding back into the insufferable cultural, professional and intellectual situation that code allowed us to escape. I’m by no means suggesting that every person at the Code end of the spectrum thinks this is the case (there’s nothing in their writing that suggests hostility), but I certainly agree with those who feel the development of Theory is risky for DH. To state things baldly, it threatens a return to everything we stand against: partisan politics, ideological wars, normative rather than inclusive politics. The worst case scenario is that it acts as a Trojan horse, importing all that is wrong with the humanities into all that is good.

My ‘worst case scenario’ could also be described as ‘paranoid anti-theoretical nonsense’, of course. As I suggested at the start of this post, the application of high quality theory and method to the digital humanities is essential if we are to develop as an intellectual community and be taken seriously by our peers. The significant point here for me, is that the way to do this is to scale out our focus on virtualmachines and code towards a broader, dare I say it more holistic view, that encompasses governance and infrastructure alongside theory and method, content and philosophy. This is the position I put forward in my piece (currently still in preview) in Digital Humanities Quarterly. In that article I argue that if we’re going to create a robust theoretical and methodological apparatus for DH we’re going to need to look to some IT approaches like enterprise architecture, and adapt them to our purposes. While I certainly wouldn’t describe myself as having anything more than rudimentary coding skills, therefore, I have no doubt that code should remain at the center of our community and our practice: it is the lodestone to which  we’ll need to return to again and again to keep ourselves on track. This doesn’t imply we all need to become computer scientists, though. Patrick Murray-John’s suggestion that DHers should at least be able to intelligently discuss a data model, or (to clumsily paraphrase) understand why developers can’t turn lead into gold, strikes me as a sensible approach to take. We need to understand code enough to use it and hack at it for basic purposes. Some will go further and become experts in a particular language, thereby empowering the community as a whole with deep channels of knowledge, but we’re too open for this to become the sine qua non of acceptance. We need basic coding skills so we can do some things ourselves and can move beyond the veil of new media surfaces to understand how digital products function ‘behind the curtain’ – this much is essential for both practical and critical reasons. We also need to understand the technical and creative constraints code places on designers and developers, and be capable of contributing intelligently and usefully to a software development team, but beyond that I suspect anything goes. As an aside, and not that any DHers have suggested it yet, it’s important to remember that if the IT industry demanded coding proficiency for entrance to the profession developers would have to do their thing without the support of a plethora of project managers, business analysts, technical writers and testers (not to mention managers). These people don’t necessarily code, but they sure understand IT.

I think we need to go even further, though, and avoid the simplistic Code versus Theory bind I outlined (and perhaps erroneously identified, too) above. While code should remain our lodestone, Murray-John’s comment brought home to me that our value to the humanities is broader than this. It lies in the fact that we understand how software and web applications work at not only the code level but also at the systems and infrastructure level.  I don’t think we should leave the digital humanities to either a reliance on //code comments, or to purely humanistic traditions derived from literary or historical practice. We need something more radical and broad-ranging than that: we need theoretical and methodological frameworks (note the plural) that can describe the intellectual, cultural and (this is of vital importance) systemic nature of our craft. Humanistic theories and methods imported from literary and historical analysis will of course be central to this, but those approaches will not stop code breaking, or ensure that future humanistic infrastructures are well integrated and sustainable. Theory, then, will occupy a central position in the digital humanities, and we need more of it rather than less, but we also need to remind ourselves that unlike other disciplines we’re building systems: systems of code, systems of metadata……the list goes on. Unlike other humanities disciplines, our theory needs to be what I will clumsily term ‘systemically functional': it needs to support not only our cultural and intellectual needs, but our technical needs. This is no small task, in fact I suspect it’s a ‘big hairy goal’ that will remain aspirational for a long time in lieu of anyone getting a grasp on what’s really required, but it strikes me that it’s a task worthy of our attention. Right now, it’s probably time for a glass of wine.