Introduction

In a recent anthology, Switching codes: Thinking through digital technology in the humanities and the arts, computer scientist Ian Foster forecasts two ways in which computation will transform humanities research over the next two decades: enabling unprecedented access to research materials and research products, and facilitating new epistemic modes centered on modeling, quantitative analysis, and "massive collaboration" (Foster 2011, 16). Those transformations are already underway. Massive digital repositories like Google Books (http://books.google.com), the Internet Archive (https://archive.org), the Biodiversity Heritage Library (http://www.biodiversitylibrary.org/), and the HathiTrust Digital Library (http://www.hathitrust.org/) provide access to millions of digitized books, periodicals, and research publications. Many traditional brick-and-mortar archives have followed suit. The United States National Endowment for the Humanities asked Congress for $4.45 million in 2014 to support digital and computational projects, ranging from digitization projects to cross-disciplinary workshops that explore methodological transfer from the natural sciences to big-data problems in the humanities (NEH 2013). At the same time, individual scholars are taking up computational tools and techniques to address smaller-scale problems in their own research. The uptake of new techniques from computational linguistics, information retrieval, and machine learning by humanists suggests widespread eagerness and enthusiasm for quantitative and computational modes of inquiry (Laubichler et al. 2013; Meeks and Weingart 2012).

The computational turn has precipitated two pressing sets of needs at the interface of computer science and the humanities: (1) the need for sustainable software development projects that are specifically focused on humanities research problems, and (2) the need for graduate and undergraduate training models that address the trans-disciplinary nature of digital and computational humanities research (Ramsay 2012; Reid 2012). In this paper we use the terms "digital humanities" and "computational humanities" interchangeably. Some authors distinguish between the two terms on the basis of "scale and technical sophistication" (Manovich 2012). We think that our arguments apply to projects at all scales, from online exhibits to social influence modeling.

Moving digital humanities forward will require bringing the full scope of humanistic methods and theories together with the most advanced computational approaches to bear on what is now a veritable ocean of digital data. This means developing software that specifically addresses humanities research problems. We use the term "software" to refer not only to desktop applications, but also to web applications (e.g. Voyant, http://voyeurtools.org/) and web services (software designed to support machine-to-machine interaction [W3C 2004]). As Meeks (2011) observes, "nothing is truly built for humanists, the closest we can get is something built by humanists." Appropriating tools and methods from other disciplines can be a powerful form of innovation in a research field, and many tools from fields like computational linguistics and bioinformatics are certainly applicable to problems in the humanities. But methodological transfer involves some degree of intellectual risk, as it may "foster a situation where rich, sophisticated problems are contracted to fit conveniently into software" (Meeks 2011). Inverting that situation by developing humanities-centered software will require close collaboration between software developers and researchers from a wide array of humanities fields. As Borgman (2009) observes, "[o]nly those who do the work and who require the infrastructure are in a position to take the field forward. […] Technology developers are essential partners, but those who conduct the research must take the lead."

It is important to recognize that although programming and software engineering both fall within the domain of computer science, there are substantive and consequential differences between them. Programming is the writing of code with a particular computational objective in mind. Software engineering goes beyond programming, and includes considerations such as software architecture and design, lifecycle management, project management, and long-term maintainability. Software engineering requires training that goes well beyond simply learning programming languages and concepts. We believe that this distinction has important consequences for how we conceive of digital humanities research and training.

Although there are exceptions, it is uncommon for scholars with advanced training in the humanities to possess an equivalent level of training in computer science (Hayles 2012). In recognition of this training gap, many digital humanities programs are moving to incorporate computer science courses in their degree and certificate programs, but this is not yet the norm. In a survey of 25 digital humanities degree and certificate programs, we found that only 12 programs offered elective programming courses, and only one of those programs required programming coursework (see supplementary materials for details). Most importantly, of those that offered programming courses, only 5 programs offered elective courses in software engineering (e.g. software design principles and software lifecycle management). Students who participate in digital humanities certificates and degree programs will serve as crucial bridge-builders between those who develop software and humanities researchers, will be well-equipped to manage digital projects and technologies, and will be able to develop limited programming solutions for specific computing problems. In this sense we agree with Moulin et al. (2011) that digital humanities training should produce "mediators" between "traditional" and "non-traditional" communities. But it is rarely the case that even the "Expert" digital humanists described by Moulin et al. (2011)—those who can produce new technology for computational humanities—possess the requisite training and experience to develop robust, sustainable, and user-friendly software. Although computer science training, including training in high-level programming and computational modeling, is a worthy desideratum (and, in our view, ought to be required) for all scholars, the programming humanist is ultimately not a replacement for a trained software engineer. Indeed, such a situation may not be desirable in the first place.

Thus, as in the life sciences, doing digital and computational humanities right necessarily involves close collaboration between humanities scholars and software engineers. Arguments similar to the ones above are also made by Bradley (2009, 2012). If humanists are to play an active role in shaping the computational tools and techniques available to them, they need to be able to communicate effectively with software engineers (Hayles 2012). This entails more than merely articulating a set of design or functionality requirements: humanists need to be able to navigate the world of computer science concepts, technologies, and software design principles. As Drucker (2009, B6) notes, we cannot just "leave it to them." Likewise, software engineers working on digital humanities projects need to be sensitized to the modalities of historical, cultural, and philosophical analysis.

We have struggled with both of those needs in the context of digital and computational history and philosophy of science (d/cHPS) research in the Center for Biology and Society at Arizona State University. In this paper, we describe one approach for addressing those two challenges simultaneously: an interdisciplinary research and development team called the Digital Innovation Group (DigInG, http://diging.asu.edu), created in late 2012. DigInG quickly and necessarily became an experiment in trans-disciplinary education at the interface of digital humanities and computer science. As we consider the need for more direct engagement between digital humanists and software engineers, DigInG may provide a useful model. In this paper, our primary objectives are to broaden the discussion about how digital and computational humanities programs are organized, and to suggest that software development and training in the digital humanities need not be conceived as independent activities.

Background

The Center for Biology and Society has been engaged in d/cHPS projects since 2006, most notably the Embryo Project and its accompanying online encyclopedia (http://embryo.asu.edu). One of the objectives of the Embryo Project was to compile historical relationships among people, institutions, events, experiments, and other concepts in the history of embryology in order to reveal connections between embryological science and its cultural contexts (Laubichler et al. 2007; Maienschein and Laubichler 2010). Workshops stemming from the Embryo Project led to the international Digital HPS Consortium, formally established in April 2011, which meets annually to discuss research, tools, and infrastructure (http://digitalhps.org). The Consortium, in turn, has organized workshops and training events at international conferences for history and philosophy of science. The Embryo Project has also resulted in training programs in digital humanities for visiting PhD students and post-doctoral researchers from other institutions.

In addition to generating peer-reviewed articles for the Embryo Project online encyclopedia, an early research goal was to encode historical relationships in a structured format that was interpretable by machines, but that also respected the historicity of concepts and institutions across the dataset. Such a structured dataset was originally used to aid navigation among related content on the EP encyclopedia, but also allowed us to use network analysis and visualization techniques to reveal unexplored patterns and relationships in the history of embryology. Starting in 2009, one of us (JD) developed a prototype desktop application called Vogon (http://gobtan.sf.net) that allowed researchers to encode contextualized semantic relationships (contextualized triples, or "quadruples") in Embryo Project Encyclopedia articles. JD also developed a prototype of an online workflow environment and repository (Quadriga, http://diging.github.io/quadriga/), along with a few other web applications that support the annotation process (Peirson et al. 2013). Mounting interest in applying the Vogon-Quadriga system to other HPS research projects, and in expanding the scope of research in the Embryo Project, prompted us to consider options for developing those software packages into a robust and user-friendly research environment.

In December 2012, we hired two students from the Masters of Computer Science program in the School of Engineering at ASU to assist with developing those tools. We decided to hire student workers rather than contract with professional software developers because (a) we wanted more flexibility to scale the project as needed, and (b) we wanted to maintain a more intimate level of involvement in the development process. At the same time, we hired five B.S.-level Biology and Society majors (hereafter, "researchers") to implement test projects in order to evaluate the software as it was being developed.^[1] It soon became evident that more programming help would be necessary to develop the software of the Vogon-Quadriga research system to a point that would make it possible to use it for more than just exploratory projects. By the beginning of the summer of 2013, the group consisted of sixteen MS-level computer science students working as software engineers and five researchers. The size of the group has fluctuated slightly since then, as students graduate and move on to positions in industry and academia. Software engineers and researchers were funded in part by NSF grants and in part by internal ASU funds.

Organization and operation

DigInG is organized with two overarching objectives in mind: (1) fostering exchange and collaboration among humanities and computer science students on concrete digital humanities problems, and (2) providing training that dovetails with the development and research projects in which our students are engaged. Not only does DigInG play an important role in developing a computational infrastructure for d/cHPS research, it also creates an environment for hands-on training for graduate and undergraduate students in software engineering and digital humanities—not as separate activities, but as aspects of a single process. Students in the humanities gain valuable experience working with software engineers, and software engineers are given an entry-point into interesting problems in digital humanities.

Many universities now house centers for digital humanities that provide consultation and support—including infrastructure and software development—to humanities faculty. Graduate and undergraduate training in digital humanities is frequently treated as a separate activity, although a few centers do offer internships (for a more detailed discussion refer to Warwick [2012]). DigInG was initially conceived as a software development project, but it quickly took on a strong educational component. Although DigInG resembles in some ways "an ordinary arrangement in which graduate-level computer science students are contracted to work on a project related to the humanities," (Anon., pers. comm.) it differs in the following respects:

1. While general direction is given by faculty, the organization and operation of the group is driven by students;
2. The process of developing the software as an educational activity is of equal importance as the software products themselves;
3. Graduate and undergraduate students who participate in digital humanities research are intimately involved with the software engineers and the development process.

This kind of arrangement is not particularly radical from the perspective of computer science training, since internships are often either part of a computer science curriculum or are pursued voluntarily by students in parallel to their coursework. We are in effect capitalizing on that internship model to advance digital humanities training and software development.

The "mental models" of software engineers and humanities researchers sometimes differ considerably (Müller-Birn 2014). For example, a software developer might focus on developing a new feature that she would think makes the software more usable, while a researcher might never use that feature. On the other hand, something as simple as duplicating a button so that it is available in different places of a program can expedite a workflow considerably and might help the researcher much more. We found that those challenges could only be addressed through frequent and candid interactions among software engineers and researchers.

We foster exchange and collaboration among humanities and computer science students by forcing them into close interaction in all stages of our projects. First, we adopt the agile software development method, which emphasizes adaption to changing requirements and constant communication between users and developers (Stoica et al. 2013; Beck 2001). For example, researchers and developers participate in weekly iteration meetings and product-specific focus-groups to present and critique their latest work, and to discuss ideas for new features and functionality. Second, the software development and research teams work in the same physical space, and their workstations are intermingled. This arrangement maximizes opportunities for spontaneous interaction. It also decreases latency in the bug-fixing and feature-development process: a researcher who encounters a problem can simply turn to their neighbor, a developer, who can directly observe whatever is plaguing their colleague. Third, we delegate responsibility for documenting software and workflows to both developers and researchers. The process of articulating the structure and operation of software in writing forces both the developers and the researchers to form a more sophisticated understanding of their colleagues' work, and in doing so learn to communicate outside of their own discipline.

We dovetail research and development projects with targeted training in several ways. For the developers, we provide regular group meetings to discuss best practices and architectural concepts, such as software design patterns and frameworks, that arise directly from the developers' current tasks.^[2] Often the basis for those discussions are code reviews. For the researchers, we facilitate frequent informal discussions about the theoretical implications of various facets of our software. For example, discussions often center on how specific software design decisions can impact the visibility of historical processes or actors. We also provide hands-on training in technologies that support the software development process, such as documentation tools, version control systems, and integrated development environments (IDEs). We place a great deal of emphasis on open source practices. The source code for all of our software lives in publicly accessible version-controlled repositories, either on GitHub or on SourceForge.

Outcomes

We did not anticipate the extent to which DigInG would become an educational enterprise, especially for our software engineers, rather than merely a software development and research project. Most of our developers were incoming master's students and, although some had industry experience, most had strong theoretical backgrounds but very little hands-on engineering experience. We found that the computer science curriculum at ASU did little to ameliorate that problem, and conversations with workers in industry corroborated our observations. This meant that we spent a great deal of time mentoring our developers, both individually and in groups. While this did require a much greater investment of time (especially JD's) than we had anticipated, the educational dimension of DigInG was ultimately a significant factor in its success. As the software development group grew, more senior members of the team played an increasingly significant role in training their peers.

The team-oriented development model and educational emphasis of DigInG yielded a stronger focus on documentation and software design principles than might have been realized by a single developer working alone. While high-quality documentation should be a priority for any software development project, in practice it may lag behind other activities due to tight production timelines. Since the developers were building on each other's work on a daily basis, and participated in regular code reviews, they were forced to frequently justify, clarify, and revise their code. This made such neglect nearly impossible.

For the developers themselves, participation in DigInG had, to our surprise, an enormously positive impact on their careers. According to Liu (2005), "[t]o nurture student's appreciation of software engineering principles and to sharpen their skills of applying software engineering techniques, it is instrumental to expose students to complicated real-world projects in software engineering courses" [p. 613]. The University of Stuttgart follows a similar approach in their software engineering curriculum: students undertake one-year team projects, in which they develop software under real-world conditions (Müller et al. 2012). Müller et al. (2012) found that those projects improved both social and software engineering skills by presenting them with problems and situations—such as communicating with users, or organizing a team—that they were likely to experience later in their professional careers. Nearly all of our developers reported that their experience working in that environment, and the regular feedback and mentorship from a more senior engineer (JD), was decisive in obtaining highly competitive jobs and internships in industry.

Participants learned to explain problems to their peers in ways that avoided technical jargon and crossed disciplinary lines by working in close quarters over a prolonged period of time. One humanities student noted that his experience at DigInG was his first opportunity to interact with computer scientists, and that one of the most valuable outcomes of that experience was, "learning to formulate questions in ways that computer scientists and software developers can understand." For example, an important skill for researchers in digital humanities is to write feature requests or a bug report that describe a problem or desired enhancement of software in such a way that a developer can effectively address it. Humanities students in DigInG learned how to write clear and useful issue reports by getting direct feedback from the developers. The agile development methodology implemented in DigInG made regular exchanges between software engineers and humanities researchers unavoidable. Direct and repeated contact between humanists and computer scientists provided students in both disciplines with a communication skill-set that prepares them for the interdisciplinary environment of digital humanities.

Working alongside computer scientists meant that our student researchers were exposed to tools and technologies that they would not likely have encountered otherwise. For example, researchers who assisted with documentation learned to use code repositories and version control systems, as well as text mark-up languages. They also learned about agile project management, which prepared them to participate in future software development projects. Several students with no prior knowledge of programming picked up sufficient skills in Python that they could incorporate coding into their own research. Students noted that they benefited from exposure to Linux operating systems, GitHub, and other technologies. One student reported that he gained a deeper appreciation of software engineering, noting that sustainable software development meant "going beyond syntax."

Beyond simply learning new tools, however, student researchers gained deeper insight into what it means to pursue humanistic questions computationally, and what is possible in digital humanities and data science. Of the six student researchers that worked with us since 2012, four have employed computational techniques in independent research projects. Three of them have gone on to pursue MS or PhD projects that involve significant computational research, and as a result of their experience at DigInG are now learning high-level programming languages.

Discussion

Perhaps the most significant challenge for digital humanities is translating humanistic questions and problems into a computational framework. Overcoming this challenge will be impossible without graduate and undergraduate training models that address the trans-disciplinary nature of computational humanities research. Part of the translation problem is bridging the "language gap" between computer scientists and humanists. Although a computer scientist and a humanist may both speak the same language, the words that they use can be very different and can have radically different meanings. Terms from computer science like "API," or "web service," may be completely unintelligible to humanists. Likewise, words like "ontology" mean something quite different in computer science versus the humanities.

Another component of the translation problem is creating a theoretical scaffold that can link the nuanced, qualitative, hyper-contextual modalities of humanities research to the highly structured and quantitative modalities of computation and computer programming (De Smedt 2002). McCarty (2007) suggests that this problem is insurmountable unless humanists and computer scientists are willing to become "participant-observers" in their contrasting fields. One way to address the translation problem is to train students in computer science as well as the humanities in order to create "hybrid experts." Several programs currently exist or are in planning that follow this approach (see for example Stanford's CS+X program). A different strategy is to prepare students for collaborations with experts from a different discipline. DigInG realizes this idea by directly linking software development and hands-on research training in digital humanities.

Digital humanities is not the only domain dealing with the challenges that we have described. For example, the field of biomedical imaging is facing a situation in which many domain experts have "serious programming expertise, but typically […] will not follow the professional software engineering practices necessary for production-grade software and will be similarly unmotivated to support the software" (Cordona and Tomancak 2012, 662). Cardona and Tomancak (2012) contended that the impact of the computational turn in bioimage informatics "will not be realized without better support and recognition of software engineers' contributions to the biological sciences," and called on their peers to "engage in productive collaboration with computer scientists and programmers" (p. 661). Part of the solution to which Cordona and Tomancack gesture is to better communicate the professional and intellectual value for computer scientists of addressing biomedical imaging problems. Similarly, digital humanities can and should pose questions that are challenging and interesting to professional computer scientists. For example, rather than merely importing text mining and machine learning algorithms designed for non-humanities applications, digital humanists should more often articulate how their fields generate unique analytic and classificatory problems that require new mathematical and computational techniques, as exemplified by Burrows (2002).

Creating sustainable software requires not only engaging the right expertise in appropriate ways, but also fostering communities of users and engineers that can grow beyond the confines of a single project or institution. As Cardona and Tomancak (2012) note, open source communities are a "natural interface" for domain scholars to work with computer scientists and engineers. Although most scholars are comfortable with the moral and intellectual imperatives of sharing their source code and data, some of the more transformative practices within the open source software development model are surprisingly under-utilized in digital humanities. One common misconception among scholars is that "open source" means sharing their code upon completion of a project or upon publication of a manuscript, where "sharing" might mean merely providing source code upon request. In an informal survey of 44 digital humanity software projects gleaned from the proceedings of the Digital Humanities 2014 conference (see supplementary materials), only 21 had made source code available in a version-controlled repository (e.g. GitHub, SourceForge). Jeremy Boggs' (2010) observations are apt: "Digital humanities is getting really good at shopping/browsing at the [open source] bazaar, but not actually sharing… very rarely are we actually giving back, or making the development and sharing of open source code a central part of our work." Sharing source code in a publicly accessible repository at the start, rather than at the end, of a project opens up new spaces for engaging users in the development process (e.g. through bug reporting and feature requests), and can invite contributions from unexpected stakeholders. Open source practices not only lead to better software, they also directly enable and facilitate one of the most transformative promises of digital humanities: building communities of scholarship that can move the humanities out of the dark corners of the library stacks. We speculate that resistance to code sharing is often driven either by a scholar's fear of embarrassment over poorly-written or under-documented code, or by a desire to retain control over the development or use of the software. We assert that such reticence is harmful both to the scholarly community and to the development and uptake of the software itself. We suspect that where open sources practices have been adopted, this has been driven by the participation of software engineers who have experience with code-sharing and software lifecycle management.

In the best possible case, digital humanities programs and projects would have abundant and institutionalized access to professional software engineering support. Except in the context of university libraries and some research institutes, however, this is rarely the case. Lucrative entry-level salaries draw software engineers into industry, and thus there is a dearth of this expertise available for grant-funded projects in academia. Concepts like the Digital Innovation Group can alleviate this problem while at the same time providing valuable experiences for undergraduate and graduate students in computer science and the humanities. Although many of the details of the implementation of the Digital Innovation Group are specific to our institutional context, we believe that the practice of training software engineers together with humanities scholars, and combining that training with humanities-centered software development, is a transferrable and potentially transformative model for a wide range of digital humanities projects.

Conclusion

The Digital Innovation Group model involves collocating humanities and computer science students for research, software development, and training. We argue that this approach can begin to address the pressing need for sustainable software development projects that are specifically focused on humanities research problems, as well as the need for graduate and undergraduate training models that address the trans-disciplinary nature of computational humanities research. By working and learning in close proximity, both humanities students and computer science students acquire a wide range of skills and sensibilities that are not likely to be cultivated in other contexts. Most importantly, they learn what it means to conduct trans-disciplinary research, paving the way for a more resilient, inclusive, and sustainable digital humanities.

Acknowledgments

We are forever indebted to Jessica Ranney, Program Manager of the Center for Biology & Society, for her exceptional generosity and guidance in all aspects of DigInG operations. None of this would have been possible without her. We would like to thank all of the DigInG software engineers and student researchers: SatyaSwaroop Boddu, Viraaj Navalekar, Prajakta Samant, Ashwin Prabhu Verleker, Sowjanya Ambaii, Kiran Batna, Veena Borannagowda, Bhargav Desai, Karthik Jayaraman, Karan Kothari, Ram Kumar Kumaresan, Dwaraka Lohith, Sayalee Mehendale, Rohit Pendbhaje, Chetan Ambi, Ramki Subramanian, Kenneth Aiello, Victoria Calvelage, Divyash Chhetri, Samantha Hauserman, Deryc Painter, R.V. Raptorius, and Bianca Zietal. Contributions from BREP based upon work supported by the National Science Foundation Graduate Research Fellowship Program under Grant No. 2011131209, and NSF Doctoral Dissertation Research Improvement Grant No. 1256752. This material is based on work supported by NSF SES 1243575, NSF SES 1127611, NSF SES 0645729, and Presidential Initiative Funds from ASU.

Works Cited / Liste de références

Beck, Ken, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, and Dave Thomas. 2001. "Manifesto for agile software development." Last modified 2001. Accessed May 6, 2015. http://agilemanifesto.org/

Boggs, Jeremy. 2010. "Participating in the Bazaar: Sharing code in the Digital Humanities." ClioWeb (blog), June 10. http://clioweb.org/2010/06/10/participating-in-the-bazaar-sharing-code-in-the-digital-humanities/

Borgman, Christine. 2009. "The digital future is now: A call to action for the humanities." Digital Humanities Quarterly 3.4, http://www.digitalhumanities.org/dhq/vol/3/4/000077/000077.html

Bradley, John. 2009. "What the developer saw: An outsider's view of annotation, interpretation and scholarship." Digital Studies/Le champ numérique 1, http://www.digitalstudies.org/ojs/index.php/digital_studies/article/view/143/202

Bradley, John. 2012. "No job for techies: Collaborative modelling as an intellectual activity of the analyst and scholar." In Collaborative research in the Digital Humanities, edited by Marilyn Deegan and Willard McCarty. Farnham, Surrey: Ashgate Publishing.

Burrows, John. 2002. "'Delta': A measure of stylistic difference and a guide to likely authorship." Literary & Linguistic Computing 17.3 (September): 267–287. http://llc.oxfordjournals.org/content/17/3/267.short?rss=1&ssource=mfc

Cardona, Albert, and Pavel Tomancak. 2012. "Current challenges in open-source bioimage informatics." Nature Methods 9.7: 661-665.

De Smedt, Koenraad. 2002. "Some reflections on studies in humanities computing." Literary and Linguistic Computing 17.1 (April): 89–101. http://llc.oxfordjournals.org/content/17/1/89.abstract?sid=9c7e3a48-efc2-4868-a4e0-d22040944130

Doerr, Martin. 2003. "The CIDOC conceptual reference module: An ontological approach to semantic interoperability of metadata." AI Magazine 24.3 (Fall): 75–92. http://www.aaai.org/ojs/index.php/aimagazine/article/view/1720

Drucker, Johanna. 2009. "Blind spots: Humanists must plan their digital future." Chronicle of Higher Education 55.30: B6. Accessed January 22, 2016. http://chronicle.com/article/Blind-Spots/9348.

Foster, Ian. 2011. "How computation changes research." In Switching codes: Thinking through digital technology in the Humanities and the Arts, edited by Thomas Bartscherer & Roderick Coover, 15–37. Chicago: The University of Chicago Press.

Hayles, N. Katherine. 2012. "How we think: Transforming power and digital technologies." In Understanding Digital Humanities, edited by David M. Berry, 42–66. Basingstoke: Palgrave Macmillan.

Laubichler, Manfred D., Jane Maienschein, and Grant Yamashita. 2007. "The Embryo Project and the emergence of a digital infrastructure for history and philosophy of science." Annals of the History and Philosophy of Biology 12: 79–96.

Laubichler, Manfred D., Jane Maienschein, and Jürgen Renn. 2013. "Computational perspectives in the history of science: To the memory of Peter Damerow." Isis 104: 119–130.

Liu, Chang. 2005. "Enriching software engineering courses with service-learning projects and the Open-Source approach." In Proceedings of the 27th international conference on software engineering, New York, NY: ACM, 613–614. Accessed May 15-21, 2005.

Maienschein, Jane, and Manfred D. Laubichler. 2010. "The Embryo Project: An integrated approach to the history, practices and social contexts of Embryo Research." Journal of the History of Biology 43: 1–16.

Manovich, Lev. 2012. "Computational humanities vs. digital humanities." Software studies initiatives (blog), March 16.http://lab.softwarestudies.com/2012/03/computational-humanities-vs-digital.html

McCarty, Willard. 2007. "Beyond retrieval? Computer science and the Humanities." Plenary lecture for the CATCH midterm event, Den Haag, Netherlands, November 30, 2007.

Meeks, Elijah. 2011. "Digital Humanities as thunderdome." Journal of Digital Humanities 1.1 (Winter). http://journalofdigitalhumanities.org/1-1/digital-humanities-as-thunderdome-by-elijah-meeks/

Meeks, Elijah, and Scott B. Weingart. 2012. "The Digital Humanities contribution to topic modeling." Journal of Digital Humanities 2.2 (Winter). http://journalofdigitalhumanities.org/2-1/dh-contribution-to-topic-modeling/

Moulin, Claudine, Julianne Nyhan, Arianna Ciula, Margaret Kelleher, Elmar Mittler, Marko Tadić, Maria Ågren, Andrea Bozzi, and Kristin Kuutma. 2011. "ESF science policy briefing 42. research infrastructures in the Digital Humanities." Accessed December 8, 2015. http://www.esf.org/fileadmin/Public_documents/Publications/spb42_RI_DigitalHumanities.pdf

Müller, Christoph, Guido Reina, Michael Burch, and Daniel Weiskopf. 2012. "Large-scale visualization projects for teaching software engineering." IEEE computer graphics and applications 32.4: 14–19. doi: 10.1109/MCG.2012.81.

Müller-Birn, Claudia. 2014. "Informatik trifft Geisteswissenschaften." Campus.leben, February 25. Accessed May 15, 2014. http://www.fu-berlin.de/campusleben/forschen/2014/140225_digital-humanities/index.html

National Endowment for the Humanities. 2013. "Appropriations request for fiscal year 2014." Accessed March 3, 2014. http://www.neh.gov/files/neh_request_fy2014.pdf

Peirson, B. R. Erick, Julia Damerow, and Manfred D. Laubichler. 2013. "Don't panic! A research system for network-based digital history and philosophy of science." Paper presented at Future of historical network research conference, Hamburg, Germany, September 13-15.

Ramsay, Stephen. 2012. "Programming with humanists: Reflections on raising an army of hacker-scholars in the Digital Humanities." In Digital Humanities pedagogy: Practices, principles and politics, edited by Brett D. Hirsch, 227–239. Cambridge, UK: Open Book Publishers.

Reid, Alexander. 2012. "Graduate education and the ethics of the Digital Humanities." In Debates in the Digital Humanities, edited by Matthew K. Gold, 350–367. Minneapolis: University of Minnesota Press.

Stoica, Marian, Marinela Mircea, and Bogdan Ghilic-Micu. 2013. "Software development: Agile vs. traditional." Informatica Economica 17: 64–76.

Tichy, Walter. 2010. "The evidence for design patterns." In Making software: What really works, and why we believe it, edited by Andy Oram and Greg Wilson, 393–414. Sebastopol: O'Reilly Media, Inc.

W3C. 2004. Web services glossary. Accessed December 15, 2015. http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/

Warwick, Claire. 2012. "Institutional models for Digital Humanities." In Digital Humanities in practice, edited by Claire Warwick, Melissa Terras, and Julianne Nyhan. London: Facet Publishing.