Research Software Engineers and Software Engineering Researchers often use different terms for the same concepts, creating hidden communication gaps. This article explores how mapping their terminology can improve understanding, collaboration, and software practices
| Resource information | Details |
|---|---|
| Paper title | Do Research Software Engineers and Software Engineering Researchers Speak the Same Language? |
| Auhors | Timo Kehrer, Robert Haines, Guido Juckeland, Shurui Zhou, and David E. Bernholdt |
| Organization | Computing in Science & Engineering, IEEE Computer Society |
| Publication | IEEE CISE Volume:27, Issue:2, April-June 2025; DOI: https://doi.org/10.1109/MCSE.2025.3557236 |
In the article titled Do Research Software Engineers and Software Engineering Researchers Speak the Same Language?, published in IEEE Computing in Science & Engineering journal, the authors examine how RSEs and SERs often use different terminology and interpret software engineering concepts in distinct ways. Both groups aim to produce high-quality software, but differences in training and professional focus can lead to inconsistencies in understanding. This study builds on discussions from the Dagstuhl Seminar Research Software Engineering: Bridging Knowledge Gaps and seeks to identify where communication gaps exist.
In the article, the authors have described a systematic method for mapping terminology across the two communities, using the Software Engineering Body of Knowledge (SWEBOK) as a reference. They developed a schema to capture SE fundamentals, RSE practices, and the degree of awareness and adoption in each community. A web-based platform was established to collect community feedback, facilitate discussion, and refine mappings over time. Applying this methodology revealed three main findings:
Their initial observations show three trends:
Alignment of Terms: Many SE concepts have clear equivalents in RSE practice, even if the terms differ. For example, SWEBOK separates “requirement elicitation” and “requirement analysis,” while RSEs often combine them as “requirements gathering and analysis.” Shared techniques like user stories make it easier to build mutual understanding and provide a practical bridge between the communities.
Lack of Awareness: RSEs are often less familiar with detailed SE testing practices and may rely on basic tests, given that much research software is developed as a limited-lifetime prototype or demonstration. They do recognize the need for better testing and could adapt SER methods to fit these contexts.
Lack of Adoption: Even when RSEs are aware of SE practices, highly structured approaches like those in SWEBOK may not fit daily research software work, which is often exploratory and nonlinear. Requirements can change frequently during prototyping (and for some type of large-scale research software, the software requirements are often influencd from the infrastructure itself). Examining these gaps can help improve RSE practices and enhance SER understanding of research software contexts.
Overall, the study demonstrates that creating a shared vocabulary can improve communication, support mutual learning, and facilitate collaboration between RSEs and SERs. By combining a structured approach with community participation, the authors provide a foundation for greater alignment between these two groups, offering practical benefits for both research software development and software engineering research.
This article should be a useful resource for RSEs and SERs looking to strengthen collaboration and share best practices effectively.
