The Large Hadron Collider is a bit like our Connecting for Health programme.
CERN fired billions of protons in a circuit in an attempt to catch a glimpse of the elusive Higgs Boson particle. Whereas NPfIT fired £12bn around a small conglomerate in an attempt to create huge bonuses.
But while our public sector contract was judged a failure, CERN has so far been a massive success. What lessons can we learn from CERN?
There's been a lot of criticism of the public sector recently. To be fair, civil servants didn't bodge up the NPfIT or the NHS Connecting for Health programmes on their own. They had to work in partnership with private industry to squander that £12bn.
The boffins at CERN provided a better example of how IT should be done in the public sector, with their work on the Large Hadron Collider, and here were two significant differences in the way they worked.
According to Fons Rademakers, who has spent 22 years as a developer for CERN, and was project leader for the building of the software for the Large Hadron Collider, there was a unity of purpose among the developers that made collaboration between the seven main developers so much smoother. There were no hidden agenda, no information held back, complete openness and honesty and trust. You don't always get that in the private sector.
The other significant advantage the developers had was a reality checker, in the form of Coverity's testing tools. If only the NPfIT had an equivalent reality check perhaps this country might have saved a few bob.
CERN's developers had been working since 1995 and wrote 31 million lines of C++ code. One of them had decided to try out Coverity to test the veracity of his own coding and liked the results. He persuaded the project manager to adopt the system for the entire development code base. The results were a bit of a wake up call, says Rademakers. Unlike NPfIT, they nipped them in the bud.
"Users find problems in the normal scheme of working, but Coverity still managed to unearth some semi-embarrassing events," he says. Bear in mind, this semi-embarrassment refers to events that were unearthed in the testing phase. Imagine the mortification if Coverity had not been used and the coding glitches had not been exposed?
The problem with modern development, using C++, is that it gives you so many options for moving a project ahead quickly. Unfortunately, that also creates more options for things to go wrong, if the code is not thoroughly tested (if I have understood the professor correctly!).
Whereas private sector IT seems to be about getting your releases in early and often.
There are four other developments at CERN, ranging in scale from 2.8 to 7 million lines of C++ code. Following the success of Coverity on the Hadron Collider project, it has now become the de facto standard tool for software testing-cum-reality checks.
Florian Moesch, chief developer at medical supplies company Drager, tells a similar tale. Coverity is brilliant at flushing out the bugs, such as uninitialised values, that are a nightmare to dig out and an even bigger nightmare if left in the programme. If you allocate space in memory for a variable, and don't reserve it properly, that totally distorts your entire schedule and renders all figures meaningless. "It would create a massive problem," says Moesch.
A bit like an NHS budget.
Moesch and Rademans had flown into Heathrow Terminal 4 and pitched up at the Hilton to give their presentation as part of a deal with Coverity to share their results. If only our own public sector fat cats could be so open!
Still, they're not perfect. Rademans confessed that CERN invested in an after-sales service from Coverity so that developers could be supported and trained. On reflection, it was probably unnecessary because "...the system is so easy to understand, and we found all we needed in the manuals," he joked.