Maintaining Correctness

This post originally appeared on the Software Carpentry website.

I'm re-thinking the lectures in the Software Carpentry course based on feedback from this term's students. I'm going to merge the three lectures on different development processes into one, and use the space that frees up to talk in more detail about programming style and software design—assuming, of course, I can think of something to say that isn't banal.

I also want to talk about the material in an article by Paul Dubois in the May/June 2005 issue of Computing in Science & Engineering called "Maintaining Correctness in Scientific Programs". Here are a few key lines from the introduction:

The more frequently a program is changed, the more difficult it is to maintain its correctness... Most programmers can reasonably tell when their programs are incorrect, but for scientific programmers, this is not the case. A bug that doesn't cause the program to fail in an obvious way could be indistinguishable from an error in modeling the real world with equations... Solving this problem must be the focus of our methodology, be it for a single person writing a 10,000-line program [or] a team of 20 or more writing half a million lines.

Paul then outlines a strategy based on defense in depth which has the following layers:

• a protocol for source control;
• use of language-specific safety tools;
• design by contract;
• verification;
• reusing reliable components;
• automating testing;
• unit testing (which requires automation to be effective);
• to-main testing policy (i.e., code must be tested before being integrated from a branch into the main line);
• regression testing;
• release management; and
• bug tracking.

This immediately struck me as an excellent way to organize and motivate several important parts of the course. It also points out some holes that I'll need to fill. Oh, to have more hours, and more hands...