The Scientific Software Lifecycle
Research code that others will rely on passes through the same disciplined stages as any engineered software, adapted for evolving physics.
Beyond the Throwaway Script
A script written to produce one figure and a code that a program of work depends on are different artifacts with different obligations. The lifecycle idea is that the second kind must be built, tested, documented, and maintained deliberately, even when its authors are scientists rather than software engineers. Neglecting this is why so much research code is unreproducible a year after publication.
Stages
- Requirements: what physical question must this answer, at what accuracy?
- Design: governing equations, discretization, and modular structure.
- Implementation: readable code under version control.
- Verification and testing: unit tests, convergence tests, regression tests.
- Validation: comparison to experiment in a stated regime.
- Release and provenance: tagged versions, recorded inputs, archived environment.
- Maintenance: bug fixes, refactoring, and controlled evolution of the physics.
What Makes Scientific Code Different
Scientific software has no fixed specification the way a payroll system does; the specification is the physics, and it is discovered as the project proceeds. Correctness often cannot be checked by inspection because the right answer is unknown. This raises the value of verification against analytic limits, convergence studies, and cross-code comparison, which stand in for the missing oracle.
Discipline Under Uncertainty
Because the model itself changes, the lifecycle must record why each change was made and preserve the ability to reproduce older results. Kronos design work treats each frozen result as tied to a specific code version, input set, and environment, so a claim can be reproduced and audited even as the underlying physics model continues to evolve.