bitbucket
A thorough and more detailed analysis giving more context can be found here:

http://climateaudit.org/2009/12/10/ipcc-and-the-trick/
and here

http://climateaudit.org/2009/11/20/mike%E2%80%99s-nature-trick/

I think the context is fully understood now. Basically, a small cabal of scientists were using their position at the IPCC to game the results. Jones's infamous statement can be seen to fit in with this strategy. Macyntyre actually wrote to the IPCC as a reviewing editor to ask them not to mislead:

"Show the Briffa et al reconstruction through to its end; don’t stop in 1960. Then comment and deal with the “divergence problem” if you need to. Don’t cover up the divergence by truncating this graphic. This was done in IPCC TAR; this was misleading. (Reviewer’s comment ID #: 309-18)]"

In response, IPCC section authors said:

Rejected — though note divergence’ issue will be discussed, still considered inappropriate to show recent section of
Briffa et al. series.

@Bitbucket - thank for the reply. As an IT person I'm really curious as to your take on the "Harry Read Me.txt" file which catalogues the poor quality and subsequent fudging of the UEA temperature record?

Go on, indulge me :-)

Interesting file !!! Well not really interesting - I only made it through 500 lines or so (of 15k) but it seems to go on in the same vein. Was there anything in particular I should have read?

I don't know the background to it, but is seems like a log made by someone who took over from 'Tim' and got a nasty shock. I wonder what he was told at interview about the task.

I don't know what you want me to say. To defend the UEA "system"? Not really possible is it? Except that I don't imagine it is that uncommon in academia or in industry.

I have not worked in academia, but if it helps, I can say is that in industries where I have worked (defence, tv/video, oil-services, measurement instruments, mobile phones, industrial control), quality systems, source control etc have often been non-existent or implemented by engineers in the course of the project. And engineers (including me) are not the best people to do that as they are usually more interested in the project than in source control and quality systems. I don't believe there are many programmers who haven't at one time (or many) found that they have several copies of their old work saved away and don't know which one is the 'correct' one. No doubt the programming experts here will label me as just an incompetent fool who doesn't know where his towel is, but I'm just telling it how I have known it.

Only in one contract in 20 years have I worked for a company that took quality seriously (oil-services). I imagine they had a quality department, although I don't recall it. Lack of source/version control, which seems a big part of Harry's problems, was commonplace in the 90s although less so more recently as people have more contact with common source control programs. But even in 2001-2 a small company I worked for had such completely lacking quality control that it spent months debugging hardware designs and then re-laid-out the boards only to find that many of the same problems were still present - there was no system for noting what problems had been found. The company later went bust. Many big companies' attitude to quality is just box-ticking; the quality department being just one man or none at all. Small companies I have know don't have time or resources for any more than source control.

I have always worked in embedded systems and not consumer application design or business services. Perhaps things are better organised in such companies. But in academia, I would imagine things are nearer to my experience. A quality department in a university? That knows something about software quality control? If such a thing exists I would be really surprised.

BitBucket... as someone who has worked in your industry for 20 years, I concur that many companies have a slipshod attitude to version control, source control, quality etc. This was much worse in the 90s.

That doesn't excuse CRU in any way. As you said, the companies with the worst record go bust - so there is a selection process going on in that only the ones who adopt quality measures survive.

CRU, on the other hand, do not go bust, since they suck at the public teat, and thus have no incentive to adopt modern quality methods. As the recent "counting defects as a measure of quality" scandal attests, they haven't moved out of the 90s.

James, I was not defending either CRU or private companies. Merely pointing out the way it is. By all means get upset by the way CRU handles software and data. They should be upset too - it is an expensive and frustrating way of operating. But CRU is just the tip of the iceberg. As we both know, quality is difficult!