Overview

This is a time of great growth at the intersection of software engineering and scientific software. The 1st and 2nd International Conference of Research Software Engineers took place in Manchester, UK. Companies are already heavily invested in the application of software engineering practices on scientific software (e.g. Microsoft Research Agile Projects team, Mathworks, Tessella, and NAG).

Despite its importance, the development of scientific software historically has attracted less attention from the software engineering community than other subdomains have. Indeed, the development of research software is significantly different than the development of business information systems, from which many of the software engineering best practices, tools and techniques have been drawn. Rather than drawing on each others' experience, the two communities can often seem in conflict. Additionally, the majority of published software engineering studies focus on industry or open source software projects rather than scientific software projects. As a result, software engineering research is often seen as unhelpful or useless to those developing scientific software, or indeed software in general, which is detrimental to the long-term production of reliable, reproducible and reusable scientific software.

In part, this disconnect results from the unique characteristics of the research environment which impact the choice of software engineering practices. Those characteristics include:

• Exploration of unknown science implies that many requirements (beyond the laws of nature) cannot be known \textit{a priori} and must emerge throughout development.
• Investigation of new scientific results implies that the software's expected output is sometimes unknown, making test oracle definition difficult or impossible. As a result, traditional software testing approaches are problematic.
• Different project lifecycles ranging from the ''lone researcher'', where a single scientist develops software to test a hypothesis and then discards the software to those that last ten years or more, run on complex parallel systems, and remain in constant development throughout their lifetime.
• Many scientific software developers are experts, often with a PhD, in the underlying scientific domain, but have little formal training in software engineering methods, tools and techniques. It is not uncommon for a single scientist to take on the role of software developer and rely solely on the internet to acquire relevant software development knowledge.
• The business driver is generally the publication of a paper, not the production of software.
• The need for better, trustworthy data associated with the use of software engineering practices in the research software domain.
• The need to identify appropriate educational topics for current and future developers of scientific software.

Thus the motivation for this workshop is to bring the communities together, to jointly work on research that will benefit both, and to provide examples of high quality research and datasets that will improve practice in the field.

Goals

Most conference and journal venues are either software engineering-focused or domain-focused (i.e. computational chemistry or computational hydrology), but rarely on the intersection of those domains. Specifically, within the scientific software community, there are few places to publish results related to the unique software engineering challenges faced by scientific software developers. The goals of this workshop are to:

• Provide a venue for members of the software engineering and research software communities to discuss issues relevant of common interest.
• Identify aspects of software engineering that should be considered for research software education programs at large.
• Identify key areas of study where participants agree there is a lack of existing data or studies.
• Support the building of a common research agenda to address the complex software development issues typical of research software.
• Provide a venue for sharing early work and work-in-progress to obtain feedback from the wider community.

---

Last Updated on November 30, 2017 by Jeffrey Carver