Source: Getty
Talented young technology professionals – indispensable to the successful pursuit of high-quality research – are deserting higher education for the private sector because the academy does not know how to reward them, experts claim.
Research software engineers, who work on research teams and are charged with designing, building and maintaining the programs required to carry out projects, have no recognised career path within universities, critics warn. So they end up leaving for more stability – and recognition – in industry.
The potential consequences for the academy are manifold. Without software engineers who understand how researchers operate and who can grasp the complicated concepts with which scholars grapple, the programs developed to process research data may be unfit for purpose, leading to questionable results and even discredited projects.
One illustrative example of this is the “Climategate” scandal in 2009, when hacked University of East Anglia emails were alleged to reveal that data had been manipulated to support the view that climate change is caused by human activity.
The professor at the heart of the scandal, Phil Jones, was criticised by the House of Commons Science and Technology Committee for not revealing details of the computer code used in his research – code created specifically for the project on which he was working.
“In Climategate, the software became contentious because it wasn’t particularly transparent,” explained Simon Hettrick, policy and communications lead at the Software Sustainability Institute (an organisation that advises on producing better research software) and a campaigner for greater recognition of engineers in this area.
“Because, like a lot of research software, there was a certain element of it being ‘thrown together’, it was difficult to understand exactly where the numbers came from, so the climate change deniers could question the results. Poor software can undermine research results.”
One way to safeguard against the development of unsuitable software, he said, was to ensure that those who write the computer code are integrated and valued members of the research team: experts in the field in which they are working who also possess the necessary technological skills. Their labour must be viewed not only as a means to an end, Dr?Hettrick said, but also as an important project output itself.
Such professionals already exist, but often have to masquerade as researchers because there is no specific job that relates to their skills. As a result they are expected to publish papers, with the sometimes considerable software output they produce earning few brownie points.
“The principal researchers know that without software engineers you don’t have good software; and without good software you don’t have good research. But there is no career path in universities for a person doing software engineering within a research group,” Dr?Hettrick said.
“They can’t progress because the metric on which university career development is judged is not something that they produce often: academic papers.”
Go out to go up
Dirk Gorissen was a research software engineer at the University of Southampton. Although his official job title was “research fellow” (another sign that the role has some way to go before it is a recognised position), he was responsible for developing software within the School of Engineering Sciences.
Despite thoroughly enjoying his work, Dr Gorissen left the sector earlier this year to become principal research engineer at BAE Systems because he had neither a clear career path at the university nor a permanent contract.
“The way academia works, the only real career path is an academic one,” he explained. “The problem is, academia all comes down to what publications you make. When you spend a lot of time on software it can be difficult to turn that into publications.
“The code you write – the quality of it – doesn’t really matter. You put effort in and make sure it’s well developed and up to scratch, but I’ve been told a number of times that it is not important. All that matters is whether you can get numbers out so that we can publish them in a paper: the code that makes it happen gets forgotten.”
Many universities appear to rely heavily on code written by staff in postdoctoral positions, he said, meaning there was often “hardly any effort” going into ensuring that the software works correctly.
‘Unique breed’
One institution that is prioritising research software engineering is University College London. James Hetherington leads its research software development team, which has three permanent members of staff. Each term there is a call for projects, after which an academic peer-review body decides which ones to resource. The most recent call was 10 times oversubscribed.
“The research software engineer is a unique breed,” Dr Hetherington said. “It is part software development consultant, part researcher and part something of its own. They are not just programmers: they must have a skill set that enables them to read research literature and rapidly get to grips with it.
“It’s not our job to understand the science as much as the principal researchers, but you can’t do good software engineering without an understanding of what the programs are supposed to do. That is what we bring compared with…the general software engineering marketplace.”
He said that if institutions placed greater value on software engineers’ output, there could be benefits not only for professionals working in the area but also for the universities themselves.
“There’s not much institutional memory around software artefacts created by research – and these could very well fit into the impact agenda of the research excellence framework that universities think a?lot about. Software is one of the outputs of a?lot of research projects, and it deserves to be treated as something that other research groups around the world can use.”
To improve the standing of research software engineers, Dr Hettrick said that universities “from the vice-chancellor down” must acknowledge the importance of their role.
“We also need to work on peer-review panels,” he continued, because the extra expense of software engineers can make reviewers view funding bids less favourably.
“If you have an engineer with a ?30,000 salary doing this work and you have this person on your grant bid, peer-review panels are currently judging them quite harshly,” he said. “We need to convince them that research software engineers are needed.”
