OverviewThis 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.
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.
GoalsMost 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.
Last Updated on November 19, 2018 by Jeffrey Carver