Dubois on Maintaining Correctness

This post originally appeared on the Software Carpentry website.

Something else I didn't get to at the Met Office last week:

Paul F. Dubois: "Maintaining Correctness in Scientific Programs". Computing in Science & Engineering, May-June 2005, http://doi.ieeecomputersociety.org/10.1109/MCSE.2005.54.

Please, please, please, if you're building scientific software of any kind, find a copy and read it, because it's the best explanation I've ever found of why the right way to do it is, well, the right way to do it. Paul ties together a banker's dozen good ideas under the banner defense in depth: no matter how scrupulous we are, any of these might fail, so we have others in place to catch the mistakes that creep through. To quote the list that opens the paper, they are:

• Protocol for source control. Policies and procedures for managing the source can isolate errors when they occur.
• Language-specific safety tools. Each computer language has some facilities for ensuring correctness, but they're often underutilized.
• Design by contract. Bertrand Meyer's design by contract (DBC) methodology is a good fit with scientific programming, and its optional runtime checking of the contracts catches many errors.
• Verification. Defending against bad user input or data is separate from checking contracts.
• Reusing reliable components. We use third-party libraries for many things; the biggest benefit of reusing code isn't that you don't have to write it, but that the software is more likely to be correct already.
• Automating testing. A simple automation of testing procedures makes it easier to do as much testing as you ought to.
• Unit testing. Hand-in-hand with DBC, unit testing ensures component integrity.
• To-main testing policy. We insist on a certain level of testing before committing developments to our "main line."
• Regression testing. Additional nightly or weekly testing on all target platforms catches problems caused by our own errors as well as those caused by changes in environment.
• Release management. A disciplined approach to release management gives most users a stable experience.
• Bug tracking. Simple open-source tools can help make sure issues don't get lost.

It's only six pages long, including a couple of ads that you can skip: please, like I said, give it a read. (And note to self: I really need to turn this into a lecture...)