Theory, DH, and Noticing

There was a renewed flurry of thinking and observing about the relationship between theory and DH, especially around the "less yack/more hack" approach to THATCamps. I'd like to pick up a bit on the comment that I left on "When DH Was In Vogue; or, THATCamp Theory" , and respond a little to Jean Bauer's "Who You Calling Untheoretical?".

In my comment on "When DH Was In Vogue", I was worried about the perception that the THATCamp Bootcamps represented a colonizing of the humanisties by computer science, and argue that it's really the reverse. The Bootcamps are about the humanities pushing into computer science. Picking up from there, I feel a real tension about that. After all, the principles of writing code seem antithetical to much of how the humanities works. Coders like to keep things simple. We like to produce the most efficient algorithms, with very well-defined inputs and outputs. Especially with test-driven development, the code we write should have very precisely-defined functionality and purposes, and once written shouldn't change (or break).

Roughly, that's good coding, and good project management. Breaking those principles leads to scope creep, and to not getting projects done. A plugin for Omeka that I started years ago is still unfinished, because each time I built a new piece of functionality, I noticed that it could be expanded upon to produce new, more interesting results. Parts of the input (RSS/Atom feeds) could be interpreted in a variety of ways, and so I wrote code to make the various meanings explicit. There are assumptions and ambiguities built into the input formats that I wanted to unpack and explicate for the user.

"expand upon", "make various meanings explicit", "unpack and explicate". These are the words of a dissertation writer. I was writing code like I was writing my dissertation, which led to what a computer scientist or project manager will call scope creep.

That's why I'm so impressed with Jean's ability to build awesome things, with theory and the humanities in mind, and actually, you know, finish them.

But I'm not terribly surprised by the reaction that she describes, of people asking, "But where's the theory?" I'm not surprised, because, in general, I don't think theorists know what to notice yet. Our graduate programs are naturally still dominated by fairly traditional "texts", and theory rooted in them. And our theory has done a good job of complicating various notions of "text" (note to non-humanist coders: complicating ideas is a good and productive thing to theorists). Whatever our theoretical approach to whatever we are calling a text, we know what to notice in them. That's what much of our grad school training in theory is about -- what do we need to notice in the text, and how does our theory help us describe what we have noticed?

This is not surprising either, because unlike any of the various theoretical notions of text floating around, most people don't have an experiential grounding in database as text or API as text. As I said in my comment on "When DH Was In Vogue", one doesn't need to be a poet to do literary criticism on poetry, though the poet and critic will share a common knowledge base. But (unless you are a medievalist or classicist or doing comparative lit.) you don't need any special training to be able to begin noticing things in the text. You already know the language, and so you can begin your training in noticing right away.

Not so in the digital world. Indeed, a good user interface is designed specifically so that you don't have to deal with the inner workings of the application. In general, people should not see the internal structures of an application -- the database, the public and private methods in the core code. And so, there is no ability to even begin noticing what's notable.

This is where crit-code studies seems promising. There might be strong analogies to crit code training and methods and comparative literature, but that's something for someone more knowledgeable about both of them to figure out.

I'm not sure I'd go so far as to say that to do theory in/on DH one needs to learn to code or design a database. But one does need some training to be able to start noticing the difference between two data models that at surface appear to describe the same things. And, coders should be ready to learn what useful things theorists can offer that, despite a first appearance of scope creep, might just be valuable things to consider building into the code. 

As a concrete example, I sometimes fret over the centrality of the item in Omeka. An "item" is the fundamental unit of information, and we have lots of ways to describe them with metadata, mostly dublin core. But "items" can become complicated very quickly. Some of my fellow CHNMers are struggling with how to put scrapbooks into Omeka. Is the scrapbook the item, or is each individual thing in the scrapbook an item? Where do pages in the scrapbook fit in? I'm guessing that there is theory that could be useful here, and could lead to an Omeka plugin that is designed to implement a theoretical approach to scrapbooks that lets us work with a more complex notion of "item" in our data model. I need some theory to help me notice things about scrapbooks, and to help me notice things about Omeka's notion of "item".

Producing a plugin that complicates Omeka's model of "item" by consciously building theory into the code would be a great code hack in harmony with theory yack.