The Detonate Instruction
Engineering Insights
This is a story told to me many years ago by a buddy who once worked at TRW.
TRW, as many of you will recall, was a major military contractor, and this guy had been working with some old computer technology — namely, the guidance computer from a Minuteman I missile.
The Minuteman I was the first-generation of ICBMs deployed by the United States, back in the 1950s. The guidance computer was a hollow cylinder about 2 1/2 feet in diameter and about 18 inches tall. In fact, if you visit the Computer History museum in Mountain View, you can actually see a Minuteman I guidance computer on display:
The story I am about to relate dates back to the late 70s, long after the Minuteman fleet had been retired.
The Minuteman computer was extremely primitive by modern standards — transistors and magnetic core memory were state of the art in the 1950s. But nevertheless, it was a computer, and could be programmed. The fellow that I knew had been using the computer for some purpose other than its original intent — I never learned exactly what.
The computer came with an instruction manual, written by the Air Force. According to my friend, “the Air Force tries to make everything as dull as possible”, and so it was: there was a page for each instruction, which had a uniform format. For example, the “ADD” instruction had a page describing the addition of two registers, a description of the condition codes (overflow, etc.), and a code example showing a typical usage of the instruction.
Except for the “detonate” instruction.
Now, those of you who are familiar with modern processors will be going, “Wait? There was a detonate instruction?”
You see, modern CPUs don’t have instructions for specific hardware devices — there’s no “print” or “write file” instruction on an Intel or AMD chip. Instead, there are general purpose i/o instructions which can communicate with any type of output device.
But the Minuteman computer was built in the early days of computing, for a specific purpose, before computers had evolved to the degree of generality and universality that we experience today.
So the manual page for the detonate instruction looked something like the following (note that I only ever got a rough verbal description, so I’m filling in the details with my imagination, based on my experience with Air Force documentation— take it with a large grain of salt):
10.13.1 DET (detonate)
This instruction detonates the warhead.10.13.2 Condition Codes
There are no condition codes after this instruction has executed. The presence of any condition codes indicates that an error has occurred.10.13.3 Example Code DET
BRA error_routine
There’s a bit of nuclear gallows humor here — “if the computer still exists at this point, then something has gone wrong.”
One question that springs forcefully to mind is, “what happens if you accidentally execute the detonate instruction, or there’s a bug? Surely there are some electronic safety interlocks that would prevent accidents, right?”, to which my friend replied, “Naw, you could blow it up in the silo if you wanted to.”
There’s an interesting philosophical point here about error handling, one which my friend told me along with this story.
You see, when the DET instruction is executed, even if the bomb fails to explode, the warhead is still going to crash into the ground at several times the speed of sound. There is no one it can report the error to, no action it can take that will remedy or mitigate the problem. The warhead is incapable of writing a log file or opening a trouble ticket.
So the lesson my friend told me is this: “Never check for an error condition that you can’t do anything about.”
A somewhat related maxim is, “Never check for a failure you really don’t care about.” In other words, if you really don’t care about the failure, then it’s not really a failure, is it?
If I tell you to go to the store and bring me a dozen eggs, and I tell you to take Pine street, but instead you take a shortcut on Bryant Ave., is that really a failure? All I really care about is that I got my eggs in a reasonable time frame. Should I refuse to accept the eggs or pay you back because you didn’t follow my instructions exactly?
Similarly, when writing tests, a lot of people struggle with tests that are too specific, too rigid— tests that test things they don’t care about. Such tests tend to be brittle and flaky; they fail even when nothing is wrong, because something changed — something you don’t care about, other than the fact that it made your tests fail.
The true meaning and purpose of an error is how we react to it.
