What is everyone saying about research software?
This post originally appeared on Jisc Research Data
Research software, as the name implies, is literally code written to solve a problem that a research team is facing. Most commonly, research teams try to automate some of their experiments or calculations using code. Sometimes these require a lot of knowledge and expertise and the teams may be looking for a research software engineer. And other times, either for lack of funding, or curiosity, one or more of the team members will attempt to write some code on their own. Which is absolutely fantastic.
Many of us at Jisc, at SSI and within the support teams across HEIs want to help researchers and the research software engineers manage their code in a more seamless way, share it with the community and get the appropriate credit. So we set out to organise a few workshops to bring together experts and beginners to talk about the type of challenges they have with managing research software. Any solutions they tried, blockers they encountered… And finally, spend some time and release those creative juices on a set of new solutions.
January was the perfect month. To give you a gist, 6 workshops were held in 6 different venues: University Birmingham, the British Library, University of Cambridge, University of Leicester, the Engine Shed in Bristol (organised by University of Bath), and University of Sheffield. Close to 200 people attended from 48 different organisations.
There were researchers, developers and support staff from departments like Chemistry, Engineering, Physics, Biology, Languages, Literature, and Theology, IT and Research & Innovation. The discussions were similarly varied. Here’s a word cloud based on the various issues and challenges that have been brought up.
I can code, but I am not a software engineer
One of the big themes across the workshops was the lack of a community for researchers that code or are just beginning to code, nonetheless they do not consider themselves software engineers. They have plenty of questions, they need some help and some guidance to get them going, but most of the time they do not know where to start. Then again they are committed. And they are interested in writing their own code.
The problem is rarely technical, as many of the attendees confirmed: the technical solutions are easy and there is enough material out there to learn the technical aspects. It is mostly about peer support, or in other words, a bit of help from someone who has done it to so we can hack our way through the time-wasting parts.
There are already some informal communities within the institutions that held the workshops and we are hoping to see a few more of these form over the next year. Watch this space, we will be putting together a short paper on how to organise a community of practice for researchers that code.
The life of Research Software Engineers in academia
Another interesting theme that emerged from the workshops – and I am pretty sure discussions around it have circulated for at least a couple of years – was on how to attract and maintain software engineers within universities.
Support staff are continuously getting requests from researchers and research teams for high quality developer effort, whilst most of these are for short periods of time. And research engineers are already forgoing highly paid private sector jobs to work in the academic sector; the risk of little to no progression and the impermanent nature of contracts make these jobs even less attractive.
A few institutions managed to solve this problem by pooling research software engineers into a service team and underwriting their contracts. The various departments in the university can then book the RSE’s time into their own projects at an established rate. At Leicester University, an RSE was hired and their time has been fully booked within just the first weeks on the job. This is an indication that the scheme works quite well. Similar schemes have been implemented at Edinburgh, UCL, Bristol, Sheffield, Southampton and Manchester Universities. An RSE subgroup is putting together case studies to help other institutions develop the business cases for these programmes.
The useful stuff
Neil from the SSI set up a slack sub-channel for those who need to find out more about software management and development. The sub-channel is on the Research Software Engineers’ slack channel, but you do not need to be an engineer to join. It is for beginners and for any questions you are not comfortable asking! You can join the beginner’s channel here if you have an account on this Slack. If you need to register, follow these joining instructions.
We have put together a list of resources – organisations, reports, tools, training, guides, journals and some slides from the workshops on the research data network pages.
Acknowledgments:
Thank you to the following group of amasing people for organising and committing their time to speak at these workshops: Marta Teperek, James Davenport, Rachael Kotarski, Hannah Haines, Andrew Edmondson, Jez Cope, Jon Wakelin, Rosie Higman, Georgina Cronin, Richard Evans, Neil Chue Hong, Mike Croucher, Jonathan Tedds, Stephen Eglen, Kirstie Whitaker, Laurent Gatto, Chris Nixon, Robert Free, Grant Denkinson, Eleni Vasilaki, Zosia Beckles, Catherine Jones, Christopher Woods.
