[submitted by Marc Muschler]
Over the course of the last several weeks I have attempted to code a modular adapter for NewRadial. Adapters are what make NewRadial work so efficiently; they allow for communication between NewRadial and a database by converting the responses received from a web service into the native format that NewRadial utilizes. Because web services do not all use the same application programming interface, it is necessary to create an adapter for each database that allows for the use of the stored information within NewRadial’s visual environment.
As a primarily humanities-oriented graduate student with a total lack of programming experience, coding an adapter is both intriguing and challenging. This adapter gives me the chance to learn a skillset that is increasingly important in a digitized academic environment. But, I am faced with learning an entirely new language that I have never encountered before. Little did I know, one of the most significant dilemmas I would face was not in the programming, but engaging with the development documents of my predecessors on the NewRadial project which, while written in English, were, at times, just as confusing to me as the code itself.
Our team makes substantial use of the work of Jake Bruce, a former Acadia University student who helped code NewRadial for his Computer Science Honours thesis. He established the building blocks off of which the NewRadial team operates today, and therein lays some of the fundamental issues of communication that have further complicated the process of understanding and learning about how to program an adapter. Of the many useful tools that Jake made available to us, I have found that his “coding sample” was invaluable to my current adapter project. Jake created a step-by-step guide to creating an adapter, theoretically allowing any programmer to create an adapter that would call data from databases which resemble those that NewRadial already communicates with. As useful as this text is, there is a significant discrepancy between Jake’s use of language and my own disciplinary vocabularies which highlights one of the fundamental difficulties of developing NewRadial across an interdisciplinary team: communication between different disciplines and between previous and current programmers.
One of the issues that exist within the English language is how our understanding of its use can differ so drastically from person to person. What might seem logical to one individual does not necessarily make any sense to another. This problem is not particular to NewRadial as it abounds in nearly every facet of language use. From reading a friend’s paper to trying to discern one’s own late night ramblings during a thesis editing session, it is very easy to see how widespread the issue of communication can be when trying to sort through the logic of a piece of writing.
This is by no way a negative commentary on the excellence or efficiency of Jake’s work, merely a discussion of how the perception and professional use of language can complicate the process of understanding. Jake’s use of language within his step-by-step guide is utilitarian and specific – the wording is quite sparse and logical, but logical from the perspective of a programmer familiar with terminology associated with that task. From the perspective of someone who has literally never attempted any sort of programming, this presents a significant issue.
With this in mind, how can we get around this issue? In the context of NewRadial, the answer was simple: communication with other programmers currently working on the project. I was able to meet with Ian, NewRadial’s current programmer, and reinterpret Jake’s guide to adapter programming. With Ian’s help I was able to make sense of many of the unfamiliar terms and processes which Jake discusses, thereby making the task of coding somewhat more intuitive on my end. Not only will this benefit myself in my own attempts to program an adapter, but it will also (hopefully) benefit future literature students working on NewRadial as I hope to outline the process for a more generalized reader in my own guide.
While there was a relatively simple solution to my own predicament, what is not so simple is the greater issue that this discussion reveals. In an increasingly digitized academic environment, I believe that such distinctions will only continue to proliferate, potentially complicating the process of working within interdisciplinary teams on digital humanities projects in the future. Adding to this potential concern is the high turnover of graduate research assistants which could result in further communication breakdown on projects with a longer development cycle (like NewRadial). While it is great to get new people involved and interested in these projects, it is necessary to establish some sort of bridge in communication that allows for a streamlined approach to working on projects that take several years to program and maintain. One solution would be to involve humanities students in the process of computer programming at an earlier stage in their education, and to make sure that those with such knowledge are able to represent necessary processes within any digital project to their team members. Either way, it is important to acknowledge how these communicative difficulties can affect progress on a project and to address them in a way which not only benefits those currently addressing the issue, but also takes into account any future concerns that may arise from similar problems.
However difficult this project was at its onset and continues to be, the thinking processes involved in learning how to code a new language have contributed greatly to expanding upon my somewhat restrictive disciplinary mindset, allowing me to the approach any problem, particularly in the Digital Humanities, from an interdisciplinary perspective. Indeed, this is probably one of the most significant advantages of the Digital Humanities interdisciplinarity as a whole.