Workshop Folder

Overview

This is a time of great growth at the intersection of software engineering (SE) and scientific software. For the purpose of this workshop, we define scientific software to encompass all research software, including software to support research in physical sciences, engineering, life sciences, social sciences, arts, and humanities. There have been three International Conferences of Research Software Engineers in the UK 2016, 2017, and 2018. Companies are already heavily invested in the application of SE practices on scientific software (e.g. Microsoft Research Agile Projects team, Mathworks, Tessella, and NAG).

Despite its importance, the development of scientific software has historically attracted less attention from the SE 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 SE 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 SE studies focus on industry or open source software projects rather than scientific software projects. As a result, SE 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, reusable and sustainable scientific software.

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

• Exploration of unknown science implies that many requirements (beyond the laws of nature) cannot be known a priori and must emerge throughout development.
• Investigation of new scientific results implies 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'', a single scientist developing software to test a hypothesis and then discarding the software, to those that last ten+ years, 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 SE 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.
• A lack of available time from scientific software developers to participate in studies that would provide better, trustworthy data associated with the use of SE practices in the research software domain.

In addition, there are increasing concerns regarding the fragility of these scientific software systems, which operate in a highly connected ecosystem with emergent properties, whose inter-dependencies can lead to cascading failures. Despite the emergence of clear and systematic SE approaches, the design and development of high-quality, sustainable software systems are still extremely challenging for software engineers involved in their design, development, and maintenance. As a result, the topic of software sustainability has also emerged as an important area of research in a number of fields within the subject area of computing including SE, requirements engineering, and human-computer interaction. The importance of sustainability and software as a growth research area has been further underlined by long-term funding initiatives from the NSF (USA) and the EPSRC (UK). However, even though the importance of sustainability is increasingly recognized, many scientific software codebases and systems are highly unsustainable. Despite increasing recognition in the field of SE, it remains difficult to assess the delayed systemic effects of decisions taken in system design leading to code smells, sustainability debt, brittleness, which ultimately lead to software decay and death.

Thus the motivation for this workshop is (1) to bring the communities together, (2) to jointly work on research that provide examples of high quality research and datasets to will improve practice in the field, and (3) to identify appropriate educational topics for current and future developers of scientific software that will help best practice to become embedded.

Goals

Most venues are either SE-focused or domain-focused (i.e. computational chemistry or computational hydrology), and rarely provide opportunities to publish results for unique SE challenges faced by scientific software developers. Our goals are to:

• Provide a venue for members of the SE and research software communities to discuss issues relevant of common interest.
• Identify aspects of SE that should be considered for research software education programs.
• 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.

In addition to the informal interactions among the participants, the workshop will produce concrete outcomes ranging from the commissioning of new collaborative studies arising from the discussions and publication of opinion/position papers in more public venues.

---

Last Updated on November 19, 2018 by Jeffrey Carver