Models Methods Software

Special Pleading Continues

Professor Easterbrook continues the special pleading for exemption that is so common among software developers that have not yet properly addressed important IV&V and SQA issues. This latest version of Professor’s pleading includes the following aspects; (1) a Red Herring, (2) broad generalizations, and (3) appeal to authority.

Appeal to Authority ( His Own )
Professor Easterbrook has not yet cited any of the literature associated with IV&V and SQA for engineering and scientific software. Literature that has presented procedures and processes that have been widely accepted and proven successful. What more can you say about that? Self reference based on a position of authority always fails.

Red Herring
Professor Easterbrook is the only person who has suggested that IV&V and SQA procedures and processes that are applied to commercial software be applied to engineering and scientific software. The subject software is not generally developed fresh from scratch but instead has evolved over decades of time. The engineering community has developed procedures and processes that take into account this obvious and critically important aspect of real-world complex software. Easterbrook attempts to introduce a comparison of apples and zebras into the discussions.

Broad Generalizations
The activities Easterbrook describes are Standard Operating Procedures for every software project that I have experience with. Direct experience. It is not IV&V Lite; it’s plain and simple SOP. SOP is not IV&V and SQA; never has been, will never be.

Collaborative comparisons of software results, and more importantly collaborative comparisons with experimental data, have a very long history in engineering and science software. This software is almost always not commercial software. In my industry, this work started in the mid-1970s. In turbulence modeling the work started in the early 1980s with the (in)famous Stanford Olympics. Infamous because so many calculations got so many different wrong results by so many different ways, sometimes when using the same software; the same models, methods and software. Turbulence is a hard problem.

It is common in many industries for user groups to be formed around a single piece of software. These groups have members that number in the 10s to a few 100s. Importantly the groups focus on a single version of the software, the frozen production-grade version of the code. That’s a lot of eyes looking in detail into all aspects of a single piece of software. From how I understand Easterbrook, the same kind of effort in the GCM community is significantly diluted relative to this standard.

A Prediction
I predict that papers will be written by Professor Easterbrook, reviewed by friendly cohorts who are equally unaware of the literature which has presented the modern methods that are applicable to engineering and science software, published in only the proper peer-reviewed Scientific Journals, and be quoted in the next IPCC reports that the Climate Science GCM software is pure. However, as mentioned above, self reference based solely on a position of authority always fails.

Not Even Wrong
This Comment by John Mashey is simply wrong. Look around this site, and this one, and this one, and this one, and this one, and this one.

November 28, 2010 Posted by Dan Hughes | Documentation, Verification | Documentation, Validation, Verification | 3 Comments