Scientific Software Development Is Not an Oxymoron

Abstract

Many scientists and engineers spend much of their lives writing, debugging, and maintaining software, but only a handful have ever been taught how to do this effectively: after a couple of introductory courses, they are left to rediscover (or reinvent) the rest of programming on their own.The result?Most spend far too much time wrestling with software, instead of doing research, but have no idea how reliable or efficient their programs are.''-Greg Wilson [1] A s Greg Wilson's American Scientist article [2] circulated on the ''bio-IT'' e-mail lists and blogosphere this past winter, many of us sighed, groaned, and smiled in recognition.The field of computational biology crosses the span between engineering and science-a surprisingly (to some) large gulf that typically is uncovered in the process of developing scientific software.Why opine on best practices for scientific software projects now?Computational biologists are taking on increasingly important roles in this Internet-enabled, information-rich, high-throughput era of biology [3].Analytics and algorithms must operate on disparate and relatively large datasets.Curation and peer review is essential to critical analysis of computational conclusions.Software applications are needed to aggregate, integrate, and manage data, tools, results, and discoveries.Computational biologists are involved as advisors to technical teams developing and maintaining long-lived data resources, as product owners for software development, as coding and algorithm experts, and as reviewers of proposals and manuscripts.Whether code is developed for use in a single laboratory or as part of a larger, multiinstitutional project, there are best practices worth knowing and following.We are starting with the premise that scientific software development brings together different cultures.A ''certified technology stack'' might mean a robust n-tiered architecture to some and an expensive waste of resources to others.We want to avoid fanning controversy over interdisciplinary science [4,5] and misunderstandings inherent at the interface between engineering and science [6,7].We hope to provide a common understanding so that we all-specialists and generalists-can work effectively on scientific software projects, increasing project efficiency, software longevity, user community acceptance, and translational impact.We see important similarities between the way scientists and software engineers approach and attack problems which may provide a general framework for successful scientific software development.Scientists are taught the scientific method from the time they perform their first experiments.Similarly, software engineers are taught about the software development life cycle before they write their first ''if'' statement.By understanding similarities between these approaches, we can layer some practical methods from the

Cite this work

No public copy is stored for this record, so only the metadata is cited.

Stored only when both papers are in the corpus — 101 citations exist upstream.

Papers that cite the same references — the relational fallback while embeddings are still backfilling.