Evaluation of RSE performance

Bernadette Fritzsch, Jan Philipp Dietrich, December 6, 2023


Research software development plays an increasingly prominent role in today’s research landscape. However, there are still no clear career paths for individuals with a dedicated focus on research software, often referred to as Research Software Engineers (RSEs). RSEs often work as traditional researchers, given their background in research, but this strategy typically involves a goal conflict.

While focusing on research software can enhance its quality and, consequently, the quality of the associated research, these efforts often do not result in traditional publications. Publications are the conventional performance indicators that significantly influence further career progression within the academic system.

Therefore, the question of a career path for RSEs is directly tied to the question of an appropriate evaluation of RSE performance. This issue was chosen as the focal point for a session at the un-deRSE Conference in Jena, where we explored the best ways to evaluate RSEs. Can RSEs be evaluated using the same criteria as traditional scientists, or do we need entirely different metrics? The direct outcomes of this discussion can be viewed at https://pad.gwdg.de/ghuWQ2E9Tomo19Cwe67aXw.

In an engaging conversation, it became evident that even the traditionally used indicators are subject to criticism and selecting suitable performance metrics for RSEs is challenging if not impossible. However, a general direction for meaningful evaluation emerged.

Broadly speaking, three core areas were identified as playing a role in the performance evaluation of an RSE:

Given that the term RSE encompasses a spectrum of diverse job profiles with varying allocations between scientific work and software development, the weighting of these indicators is flexible. In this regard, indicators relevant to traditional scientists may also apply to RSEs. Although RSEs focus on research software, their ultimate goal is to generate high-quality scientific output.

However, a sole focus on traditional indicators falls short. Research software is not only a means to conduct research but is also an outcome of research itself. Therefore, research software should be considered as a specific type of scientific output and appropriately accounted for in the evaluation. With the increasing prevalence of research software publications, this is now feasible.

In discussions, a third aspect was highlighted, which may initially seem unexpected but is an essential component of an RSE’s role upon closer inspection. This pertains to communication. RSEs must be capable of explaining software engineering concepts to traditional scientists while also understanding and explaining the domain-specific questions and associated problems of scientists. Thus, being proficient in programming is not sufficient for an RSE; effective communication and the ability to comprehend scientific inquiries are equally vital.

By considering these three areas, a more comprehensive evaluation of RSE performance should be possible. This could pave the way for the development of new career paths for RSEs in academia parallel to those for traditional scientists, ensuring the continued integration of RSE expertise within the academic system.