#### Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Options

# Software engineering in climate science

I've been sufficiently annoyed by several discussions about the quality management processes of climate models, to write Software engineering in climate science. For starters, to explain the difference of validation and verification.

Before we start an interdisciplinary discussion, we first have to agree on a terminology...

• Options
1.
edited December 2010

I think one thing that's going to be a problem in this discussion is that a lot of software engineering practice assumes, and often has, tasks for which one can write a meaningful high-level specification (your book reader is an example: your top level specification doesn't need to refer to things like the ECC in the ISBN). In contrast, I've found a lot of "investigative scientific programming" often doesn't have precise enough statements to write a spec against which one can look at various things. Especially since often numerical issues aren't easily made binary for specification purposes (eg, The Matrix Inversion Lemma is a technique for updating an inverse matrix under a small perturbation. It's use can dramatically cut down on run time expense, but it's also significantly less accurate in FP than calculating an inverse from scratch, particularly if used repeatedly. Does a routine that uses it fulfill a spec that is written in "real number" mathematics? Often the only answer is "it's ok if it's errors are smaller than the unavoidable noise elsewhere in the complete program, otherwise not", which isn't really a useful specification.)

That's not to say your discussion is not worth doing, but I think a lot of the issues will founder upon the rocks of specification issues.

(I did my MSc on formal methods before moving into computer vision, and it took a while for it to sink in that for most of the investigative programming there wasn't a clear enough spec to bother doing anything with.)

Incidentally, I'd be tempted to extend

When programming is compared to masonry, then software engineering can be compared to architecture.

to

When programming is compared to masonry, then software engineering can be compared to a mix of architecture and construction site "project management".

but it's a matter of taste, so I won't make the change directly.

Comment Source:I think one thing that's going to be a problem in this discussion is that a lot of software engineering practice assumes, and often has, tasks for which one can write a meaningful high-level specification (your book reader is an example: your top level specification doesn't need to refer to things like the ECC in the ISBN). In contrast, I've found a lot of "investigative scientific programming" often doesn't have precise enough statements to write a spec against which one can look at various things. Especially since often numerical issues aren't easily made binary for specification purposes (eg, The Matrix Inversion Lemma is a technique for updating an inverse matrix under a small perturbation. It's use can dramatically cut down on run time expense, but it's also significantly less accurate in FP than calculating an inverse from scratch, particularly if used repeatedly. Does a routine that uses it fulfill a spec that is written in "real number" mathematics? Often the only answer is "it's ok if it's errors are smaller than the unavoidable noise elsewhere in the complete program, otherwise not", which isn't really a useful specification.) That's not to say your discussion is not worth doing, but I think a lot of the issues will founder upon the rocks of specification issues. (I did my MSc on formal methods before moving into computer vision, and it took a while for it to sink in that for most of the investigative programming there wasn't a clear enough spec to bother doing anything with.) Incidentally, I'd be tempted to extend > When programming is compared to masonry, then software engineering can be compared to architecture. to > When programming is compared to masonry, then software engineering can be compared to a mix of architecture and construction site "project management". but it's a matter of taste, so I won't make the change directly.
• Options
2.

Right, that's a point that Steve Easterbrook has made several time on his blog, quite convincingley. I'm very hands-on, although I'm currently writing a specification for an IT system for BMW, I have no problem to accept the fact that the very idea of a specification is useless for climate models (what would be useful is part of Steve's research).

...it's a matter of taste, so I won't make the change directly.

The "head mason" would be the one who acts as a broker and does the construction site project management, with a casual involvement of the architect - in the software industry there is the role of "technical lead architect" or "technical chef designer", which is a mixture of both.

Anyway, the analogy is useful to tell people that there is more to software construction than programming languages and build tools :-)

Comment Source:Right, that's a point that Steve Easterbrook has made several time on his blog, quite convincingley. I'm very hands-on, although I'm currently writing a specification for an IT system for BMW, I have no problem to accept the fact that the very idea of a specification is useless for climate models (what would be useful is part of Steve's research). <blockquote> <p> ...it's a matter of taste, so I won't make the change directly. </p> </blockquote> The "head mason" would be the one who acts as a broker and does the construction site project management, with a casual involvement of the architect - in the software industry there is the role of "technical lead architect" or "technical chef designer", which is a mixture of both. Anyway, the analogy is useful to tell people that there is more to software construction than programming languages and build tools :-)