Does academic culture support collaborative software development?

I’m interested in how academics develop software. Not so much the tools they use, but the processes they adopt.

As such, I’ve been talking to academics and research software engineers about their experiences (you can take the online version of this survey here by the way: http://bit.ly/academic-software-survey). What I’ve heard so far has caused me to think a great deal about an aspect of software development which underpins everything: collaboration.

Being close to the start of this journey, there’s still a long way to go before I’ll achieve anything close to the full picture. So, for now, I’m going to have to work with what I’ve got, which is a limited qualitative data set derived from surveys, email correspondence and viva voce. Given the limitations of the data, I’m making no claims here! Just pondering, and hoping it might prompt others to join in.

What are the barriers to successful collaboration?

The data I have collected can’t answer this question directly, but it does suggest there are perceived barriers in relation to best practices. Since it is impossible to talk about best practices without considering collaboration (and vice versa), I think I can get away with a bit of question bending here.

Here is a non-exhaustive list of ‘challenges’ reported by RSEs and academics who develop software for research purposes (which I’ll now refer to collectively as ‘ASDs’ for brevity…but without any intention of drawing parallels with another use of this acronym!)

• Lack of funding
• Lack of knowledge / experience (sometimes linked to funding)
• Lack of time
• Small team size / ‘narrow pipeline’
• Skills incompatibility (among development team, or between different user groups)
• Complicated pipelines (e.g. in long-running projects)
• Various reasons linked to personality and/or prevailing culture (e.g. insecurity about code, reluctance to ‘let go’/ask for help, etc.)
• Think I missed one? Take the survey!

Of course, ‘challenge’ does not equate to a ‘barrier’, except perhaps when those facing it don’t feel adequately positioned to overcome it…which brings me to another point I’d like to make about the discontinuity between industry development practices and those of the academic research community.

One of the things I’ve noticed from my (as yet) limited exposure to ASDs is the tendency to view the software software projects they work on as being fundamentally different from industrial projects in organisational structure and purpose, and that these differences make them incompatible with much of the popular methodology (or ‘dogma’, as one RSE put it!) While differences are unavoidable, I can’t help but wonder whether there is less of a compatibility issue when it comes to best practices than might first appear?

What makes academic software development different?

I would suggest there are 3 main areas in which ASDs differ from industry practitioners: context, culture and competence (disclaimer: ‘competence’ might be a slightly unfortunate choice of term here as I’m not wishing to imply ASDs are incompetent, but I wanted a word beginning with ‘C’ which would imply a different level of software development expertise than one might expect from their industry counterparts…on average). I’ll leave competence out of this for now, given it doesn’t require much in the way of explanation, but the other two ‘C’s I’d like to give a bit of attention to.

Let’s start with context. It is undeniably true that, within the two factions, there are different sets of vocabulary which carry contextual connotations that aren’t always easy to reconcile. For example, in relation to industry projects, it is normal to talk about ‘products’ and ‘customers’ in a way that doesn’t translate easily in relation to research project structures. Similarly, terms like ‘fail fast’, ‘lean’ and ‘rapid’ don’t naturally resonate among academics whose culture is one of rigour, verbosity and perfectionism (if you’ll forgive the generalisation). It’s also hard to mention the word ‘agile’ among ASD’s without hearing a faint grinding of teeth…though I’m not entirely sure why this is?

But what happens if we reframe software development as a subsidiary activity which supports research? Of course there may be exceptions to this rule, but generally speaking, the software development isn’t the research. Software development, on it’s own, doesn’t lead to new knowledge (other than knowledge about software development). And before anyone gets their back up, this isn’t an attempt to devalue it in any way, or to place it below research in status. From this perspective, software is the science laboratory…or a powerful statistical technique. It makes new knowledge possible.

Having decoupled the software itself from the research it supports, it may be a little easier to observe the similarities between what ASDs do when they write software, and what industry practitioners are doing. They are all developing tools or products or artefacts or whatever you want to call them. Both manage budgets and stakeholders of one form or another. It doesn’t take a massive leap of imagination to start substituting terms according to context, although it does take some thinking about. For example, it might be that ‘you’, the ASD, assume multiple ‘proxy’ roles to compensate for the lack of direct involvement from your stakeholders. (As an aside, I would find it really interesting to hear how ASDs practice stakeholder identification, or whether they do it at all?) It might be that your only collaborators are the future versions of you, or a future open-source community you can’t quite imagine yourself ever encountering…yet the possibility is there.

The interesting thing is, that when you start asking industry practitioners about the key to successful collaboration, they will rarely say anything that couldn’t apply to ‘future you’. In fact, very little of what I’ve learned about industry practice from practitioners who are predominantly practicing agile could not be applied to the academic software projects I’ve worked on (at least, in principle).

What does industry say about collaboration?

The figure below is an attempt to group the key points made by industry practitioners in response to the question:

Other than ‘use version control’, what is the best piece of advice you would give a small (and potentially disparate) development team to help them collaborate effectively?

I’ve done it in a Maslow-esque format mainly because it looks nice, but also to imply there is a degree of hierarchy here, with the bottom tiers representing the most fundamental of the collaboration ‘needs’.

So far I haven’t heard anything that sounds like a particularly convincing argument (or excuse) for not adopting at least some of these principles, all of which are consistent with ‘agile’ (a fact you can ignore if you find it unsavoury). Moreover, many of these points were echoed by my first year BSc students after their first Team Project module. In effect, they are no-brainers.

How we actually apply these principles in practice may not be so straightforward though. That’s why I want to learn as much as possible about how ASDs of all denominations currently work, so that I may start to understand where there are opportunities for improvement. Maybe this will lead to a collection of ‘good practice patterns’ for ASDs, taking into account important variations in context such as project size, structure, etc.

A word on culture

I haven’t forgotten the second of the ‘C’s, and its one I find interesting from a slightly tangential perspective. It starts with an observation: in the process of garnering my data, I received the same number of responses from industry in 2 hours as I received from academics over several months. Admittedly that was partly due to the mode of contact (I find direct email a more effective way to elicit responses from people than social media, group emails etc.), but I wonder if it also says something about the collaborative ‘culture’ in the two different camps.

While I imagine most academics view themselves as collaborators, the culture in which they work may not be the best at supporting it.

For example, a culture preoccupied with ‘intellectual value’, ‘impact’, ‘credibility’, and, at times, a ‘justifying one’s existence by looking like one is doing something useful when in fact one is riddled with doubt’, may not be the best at fostering openness and collaboration. Similarly, ‘don’t gold-plate it’ is perhaps not the phrase you’d want your reviewers to hear you using, yet in software development, perfectionism is not always your friend.

In response to the accusation that academics are ‘slow’ responding to emails, one might argue they are simply overloaded. As an academic myself, I’m hardly going to contest that point! However, I’d also look at culture…

Is there something about the academic culture which promotes the tendency to take on too much work, or are bugs in the system entirely to blame?

I can’t answer that for all academics…so I’ll let it be food for thought.

Conclusion

So, in summary: the pathway to better collaboration is one which requires knowledge of best practices coupled with a flexible approach to their application, as well as a slight shift in culture. (Simon needs not to be apologetic or afraid about asking Judy for help, and Judy should try to resist taking on so many projects that it takes her 2 weeks to reply to Simon’s email, and another 2 to find time in her diary for a meeting. Moreover, if Simon and Judy are supposed to be working together, they should develop and agree unambiguous processes and workflow procedures…whatever they may be.) And, going back to the title of this essay, I think academics are a culture of collaborators, but while we stuck to the same format for hundreds of years, others adapted theirs and got, well, better. Perhaps we can learn from them?

If you are interested in debating or assisting in any of the above, please consider getting in touch via my institutional email, or by completing the survey. I am also keen to hold ‘retrospectives’ and ‘project process case studies’ with any ASDs who would be willing to participate.