Climategate underscores the importance of projects like Clear Climate Code. They’re software engineers who are rewriting a key model (GISTEMP, which models Global Historical Climate Network data from the Goddard at NASA) so that the model is clear and understandable and verifiable. I tried to write a multiprocessing extension for a school project, but couldn’t verify the results due to equipment problems.

Science models & data are massaged all the time. A dirty fact, but common across many disciplines. The bottom line is, if the models in question have predicative power, anthropogenic climate change is real. If not, then climate change may still be real, but we must wait for better data and/or better models. Academic models of complex, schocastic systems are always ugly code in my experience. That doesn’t negate their validity.

That being said, scientists writing models aren’t often software engineers, and the data collection and collation is incredibly complex and messy with many possibilities for errors. Code and data should always open-sourced for verification, and keeping such things to yourself is inexcusable and a violation of how science should be done.

However, I highly doubt there’s a climate conspiracy cabal hiding a secret data db. All the data I’ve seen is open and freely available (and really messy!). Seeing those emails as suspicious appears as confirmation bias to me, no matter how much of a persecution complex the individuals in question appear to harbor.

“It is this culture of trust along with the functionality of A-Space and the classification level, which supports the analytic benefits…through interaction.”

In her superb ethnographic study of DIA analysts using A-Space, Nancy Dixon provides a gold mine of research and conclusions regarding how the Intelligence Community uses social software (found from Lewis Shepherd’s tweet via Christopher Dorobek’s blog (and check out the YouTube Intellipedia informercial in his post!). Many of the conclusions are general to writing social software for anybody. But there are a few lessons specifically for those of us who author software targeted at the Intelligence Community.

1. Save the user a meaningful chunk of time compared to their previous process. Walking around cubes to ask 7 different colleagues the same question? A-Space lets analysts just type out the question and post it to their entire A-Space network, posing it to both strong ties and weak ties.
2. If there is user-generated content, give the user a profile that can be made interesting to other users. Software projects always forget that users are people. We all want to be known. And we all are curious about other people. Profiles, even if they are static or rarely updated, provide meaningful connections and context to users. A picture creates a more powerful personal connection than a username.
3. Make creating content easy. Duh. But measure the time it takes. Under 5 minutes to publish? Or 5 pop-up dialogs and 10 minutes?
4. The power of the URL over shoeboxes. The web’s fundamental utility is to give every piece of information a Uniform Resource Locator. A-Space takes inter-agency email and email threads there were stuck in private mailboxes and gives them a URL that is accessible across the entire IC.
5. Good-enough may not be compelling enough. Think back to Myspace v Facebook. Facebook had to compel each new user to sign up there and not at the good-enough Myspace.
6. Superstar users are a feature. We all want to be known as awesome. Give people the ability to gain name recognition and credibility. Jon Skeet at StackOverflow is my de jure example of this, a nobody until he found the right venue in which to express his awesomeness. Give n00bs access to greybeards, and lets the greybeards be hailed as such.
7. Users at every classification level need tools. Compartmented TS/SCI information is information too, and it wants to be free. Intellipedia serves non-compartmented U/S/TS information. A-Space serves TS/SCI information. Different tools, different classification levels, but fundamentally the same software: users and URLs instead of personal shoeboxes stuffed with inaccessible private stashes.
8. Make the early adaptors and lurkers happy. Duh. But say only 1 person on a team uses your software, but keeps using it. You have a successful product. Not everyone will integrate into your software’s workflow. And the lurkers are valuable for their off-line evangelism of your software.
9. Decide whether you want users to be cruel. Sounds like an easy choice, right? But if your software serves analysts, it may be important to architect your software to allow users to criticize and dog in order to allow the creation of a more-robust product. Doubts are information too.