Marie-Claire Beaulieu and I have a running joke between us playing on the difference between “professing” and “hacking.” When we have a Perseids Project hackathon, the hackers “hack” and the professors “profess.” This is meant to be funny, but it also exposes a more serious question — how, in a digital humanities project, do you manage the different approaches and expectations developers and humanists bring to project in a way that is productive and encourages rather than discourages continued collaboration?
The inspiration for this blog post comes from our presentation at DH 2015 in Sydney, “Building Tools that Build Digital Humanists.” This paper was actually mistitled in a way that highlights this very point of potential disconnect — what we should have called it was something like “Building tools while building Digital Humanists” because otherwise it implies that the tools themselves provide the magic solution of how to develop digital skills. Eliminating the tool as black box is a primary motivator behind many of the design decisions we make on Perseids. Exposing humanities scholars, researchers and students to the inner workings of the software tools we build for them, the raw data on which they operate, and the development process itself has resulted in some unexpected benefits and challenges.
We have been following what I call an Agile-inspired approach to building tools for Perseids. We engage the users at every step of the process, releasing features for them to work with well before the tools are fully finished. This is a fairly common practice in software development, but it introduces some unique challenges in academic environments, where programming and other resources are typically in much shorter supply, and where we often cannot finish what we start. Agile methods take for granted that there will be another sprint.
It sometimes feels a bit like looking for the silver lining in the clouds, but we have found that using tools mid-development with constant, and maybe even a bit too in-your-face, access to the raw data structures can open a window into exactly how the tools let users manipulate and shape the data. The process has allowed both students and researchers to understand their role in the creation, curation and annotation of texts through the scientific process of creating and using the data. It has also exposed the critical role the humanist plays as product designer and tester of the tools we develop to support the research and publication process. Or, as Stephen Ramsay says, as “builders and makers.” (Ramsay, Stephen. (2011). “On Building.” http://stephenramsay.us/text/2011/01/11/on-building/ )
It also builds their digital skills. We have scholars working with us who, prior to becoming involved in the project, had no programming background or experience with XML files, and are now developing their own analytical tools and services in XQuery and managing their JSON configuration files through GitHub. One researcher, initially very hesitant about her computer skills and afraid of breaking the system, is now our star quality assurance expert who eagerly tests new releases and can be counted on to find and report the bugs within hours if not minutes. Enterprising students and professors have become emboldened to develop additional solutions that cleverly work around current limitations in the system and which inform our design process and feature list.
It’s not all roses though. Our development approach of rapid prototyping has led to many misunderstandings about exactly how experimental certain features are, and dashed hopes about how soon things that we trial can be brought to readiness for actual use.
Another real challenge is that for projects that are funded in spurts you want to try to make sure that the code you write can be easily taken up and added to by new developers, but with code that changes so rapidly, keeping documentation up to date can be daunting and it is often the first thing that has to go when time runs short.
I am trying to be better about managing expectations about what we can realistically do by when, and imposing discipline in the form of requiring user stories and well defined requirements for new features, but as a developer in this environment it is not always easy to say no, especially when it’s the shiny new features that grab attention, while the amount of work needed to make them real is not always easily justifiable.
I think it’s worth it though. One of my favorite quotes from the group of scholars who make up our ad-hoc software development team on Perseids is the following, from Drs. Robert and Vanessa Gorman of the University of Nebraska Lincoln:
“The principal power of the Perseids/Arethusa system is the information it puts into the hands of student and instructor.”
It is this perspective that keeps me going when I’ve had to explain for the upteenth time why the system looks and feels a bit like Frankenstein. We have quite enjoyed working with the monster in our lab here, and we feel that it is precisely this wires-exposed nature of Perseids that is inspiring and fosters learning and experimentation.