Journey or destination: Is software sustainability different in the humanities?

Posted by g.law on 5 February 2020 - 10:14am
Bird's eye view of complex motorway junction
Photo by John Lockwood on Unsplash

By Catherine Smith, Software Sustainability Institute Fellow, University of Birmingham

Last summer I attended the DH2019 conference as part of my fellowship and while there I attended many sessions about preservation and sustainability. I was quite surprised at how different the conversations were compared to those on the same topic that I had heard at Software Sustainability Institute and RSE events; while reference was often made to the importance of documentation, the use of automated testing and version control were rarely mentioned. One presenter did have unit testing on their todo list and the RSE teams involved in the sustainability panel did say they use testing as part of the software lifecycle but did not consider it part of preservation. I think that this is because the object being sustained is different in digital humanities projects: the destination matters more than the journey.

The main prompt for my thinking on this was a presentation by Greg Newton from The Endings Project. In his presentation he said that the only technologies the team advocate are HTML, javascript and css, all with no additional library dependencies such as jquery. I think that this list of technologies highlights the difference in the nature of what is sustained in the humanities compared to other research areas. It seems to me that in the humanities it is the end product that is the main focus when it comes to sustainability rather than the process by which that product was created. Several end products were discussed at the conference: interactive 3d models of historic sites, websites that allow people to interrogate data for their own research purposes, multimedia publications used to enrich our understanding of a particular text and many more. In all cases the researchers were concerned with sustaining and preserving this finished product more than the processes they used to create it.

This is certainly true for the kind of projects that I work on. I write tools that enable editors to make digital editions of ancient texts. The editorial tools themselves have many technological dependencies without which we would not have been able to create them. However,  we aim to make the editions produced with the tools available in a much more sustainable way. For example, the data is released as TEI P5 XML and the HTML view of the data uses nothing more than HTML, css and javascript. In this way we hope that the product itself will be more sustainable in the long term.

Documentation was a particularly important feature in most of the discussions at the conference. A useful analogy used by someone was that of a theatre performance where the performance itself is ephemeral but the meta-data around it such as programmes, prompt books, reviews and perhaps video or audio recordings still document its place in history.

This also works for the editorial tools that I build. Once they are no longer useful I would hope that the information contained in technical documentation, research project documentation and publications would enable people to understand what the tools did, why they were needed, how they were built, how they worked and what they produced. They do not need to be working in order for this information to be preserved. The methods we use for publishing the finished edition, the product, means that it will still be accessible without the tools used to create it.

If the object worthy of sustaining in digital humanities is the product rather than the process then this explains the different focus of the discussions I encountered at the conference. I wonder if other research areas also have this distinction when it comes to software sustainability and what implications, if any, this might have for reproducibility in digital humanities.


Want to discuss this post with us? Send us an email or contact us on Twitter @SoftwareSaved.