By Sam Cox, University of Leicester, Richard Adams, Cranfield University, Eike Müller, Met Office.

The role of software in research and who writes it

From an institutional level down to teams and even individuals, research today is heavily reliant upon software and particularly upon bespoke computer code which solves specific scientific problems.. This creates a huge demand for software creation and maintenance. Traditionally, this has been the responsibility of post-docs and postgraduates. But while they play a crucial role in the success of the research group, the indirect nature of the translation of their work into papers (particularly the maintenance and update work to keep on keep the software fit-for-purpose under changing scientific requirements) can leave the individual researchers at a disadvantage—they have less time for the more traditional work of running experiments and writing papers. This in turn has an effect upon their career progression, which hinges on clear metrics for success.

As a result, one major issue is how to identify what ‘success’ looks like in these roles. How do we show funders the value of these roles? Counting authorship of academic papers and impact factors is often a poor fit, but it is the most widely used metric within academia. Developing similar metrics to recognise the value of good software engineering practice in science will be important for the establishment of new, software-related career paths.

Emerging careers for RSEs

In recent years, the Research Software Engineer (RSE) movement has helped to professionalise and recognise this role—in particular, giving a voice to those who participate in a research environment, but may not themselves be researchers [1]. This is becoming a well-established field with enormous growth in the last couple of years. However, questions remain about the career paths of those choosing to identify as RSEs, as well as those doing similar work while remaining within the traditional academic roles of postgraduate and post-doc. What career paths exist for those wanting to pursue software development in the research context? What can we as a community do to establish and promote new career paths?

Shaping career paths—towards a taxonomy

Within the RSE structure, there is currently no well-defined career progression beyond ‘RSE’ and ‘Senior RSE’ (in contrast to the well established academic career structure of post-doc, lecturer, senior lecturer, and professor). For those staying within the academic stream, software-oriented roles can suffer from the fact that their contribution is not easily seen to translate into academic papers, the currency of academia. This can slow down or limit career progression. There are of course notable exceptions to this; people have made a great success of their software-facing roles, many reaching professorial positions on the back of this.

It is recognised that there is not a ‘one size fits all’ description of those in a software-oriented research career. Different research fields and institutional structures lead to a variety of roles fitting this description. To establish a well defined career framework for RSEs, the creation of a taxonomy of different paths may be a useful tool. A possible classification could be guided by the roles that software and RSEs play in this context:software as a service, software as a scientific instrument, RSEs as teachers, and hybrid roles for RSEs. The use of such a framework might help with identifying contextual problems and proposing solutions.

To establish a useful career framework, it is crucial that the RSE community and others in similar roles identify what their envisioned career path would look like: without a clear vision of that path, how can we ask for it, and how can institutions and funders fulfil that vision? Understanding the views of the community on this topic is essential, and so surveying the members would be a useful starting point to identify past career paths and generate ideas for the future.

One important aspect in the establishment of an RSE career framework are clear measures for success, which can be used to define career progression. One suggestion would be to treat software like scientific hardware—it requires upfront and ongoing funding, but directly or indirectly makes new research possible, which sounds quite like a lot of software development for science! A study of data in the area would also help to demonstrate the impact of this work.Another suggestion is the use of computing facilities as hubs. This already happens in places in the UK such as EPCC, Daresbury and RAL, as well as internationally, and it has benefits of visibility and removing duplication. However, it is not always suitable as many researchers have software needs far below those delivered by such facilities, and would be unlikely to engage at that level.

Finally, there are a number of working solutions in other countries. There are some good examples in the USA, e.g. in the Space Telescope Science Institute [2], or LSST [3], and also at the national labs. For example, the CASC group at Lawrence Livermore National Lab [4] is specifically developing software for supporting science projects and the highly success PETSc solver library is developed at Argonne National Lab [5]. Understanding the reasons for their success, and learning lessons from them, would benefit the community, and additionally act as demonstrations to funders of the benefits of their approaches.