-
Notifications
You must be signed in to change notification settings - Fork 84
Why a Research Software Engineer Role
This is a living document that reflects a community argument for why a Research Software Engineer is important. "Living" means that you can suggest changes or edit it at any time by updating this wiki, and "community argument" means that we've put our heads together to try and synthesize a robust answer to "Why do we need research software engineers?" This document in no way encompasses all of the current literature and views, and so if you see something missing we invite you to contribute your ideas and opinion. The original Google Doc can be viewed here.
The following individuals have contributed to this living document.
- Vanessa Sochat
- Daniel S. Katz
- Matthew Bluteau
- Alys Brett
This document aims to be a community effort to bring up an argument for creating an official research software engineer job classification and levels at an institution. It aims to include:
- An introduction that summarizes and provides evidence for the problem
- A proposed job description for a single role
- An expanded job classification for proposed levels
- A summary of current institutions that do have official groups / roles
- And at its completion, it can be shared with other institutions and used as a starting point to communicate with Human Resources (HR) about establishing this role.
The following contributions would be meaningful:
- Add evidence (point and reference, appendix, or supplement) to any section
- Critique or make suggestions to the classifications or content
- Add additional known RSE groups to Table 1
- Suggest addition of a new section
This document does not include a plan for funding, or salary. It could be that some reference to either of these is added, but from my experience recently, the salary levels are determined by the HR group after some “market research” and the funding strategy depends on where (in what department) the role is established. But if you think there can or should be a section that covers this, please add!
We know that software is becoming increasingly important to research. This means that for research to be reproducible and sustainable, research code must be documented, understandable, developed under version control, tested, and professionally packaged. Historically, the crux of this work has fallen on academic software developers, a group of individuals that can carry titles ranging from lab associate to research staff, and in many cases without this staff the burden falls on the shoulders of students or postdocs. Students and postdocs may not know best practices, or worse, they eventually leave and the code must be passed on to a new maintainer. Instead of a high quality, sustainable artifact, this makes research software fragile, hard to maintain, and hard to validate. How can it be that, despite this essential role of software for research, there is no accredited career track for an academic software engineer? This problem was first noted in the UK almost a decade ago ^1 and has come to the forefront of our attention in the United States in recent years ^2. If we want to encourage talented engineers to stay and support software officially across a university or institution we must be competitive with other software engineer roles that offer a career ladder, competitive salaries, and professional and personal growth. If we want to set the standard for research software engineering practices, and consequently the highest quality of research, we must show action to support the role of Research Software Engineer (RSE) as an official job in academia.
Several national institutions are leading the way to establish research software engineering roles (Table 1). The group in the UK (UKRSE) has thousands of members, and the US-based group, which started only recently, already has 400 members. Major US universities that are respected players and leaders in conducting high quality research should also be at the front of this charge. To assert that our community values the quality of research, and importantly, the sustainability and longevity of its outputs, this role must be recognized and better supported. Other institutions have already recognized and presented work on this topic (See Appendix 1).
From the standpoint of an institution, there should be concern about the current design. By not recognizing the role of Research Software Engineers and providing no opportunity for advancement, this means that knowledge leaves the organization as the engineers eventually leave looking for better opportunities. It makes it unlikely to be able to maintain expertise, and be on the cutting edge of technology for research, and likely that the institution cannot continue to fulfill grants that require such expertise. On a higher level it wastes funding that the university relies on for research, and time and resources of current staff as they have to somehow fill the roles. All of this happens because we are using an outdated model of a research organization that does not account for Research Software Engineers. There is a gap in Human Resource's understanding of the real organizational model that exists but is not recognized. Not having a secure place for Research Software Engineers places current and future research projects at a huge disadvantage. Science is not a short-term process. Success in research means reproducible, sustainable, and consistent software and practices. This cannot be provided by way of students and temporary research staff or consultants being utilized for a small period of time. If institutions cannot keep developers and the knowledge and expertise they bring or acquire, they are severely handicapped.
National Institutions that have established official Research Software Engineering roles, meaning that the title is defined at the university organizational level.
| Institution | Description | Link | Size of Group |
|---|---|---|---|
| Princeton University | Ian Cosden leads a group of research software engineers to serve researchers across departments at Princeton. | link | 10 |
| Harvard University | Research Software Engineering at Harvard is growing an RSE community and covers everything from software packaging and design to data services and consultation. | link | 6 |
| National Center for Supercomputing Applications | NCSA has an official software directorate, and a hierarchy of RSE roles that start at assistant research programmer and go up to senior and principal research programmer. | link and Google Doc | ~35 |
| Duke University (RENCI) | RENCI has multidisciplinary group that supports all aspects of data science, including development. They have several levels for the role of RSE. | link | ~17 RSEs in a group of ~100 |
| NYU | NYU has a Data Science and Software Services group with Research Engineers | link | 2 |
| Cyverse | Cyverse provides science gateways, and has a large team with several levels of RSE. | link | 8 |
| McGill University, Montreal Neuro | McGill Centre for Integrative Neuroscience (MCIN) makes large open-source neuroscience platforms + tools. | MCIN.ca (lab) established these HR Job profiles for RS devs & managers - available since 2017 to all units across the university | ~40 RSEs / 80 at MCIN |
| UK Atomic Energy Authority | There is an explicit RSE Team at UKAEA which operates on a consultancy model wherein RSEs assist research groups across the organisation. The team also provides centralised infrastructure and training courses of software engineering topics. RSE roles exist at four levels from graduate to group leader. | 12 |
Individuals that act in the role of Research Software Engineer (RSE) have been around as long as there has been research that relies on software. It tends to be the case, however, that the roles are hidden. For example, at Stanford University as of the end of 2019 there were 177 Individuals across approximately 50 departments (not including the SLAC National Laboratory) that carried responsibilities that fall within the job duties of Research Software Engineer. Despite the importance of these roles to developing quality software for research, there is typically no career progression, and no direct opportunity for professional or personal growth as an RSE. Despite their importance, RSEs tend to fall out of acceptable paths for academic careers as they are not postdocs or otherwise pursuing a path toward becoming a principal investigator (PI). For example, the typical Research Software Engineer might carry an official title of “Research Staff,” be heavily reliant on soft funding, and entirely responsible for her own professional growth. The classification fails her because it offers no next steps, no excitement for the future, and a constant burden to recover her salary.
This lack of a proper, accredited role also means that talent graduating from a top university, even when there is passion to stay in research to work on software, is more likely to choose the job security, competitive salary, and professional growth that comes with software engineering roles in industry. The most successful labs are those that can afford to find and hire staff to work exclusively on software. This means that, for the bulk majority of labs, even if they were able to find talent that would be content with no career progression and a lower salary, they probably couldn’t afford it. The current lack of an official role across most US universities or groups is simply not working because there is no role that is attractive to grow this pool of talent to ensure that we have the highest quality and sustainability of software.
The following job description covers the general duties of a Research Software Engineer. An RSE can generally cover a wide variety of roles that range between researcher and software engineer, and this heavily depends on the needs of the user base. The role below is adopted from the experiences of RSEs writing this document, along with job descriptions created by other universities.
For the job description linked with this document, see the usrse job descriptions repository.
The following publications and documents are helpful to provide additional context and information about the role and need for Research Software Engineers.