By Caroline Jay, University of Manchester, Albert Solernou, University of Leeds, and Mark Woodbridge, Imperial College London

At present, few higher education institutions in the UK - or indeed internationally - employ a central team of dedicated research software engineers (RSEs) who sit outside of any specific academic department. The allocation of baseline funding to software developers is considered a risky activity when every member of staff represents a significant ongoing cost which has to be recovered. A cautious approach to employing people in what may be perceived as a completely new role is understandable, particularly in an uncertain financial climate.

Nevertheless, permanently employing RSEs has the potential to pay huge dividends, a fact borne out by the institutions who have established central pools, including the University of Manchester, UCL and the Turing Institute, and rapidly expanded their teams.

Institutional benefits of employing RSEs

A primary benefit of including software engineers on the baseline can be summed up by the Software Sustainability Institute mantra of “better software, better research”. Involving professional software engineers in research projects leads to better quality data, analysis and results, which has a direct impact on the scientific evidence base. Higher quality output is on every university’s wish list, as it leads to a potential increase in QR funding, while reducing the reputational risk associated with substandard research practices.

Reproducibility is notoriously difficult to achieve and RSEs are an essential part of enabling this. A researcher struggling alone to solve a complex domain problem does not necessarily prioritise the robustness, elegance and cross-platform compatibility of the analysis pipeline. When a domain expert and an RSE work together, data and analysis methods are much more likely to be repeatable and transferable, leading to higher citations and greater research impact. An additional consideration is the direction in which publication models are now moving. Future journals will require not just data to be available, but the analysis to be executable too, giving institutions who support their staff in producing this kind of work a significant advantage.

Another benefit of better quality software is that it is easier to disseminate and commercialise. An algorithm may promise a step change in performance, but if it only works on one PhD student’s machine it’s going be much harder to make the case to industry for its value as intellectual property, or even to build a community of open source contributors.

Fixed-term or permanent?

The case for the contribution that RSEs can make is clear, but it doesn’t articulate why RSEs should be part of a university's core staff. Better quality, higher impact research is a goal of every institution, but it could be argued that this is achievable with fixed term contracts in line with the traditional academic model.

A straightforward argument for employing software engineers on permanent contracts, however, is that it’s what the job market dictates. A skilled RSE has transferable skills and won’t struggle to find a post in industry. To get the best people, it therefore makes sense to offer stability and the potential for some form of career progression.

An important point to make here is that while institutions must underwrite permanent posts, it is not the case that they would be paying an RSE’s salary from baseline funds. The research councils now encourage people to cost RSEs into grants, and their time can thus be recovered as with academic staff.

In a complex research project it is challenging for a single person to take on responsibility for both the research design and outcomes, and the full-stack software development that is required to implement and deploy these in a reproducible and sustainable manner. This work is not necessarily two full time posts however. By costing in, say, 25% of an RSE to work with the domain expert, the quality of the research software and therefore the reliability, validity and efficiency of the research will increase considerably.  The RSE who has worked on one project will take this knowledge with him or her to the next, spreading best practice and providing an ‘institutional memory’ of how best to maintain and build its research software. However, this process depends on the continuity of employment offered by longer-term contracts.

An official costing in a research grant is not the only way RSEs can pay for themselves. A pool of skilled engineers who are also well versed in scientific analysis methods across domains is a very versatile workforce. The underspent travel funds from a soon-to-expire grant can be used to fund an RSE to make a tool deployable; an RSE can perform the data analysis for a short, seedcorn-funded project where finding and employing a postdoc on a fixed-term contract would have been unfeasible. RSEs can also provide training as part of their role, which opens up the option of cost recovery from teaching funds. These options are only available if RSEs are permanently employed and their salaries are underwritten - the short-term, part-time nature of such jobs means it is not practical to recruit someone to do each in isolation.

Once a pool is big enough, RSEs can specialise. Each research project may need an RSE, but that RSE is not necessarily going to be the same person throughout: sometimes a web developer might be required, at other times a Fortran expert. An RSE team that is permanently employed can be truly agile. Recruiting an expert for a short period of time in an academic institution is virtually impossible. As long as we rely on fixed-term contracts for RSEs, a lot of important work will fail to be done, and funds will not be spent as effectively as they could be.

Barriers

A major barrier to the recruitment of a permanent RSE team is the risk involved. While a source at a major university tells us that his team has been massively oversubscribed from day one, at a smaller, less research-intensive institution the possibility of failing to fully recover costs may be much higher.

There are also more subtle drivers against the set up of a shared resource. In some disciplines a larger team garners higher status, so sharing some of its members with other groups may not appeal. Even the seemingly neutral activity of costing could be problematic. If an overhead comes with an RSE and this goes to a central pool, the principal investigator’s department may view this as missed research income.

Conclusion

In spite of these issues, things are moving in the right direction. Since ‘research software engineer’ was first recognised as a professional role, the career prospects of those writing code rather than papers have improved considerably. As more institutions recognise the value that a team of technically skilled individuals could bring to their research endeavours, we anticipate that the future - for research, as well as research software engineers - will look brighter still.