I became a computer programmer in 1966. In my early years programming involved writing reams of coded instructions which were then executed on a one-to-one basis by the hardware of the machine. Such programs took uncountable trials before they produced any believable (and not necessarily correct) output. Attempts were made to tame this problem by insisting on the production of a “flowchart” before starting to write the code itself. The flowchart was typically an enormous rambling diagram of squares (processes) and diamonds (yes/no branching decisions). The logic of the program was verified(?) by tracing various possible paths through the flowchart, but the huge number of combinations caused by the decision points made exhaustive testing totally impracticable. These problems continued even after the widespread introduction of “high-level” (user-friendly) programming languages.

Luckily the esteemed Edsger W Dijkstra (see Wikipedia) came to the rescue (1968) by introducing the concept of “structured programming” which replaced the hitherto intractable “spaghetti” code with a disciplined hierarchy (nesting) of independent modules named according to their process and within which were allowed only two sorts of decision-point, characteristically “IF condition do process” and “UNTIL condition repeat process”. The unrestricted “GO TO distant point and continue processing” was thenceforward strictly prohibited and a new era of professional software writing began.

Climate science as currently practised demands many areas of skill: physics, oceanography, meteorology etc etc, including of course the use of statistics and the development of computer models.

Recently it appears to have been found wanting in the proper use of advanced statistical methods.

Consequently I would want to be persuaded that its programming competence does convincingly reflect the current state of commercial software professionalism.

As a minimum level of “quality assurance” it could be insisted that all significant code be independently developed by at least two programmers and that the outputs corresponding to a given input in each case be shown to be identical. Otherwise no result can be regarded as trustworthy. Given its importance, I am sure that nothing but the highest level of professional software competence in climate science can be acceptable.

Simon,

I think you are overlooking the 'luring away' effect.

In most research work where there is code to be written, the researcher is expected to put together a few hundred lines of FORTRAN, and they will have done a quarter term course on programming. There isn't the money, or the culture, to write a spec and pass it over to software specialists. It's difficult to argue it should be otherwise.

Mostly it doesn't matter. If the research is shown to be invalid because of programming errors, it reflects on the researchers and it ends there.

What's different in climate science is that the policy consequences, which are almost non-existent in most areas, are huge. This hasn't come about overnight. So there was a 'good enough', slapdash culture maintaining datasets fundamental to a discipline which has become hugely important.

GCMs are a different matter. I'd say that no matter how well designed and coded the algorithms, the basic quest of modelling a system consisting of a many linked, non-linear, chaotic systems, where not all the factors of the problem are known anyway, and hoping to produce usefully predictive results of what the system will be doing decades hence, is hopelessly over ambitious.

cosmic "the basic quest of modelling a system consisting of a many linked, non-linear, chaotic systems, where not all the factors of the problem are known anyway, and hoping to produce usefully predictive results of what the system will be doing decades hence, is hopelessly over ambitious"

Agreed absolutely.

But my further point is that even if we could in principle model a system which accounted for the all the myriad aspects of the physics involved and which could therefore be expected accurately to predict the evolution of the climate, such a model would still have to be represented by a software system of such astounding complexity that its correct (intended) functioning in any relevant detail could never realistically be authenticated or verified. (And, I would suggest, nor can today's).

Simon,

Then there's the question of validating a model predicting (or producing 'projections') of things decades hence.

It isn't like producing a model of an electronic circuit or a traffic system where you can model a circuit and then build it and see if the model agrees with reality, or check it against actual traffic systems and see what happened when say, a road was closed because of an emergency or there was a football match.

Then there's the problem of cumulative errors.

I don't see GCMs as anything more than a propaganda tool. Laymen are impressed by computers in general and especially supercomputers costing millions and fall for arguments such as 'aircraft are designed with computer models'. Computer models are useful in aircraft design, but it certainly isn't a matter of bunging the requirements into a model, the design drops out, and then it's put into production.

Wrong units and values can creep in undetected, buried deep in the detail of the processing. One is reminded of the Hubble telescope debacle. In that case the error soon became apparent (not soon enough) but similar errors in the GCMs could remain unsuspected for years.