Since returning from my second DHSI, I’ve had a little time to reflect on my experience and to bask in the glory of my new—but still fledgling—programming skills. Like Chris, Emily, James, and Mathieu, I spent last week happily enrolled in Josh and Zailig Pollock’s course on “A Collaborative Approach to XSLT.” And, like my classmates, I was encouraged to embrace aspects of what the instructors referred to as an “Agile development method” (in essence, an iterative and adaptive approach to coding and project management). As we worked through exercises to reinforce each of the day’s lessons, we learned to test and tweak our code obsessively, and in this small way we began to see how an “agile” approach to DH projects might prove valuable on a larger scale.
For the benefit of those who haven’t read it, the “Manifesto for Agile Software Development” reads as follows:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on
the right, we value the items on the left more.
(Source: agilemanifesto.org; emphasis added)
As one can see, the agile method offers a number of practical, even common-sense suggestions that can be usefully incorporated into most collaborative DH projects. In terms of my own DH work—and I’m thinking specifically here of my role in getting the Canadian Modernist Magazines Project up and running—an agile workflow or development approach will likely benefit the project in several ways. For example, I hope to successfully model the agile method’s emphasis on openness (to collaboration, to changing tools and conditions in the digital landscape, or even to the overall direction of the project). Perhaps even more importantly, however, I want to avoid being paralyzed by obsessive over-planning or inflexible long-term projections; instead, I want to work incrementally, letting each small step or misstep guide the next. The reality is that any new DH project is the product of innumerable blunders and misgivings, just as any “polished” essay is (in my experience) the product of multiple drafts and, initially, ill-conceived thoughts or malformed sentences.
Finally, I think it’s important for institutions that wish to support DH projects to recognize, and perhaps to help mitigate in some small way, the institutional pressures that confront English literary critics qua DH scholars in their work as DH scholars. But I guess what I really mean to advocate is an understanding of the similarities between literary critics and programmers or DHers, not the differences that make collaboration between them a potentially overwhelming undertaking. As those of us who have been lucky enough to participate in DHSI are well aware, the literary critic and the technogeek no longer occupy mutually exclusive domains. While I acknowledge the dangers of getting entirely immersed in the DH world and thus neglecting to hone one’s unique skills as a literary critic, I also acknowledge the need to constantly re-think my own research in light of rapidly changing disciplines, departmental practices, and institutional exigencies. So thank you for the education, Josh and Zailig—and thank you, EMiC, for another great week at DHSI.