Software as an Engineering Discipline
Scientific software that drives real decisions must be built with the rigor of any other load-bearing engineering.
Beyond scripts
Much scientific code begins as a script written to answer one question. When the same code starts informing a design that will be built, it becomes infrastructure, and it must be engineered accordingly — tested, versioned, reviewed, and documented.
The core practices
- Version control for every change, with readable history.
- Automated tests that run on every change.
- Code review by a second person before merge.
- Documentation sufficient for someone else to run and trust the code.
- Pinned dependencies so results are reproducible.
Why rigor pays
A silent bug in analysis code does not announce itself; it produces a plausible wrong number that propagates into a decision. The cost of finding it late is far higher than the cost of the tests that would have caught it early. Engineering discipline is cheaper than debugging a committed design.
Correctness has layers
Software can be correct in several senses: it runs without crashing, it solves its equations correctly (verification), and its equations describe reality (validation). Treating these as distinct requirements prevents the false comfort of code that runs cleanly but computes the wrong thing.
Culture, not just tools
Tools enable discipline but do not create it. The habit that matters is treating every number a program emits as something that might one day be defended in front of skeptical reviewers — and building the code so that defense is easy.