It does not matter in what field you work in: nowadays, it is nearly impossible to carry out any kind of research without specialised software. It might be a complex modelling tool that needs to run on a supercomputer several days to give you some result; it might be the good old Excel, highly criticized lately but still hard to beat in many aspects; it might be a program to manage and keep tidy your references and bibliography… All in all, software is everywhere!
Very often, this software – research software – is developed by the researchers themselves. They start as small pieces of code to analyse some data or produce some plots for a paper. Then, over time, that code grows in size, complexity, features, and usefulness for the whole research group. By the time those researchers – nearly always PhD students or postdocs – need to move on to another institution, the software they have created has become an indispensable tool for their colleagues. Nevertheless, there is a problem: only them, as the creators, know how it works, how to improve it, or how to solve issues when they appear (and they will appear). It is not sustainable and, once the developers are gone, the software will eventually die and disappear. What a waste of resources!
Research software engineers (RSE) were born to sort this out – among other things. The term was coined in 2012, at a workshop organised by the Software Sustainability Institute [1] to describe people with expertise in programming but also with a deep understanding of how research works. We might arrive at this role – not necessarily a job title – from a software engineering background or from a research background (this is my case, for example [2]). Either way, our purpose is the same: to ensure that software developed as part of any research is of high quality and sustainable, creates impact, and it is acknowledged as a first-class research output. We facilitate bringing that code developed by researchers to the best of their abilities up to a state where it can withstand the test of time, adapt to the ever-changing goals of research, and create a thriving community of users and contributors around itself.
The way we do this takes multiple forms and is highly dependent on the institution. Sometimes, we directly take over the software, rewrite it totally or partially to follow best coding practices and patterns, document it, and hand it back to the researchers. At the other end of the spectrum, we have the training: we teach researchers how to create sustainable software themselves, to start with. The most famous public initiative along these lines, but not the only one, are the Software Carpentry courses [3], but we also offer bespoke training courses whenever it is needed. In the middle, we have my favourite type of projects, those in which we work alongside researchers supporting them in improving their software. These might take longer to be completed but the result gets the best of both worlds: the software is now sustainable, and researchers know how to keep it that way or develop brand new software following the same principles.
RSEs can now be found in most of the big universities in the United Kingdom. Sometimes, like in the case of Imperial College where I lead the RSE Team, they are part of the central services of the university, helping all researchers across all Faculties. In other cases, they are embedded in specific Departments or even big research groups with important software needs. Being an RSE is a relatively new concept, and most probably you have never heard of us before. You might have one of us around the corner and you would not even know! But here we are: look for us – or check the webpage of the Society or RSEs, where there is a list of RSE teams across the UK [4]. We can help you make your software as valuable – or more – as any paper you will ever write, and chances are you will get new invaluable skills for the modern world of research in the process!
By Diego Alonso Álvarez, @dalonsoa. Research Software Engineer Team Lead, RCS-ICT, Imperial College London.
More information:
