Thermonuclear code

Dave Wilson concerns himself with the misguided use of code-generation software and the fearful consequences it might have.

‘I can no longer sit back and allow communist infiltration, communist indoctrination, communist subversion, and the international communist conspiracy to sap and impurify all of our precious bodily fluids’ – Base Commander Ripper (Dr. Strangelove, 1964).

When the multi-national defence contractor won the deal to update the new ‘mission-critical’ software for the nation’s nuclear defence system, no-one was more excited about the challenge than the head of the company’s engineering department.

Faced with a two-year timeframe until deployment, the man in question decided upon (what was then) a novel programming methodology to reduce the number of man hours that it would take to generate the thousands of lines of code needed to complete the project.

The new concept, code-generation – the automated building of high-level code from a description of the requirements of the code – promised to save hours of programming time. And that meant that the guys in the software department could spend more of their time more accurately defining the problems that needed to be solved at a much higher level, rather than twiddling with bits and bytes.

And so that’s what they did. At one of the meetings, they had a brainstorming session on the exact requirements that would trigger a national response to an attack from foreign ICBMs. Either one’s that were in the air – or in the truly worse case scenario – those that had already landed with some effect on the nation’s cities.

The existing system had worked pretty well in the past, differentiating between a real attack and a false alarm by acquiring, processing and correlating data from satellites that tracked the trail of incoming missile engines and radar systems that tracked the actual missiles themselves.

But, given all the extra time they had on their hands because of the new code-generator technology, the new kids on the block decided to enhance the system. More specifically, they wanted to incorporate a new ‘launch under attack’ feature that would allow the country to ‘retaliate’ as soon as ‘reliable evidence’ was received that the threat was real.

So they set about defining the meaning of ‘reliable evidence’. One bright spark on the team had read the TTAPS (Turco, Toon, Ackerman, Pollack, and Sagan) proposal that describes the creation of a ‘nuclear winter’ when lots of soot is thrown up into the air from burning cities hit by a nuclear weapon. And so he proposed a new criterion that would automatically trigger the defence system to ‘autorespond’ to a threat should remote sensors on the ground detect an ‘unnaturally low level of sunlight’ during the day. A level so low, in fact, that only a nuclear weapon could cause it.

No-one challenged the idea. So it was bundled up in a new set of high-level system specifications and fed through the code generator, which mindlessly delivered the thousands of lines of system software that were then rigorously tested in the field and finally deployed.

The code ran perfectly. And the fellas in the software department felt very satisfied with the role that they had performed in maintaining the nation’s defences.

Until one day, there was a total eclipse of the sun and a great darkness fell across the land. The software, of course, performed as specified. And then it got darker still.