Rapid Bricolage

"Doing what we can with what we can get." - Philip Dwyer, C21CH

How to build a digital humanities practice at a University from the ground up, starting with almost nothing, with the C21CH lab as an example.

The approach as a whole is rapid bricolage, not just on projects but on developing DH in the institution.

At C21CH this has resulted in several major projects, one of great national interest with global impact, and many small projects, with many more underway.

Challenges

Firstly we will look at these terms 'Rapid' and 'Bricolage' and why they are suited to solving this problem. Secondly, we will look at the example of The Centre For 21st Century Humanities, and how this approach was used to build from nothing to successful projects and grow the centre. This may not be the only way but it has worked for us and I hope this provides a model that others with similar constraints can follow.

RAPID

'Rapid' is a relatively new, but now well established approach to software development and IT project management.

Main characteristics:

Rapid is typically contrasted with more traditional approaches, which are still suited for some circumstances.

An extremely 'Rapid' approach is particularly suited to research in digital humanities, and growing it at a University because:

Ideation: Some collaborators have difficulty imagining what is possible and feasible with IT, and what would be difficult. A 1 hour discussion followed by a basic visualisation or draft makes it immediately clear what might be possible, and what should happen when you click a button. In this way a few hours or days dev work can save months of discussions and associated costs. Gaps in functionality become immediately clear when they are not there.

Research: Research typically involves speculation so requirements usually change as we go. With fixed requirements Researchers might get what they asked for instead of what they needed without yet knowing it. We research because we don't already know the answer. A Rapid approach means the development can change direction and priorities as we go.

Real Outcomes: With a low budgets and limited attention, developing a prototype early ensures that at least some working software is produced as an outcome, even if the project is cut short or abandoned. This is better than being left with only talk and drafted proposals and requirements.

Builds Confidence: Even if cut short or prolonged, the prototype can be used to demonstrate capability and revived to gain more interest and investment later. Having produced a working piece of software is encouraging. This is important as academics, administrators and developers alike can be jaded about money going to waste on failed projects. It proves this is not 'vaporware'.

Bricolage

Bricolage means 'making do' or 'using things for something other than what they were designed for' or 'creative transgression'. It is a term well known in Humanities, popular in late 20th Century theory (such as De Certeau) and well describes the way software developers habitually work - by cut and pasting code from different places, hacking and modifying systems to suit the immediate need. There are reasons why bricolage is even more applicable to digital humanities research than it is to other areas of software development.

Low budget

Humanities usually has a far smaller budget the commercial world, and than other academic fields such as engineering, science and health and not much of this is can be spared for IT. We usually aren't in a positions to build rigorously well defined tailor made software from the bottom up. These fields none the less produce useful software, so it makes sense not to rebuild it ourselves. However, our needs are different to these other fields so, inevitably, we must modify established software and techniques to our own ends.

Divergent Fields

Humanities staff at an institution are usually working in many different fields. In C21CH we have specialisations in endangered languages, the history of violence, Napoleon, early modern women's literature, Shakespeare, stylometry and others. No one system can meet all their needs for doing and disseminating their research. This means there is even less time and money for each, so we must 'make do'. When we develop a system for one area, it often turns out that it can be re-used for another area, with some modification and enhancement. This other area then has the benefit of it without the initial cost. This has the added benefit of emergent interdisciplinary activity, and re-usable software and skills. For example, a special interest in mapping emerged in this way. Because the infrastructure for these projects is emerging from project needs, it's usefulness is already proven - there is no 'solution in search of a problem'.

Exceptions Are Important

While constrained to use already existing software and techniques, often built from other fields, there are fundamental epistemic and methodological differences between Humanities and commerce and STEM fields. The imperative of management and production methodologies in commerce is to standardise, simplify and optimise for the most common cases, dispensing with costly variations. In STEM there is a need for ceteris parabis and controlled conditions and science is based on repeatable phenomena. Even in statistics outliers can be ignored. But in humanities we are often interested in highly contingent historical circumstances, unique and complex situations. We are as interested in marginal cases and exceptions as we are in regularity. Each informs our understanding of the other, and anything might be in scope.

That's Not How We Do IT

This presents challenges to standard IT practice. Normally and IT project would commence with an analysis to identify the form into which all the content will be put as data. Noted by Ada Lovelace, this has always been one of the principle benefits of IT - processing vast amounts of data, beyond human capacity, in a consistent structure. This is, of course, useful to Humanities and enables new insights as with distant reading, but there remains a fundamental distinction resistant to it in Humanities. It is inevitable that bricolage, hacking to meet idiosyncratic demands, will characterise a DH practice moreso that usual in software development. By exploring idiosyncratic requirements, we may also find solutions, unexpectedly useful more broadly.

Implementation: C21CH as case study

This approach has been identified in retrospect, and some tools and activities were important in it's successful implementation.

  1. Beginning
    1 Academic + Casual Software Developer with Humanities Sympathies.
  2. Another Project
    3 Academics + Casual Software Developer.
  3. Form A Group
    Members of the school of humanities were invited to form a group. There was no expectation that participants would have anything more than an interest and a vague idea. Previous completed projects and interest of the group was enough to convince the institution to provide a small amount of provisional funding. Forming a group enables aggregating funds to employ a staff member. It is difficult to find and keep staff for isolated small projects.
  4. Consultation
    At the formation of the group, there was a crucial phase of consultation. The purpose was to produce feasible ideas through conversations between each academic and developer and to isolate and prioritise feasible projects.
    • Consultation Sessions
      One to one meetings with each academic participating, arriving at at least one project idea each. We had 38 in our first round.
    • Pareto Frontier
      There were too many projects and too many factors to consider about each project to get a clear picture of which should be done first, or at all. We used a rough 'Pareto Frontier' approach. This was an important step to identify commonalities and prioritise projects. The ideas were entered into a spreadsheet and a ranks given for Impact and Feasibility.

      22 Linguistics Storage
      8 Survey of general data visualisation tools, eg: networks, trees, etc
      31 Place-Time Map Layers
      11 Mapping of massacres and atrocities across the British empire
      12 Mapping domestic violence
      20 Best or better audio transcription

      Impact (average of scores out of 5)

      • Relevance (how many would use it, from just this researcher to anyone in the world)
      • Repurposable (can the system developed be used for other projects)
      • Importance (from helping you do your job a bit better to changing the world)

      Feasibility (average of scores out of 5)

      • Time Effort (hours on the job, from a few hours to several years)
      • Likely To Work (what's the chance it will even work)
      • Uptake Likely (are people likely to want it and get it).

      When graphing feasibility and impact we obtained a 'Pareto Frontier' across a range of those with more feasibility to those with more impact, and the highest balance of both feasibility and impact in the middle.

      This draws out projects that are worth doing because they are easy to accomplish in a short amount of time, and those which are worth putting a lot of work into because they will most likely succeed and have a big impact.

      We separately flagged those which would have grant potential and which might involve industry engagement, to give these special consideration.

      This may seem a contradiction to what was said earlier about humanities not being limited to the most general and common solutions, but needing to cater for exceptional cases. We need to do both. Because we are short on resources, we need to identify what is held in common, what will have the most impact, so that we can do as much as possible for as many as possible so that we will have time to handle the special cases.

      An important part of each project is that what is developed for one situation can easily be applied to others, even it if wasn't top priority for them, it becomes a low cost improvement. For example, within the EMWRN archive, each text has unique requirements, but many have some in common or similar. Some do not need the high resolution image viewer, but since it is a convenient way to view the images, it becomes available for all. This applies also to skills development. Developing web mapping skills among the IT staff makes it easy to take on mapping projects for any project.

  5. Deliver Project Outcomes
    The most central point on the Pareto Frontier was 'Place-Time Map Layers'. This highlighted an interdisciplinary interest in maps, across history, linguistics and literature that no-one in the department was aware of before. This has evolved into a core development stream in our digital humanities lab, it has produced a ARC LIEF Grant application (cross institutional and prestigious in Australia), and it has produced innovative map technology for text and audio processing useful to history, literature and linguistics, as well as the Colonial Frontier Massacres project (this project addresses an issue of vital importance to Australian culture and has had a huge impact in Australia and globally).

  6. Grow Centre Seek Money
    The successful development projects make the centre highly attractive. This year we have brought in new members and early career researchers and taken on two student developers. We have offered small internal grants to encourage and build Digital Humanities experience. We have also provided small grants to fund humanities startups. More funding was obtained from the University and more grant opportunities are being sought through government and philanthropy.

Current Personnel

19 academic members, including 4 Early Career Researchers

1 Casual admin support

1 Casual media support

3 Casual IT staff, 1.5 FTE, with some design work through a local business

Other contributing factors

Problems

Academic recognition. Although they are citable with DOIs and HDLs, it remains difficult to get recognition for DH projects as intellectual outcomes. It often difficult to figure out just how to cite DH project into bibliographic conventions. This is a disincentive forcing academics into churning out papers even though a DH project may improve research and enhance dissemination.

DH Precarity Staffing structures have yet to adapt to 21st century changes, still with a binary opposition between academic and professional roles that fails to recognise, and account for the 'third space' professional work of academics and the intellectual work of professional staff, if we can separate 'intellectual' from 'profressional' at all.

Other Approaches

Other Case Studies

Electronic Textual Cultures Lab (ETCL), University of Victoria, Canada

- Information provided by Ray Siemens

Western Sydney University

- Information provided by Rachel Hendery

The differences in these two case studies and our own can be attributed to different stages of development, different evolutionary processes, and different cultures of academia, entrepreneurship and philanthropy in Australia and North America.

Next Challenges

With workload and projects rapidly increasing we are seeking funding through larger grants, philanthropy and industry partnerships.

Wider collaboration

Key Ingredients

Staffing
The need to avoid fixed requirements can make working with commercial providers, even in house IT departments difficult, as they usually need to strictly deliver according to agreed requirements for legal and resourcing reasons. The approach described here works better employing your own DH developers as collaborators. Staff member should have a humanities background in order to communicate effectively, appreciate the distinct needs of Humanities and avoid frustration with the difficulty of getting a clear requirement.

Rapid Prototyping
Providing working software as early as possible aids imagination, builds confidence, demonstrates capacity and ensures an outcome despite uncertain budgets. Requirements documentation need only be rudimentary and general, developed from one or two meetings at most.

Pareto Frontier
This was a crucial step when building a group, to prioritise projects when there were too many to contemplate all at once, and there were insufficient resources to produce them all. The projects that emerged did indeed appear to be the most sensible, made us aware of interdisciplinary interests, lead to reusable software and skills, and were high impact.

Laissez Faire Prototyping environment.Unrestricted access to web prototyping environment (though developer must understand IT security) for fast moving development. This allows you to 'try and see' resulting in working software and demonstrated feasibility rather than meetings and plans. If it won't work you find out early.

Small projects Many small projects would be greatly beneficial but can't be done because a staff person can't be attracted with such a small amount of money. Aggregating projects, makes a commitment possible. Small projects also provide earlier cumulative successes that build confidence and demonstrate capability. Important DH projects don't necessarily need big data and hardware. The point of focusing on cost savings and shared outcomes is to allow time for exceptions, idiosyncrasies and so that diverse needs are met.

The end of the project is the beginning.