By Simon Hettrick and Neil Chue Hong.
We work with people who share two characteristics: they are involved with research, and that research relies on software. This incredibly diverse group is known as the research software community. It’s a convenient name, but what does it actually mean?
Identifying the people with a vested interest in the use of software in research is of obvious importance to the Institute: it’s our target market. But it’s also of use to the people in research software community. The different groups within the community are reliant on each other – even if they don’t know it. A better understanding of what other people are doing, and the better communication that entails, will help everyone to share ideas, results and solutions.
We’ve identified the three main groups of people (plus two other groups) that we think make up the research software community. Do you agree? Let us know.
The Researcher Who Uses Software
A researcher who uses software is someone whose primary goal is research. Their work is judged on the quality of their scientific output via traditional mechanisms like publications. This person sees the value in software, but only as a means to an end.
By software, we don’t mean the omnipresent variety, like word processing or email clients, because in today’s world that would cover almost everyone. We mean software that has been developed for performing a fundamental part of research. In fact, the software may have been developed for a specific researcher.
Researchers who use software may not be able to write code and, even if they can, they would prefer to focus their effort on their research. If forced to write code, they tend to hack together a quick solution without an eye on software engineering practice or sustainability.
Researchers who uses software rely on the research software community to provide software that can help their research. They also rely on the more development-oriented people in the community to help with fixing problems with current software and advising on important subjects, like reproducibility of results.
The researcher-developer generally started off as a researcher who uses software. At some stage, the software didn’t do exactly what was needed, so the researcher took the plunge and had a go at hacking the code himself. This quickly led to the realisation that bespoke software can give you an edge in research. Whilst other researchers have to waste time wrangling with software that doesn't quite fulfil their needs, the researcher-developer gets the results he wants, from the data he has and in the format he needs. This realisation motivates the researcher-developer to become more and more adept at writing code.
As the researcher-developer’s software matures and generates results on which papers can be published, it attracts researchers who want to use the software themselves. What starts off as sharing code with a colleague, can grow into a small user group and then end up as a full-blown software project. Suddenly, a new route to recognition is available to the researcher-developer: as a provider of software.
The researcher-developer is still a researcher at heart, so he will mainly receive recognition from his scientific output. The newfound recognition for his software is also welcome, but there is no obvious route for reward for this role in academia (a problem that the Institute is lobbying to resolve).
Researcher-developers look to the research software community for users for their software. They have not received formal training in software development training, so they also look to the research software community to provide advice and training.
The Research Software Engineer
The research software engineer comes from a research background, but is also a skilled software developer. It is not just developing code that he relishes, but the challenge in coding well. At some point, he received more formalised education in software engineering, which he now applies to his research software. This makes the software more reliable, more robust and easier to use. The talents of the research software engineer are much in demand, but there is a problem: they are difficult to employ.
Research software engineers fulfil a role that most academic grants do not recognise, so they end up in loosely defined postdoctoral positions. This is a less than perfect workaround, because the research software engineer focus on software development means they can lack the publications needed to secure a successful career in academia.
The research software engineer works with the research software community as a provider: of software, of advice and of training. He looks to the research software community to help gain a formalised recognition for the role of the research software engineer.
Although the three groups described above make up the majority of the research software community, there are two further groups who are also very important.
The Professional Software Engineer comes from a software development background and works with research groups to develop their code. They are not research specialists, which means that they can easily move from one research group to another. They provide software of a professional quality. However, a lack of knowledge about their chosen research area means that the Professional Software Engineer requires time to get up to speed, and he can overlook things that an expert in the research field would know to be important.
The Infrastructure Provider provides research software, hardware and expertise to researchers. They tend to be a diverse group of people, ranging from project managers to IT support.