Research Software Science: Expanding RSE Impact through Scientific Practice

Research software engineers (RSEs) aren’t just coders. They are the people who make scientific software actually work in real life. They bring experience from one project to the next and help research software become more reliable, reusable, and easier to adapt. But a lot of what RSEs do involves informal experimentation with tools, techniques, processes, and team practices, which are very rarely formal or repeatable, or designed to generate sharable knowledge. This article, Research Software Science: Expanding the Impact of Research Software Engineering, introduces Research Software Science (RSS) as a way to treat software development and use as a scientific problem, giving RSEs a framework to turn experience into reproducible, shareable knowledge.

The paper starts by introducing RSS and its approach to understanding how research software is developed and used. It looks at the technical aspects, the way teams interact, and how individual researchers think about problems, using observation, experimentation, and data to understand what works in research software. It goes beyond routine RSE practice by systematically studying team dynamics, user interactions, and software workflows. The paper proposes a research-develop-deploy pipeline, where deployment challenges feed research questions, research results guide development, and new software capabilities are redeployed. This approach formalizes experimentation and learning, transforming project-specific insights into broadly applicable knowledge that can improve future projects and teams.

Finally, the article argues that treating research software as a scientific problem can make software more reliable, reusable, and sustainable. It states that it can improve team performance, guide design and user experience, and help funders see the real value of supporting software.

Folks reading this article will walk away with an understanding of RSS, how it complements RSE work, and a model for applying a scientific lens to software development. For anyone building, managing, or funding research software, this paper may provide both a framework and a strong argument in favour of why software deserves to be studied as science in its own right.