July 22 1962: NASA launches its very first interplanetary probe, Mariner 1. It was supposed to do a flyby of the planet Venus, but instead, 4 minutes and 3 seconds after launch, the range officer had to abort the mission (blowing up the rocket by remote control over the Atlantic Ocean) because it had gone irrecoverably off course and if not destroyed would have crashed among heavily used shipping lanes.

The cost of the lost rocket and its probe, in 1962 dollars, was 18.5 million dollars. In 2015, the same value would be expressed as about 150 million dollars. And that’s not counting the costs of the congressional investigation, the bad publicity and cold-war security implications of failing on America’s first attempt at an interplanetary mission, and all that jazz.

So what happened? The main problem was a bug in the guidance system. It overresponded to needed course corrections, leading to positive feedback. As each overcorrection shoved it further out of line to the other side, requiring another correction, the rocket went into hysteresis and lost its course.

The first symptom of the problem was that communications with the rocket became difficult; the directional antenna mounted on the unstable rocket was only pointed at ground control approximately and in brief moments at the midpoints between overcorrections. However, even if communications had remained perfect, it is not at all clear that anything could possibly have been done about the guidance system error.

And where did the error come from?

Mathematicians employed by NASA had worked out the requirements for the course correction software, and somewhere in its middle, they had used the notation

by which was meant “the nth smoothed value of the time derivative of the radius R.”

And the guy doing the coding? He missed the overbar, and instead wrote code as if they had meant “The nth time derivative of the radius R.” Which is a completely different thing.

Several wags have called that overbar “the most exensive hyphen in history.” Which is, you know, wrong, because it wasn’t a hyphen at all, but easier than explaining the mathematical overbar notation to the general public.

Easier than explaining the mathematical overbar notation. Think about that. Could it be that mathematicians who were entirely used to their dense and idiosyncratic notation handed a specification to a coder who wasn’t, and never realized that they needed to explain and be sure that the notation meant the same thing to the coder that it meant to them? We may never know, but I hope that, since 1962, we’ve learned that dense notation and jargon are not a good way for people of different backgrounds and professional skills to communicate.

Inevitably, when either side lapses into the peculiar usages that their background and profession has taught them, they become difficult for the other side to understand.

Checklist Items:

• Eschew Obfuscation. When a requirements document comes in check it for anything that would be opaque to ordinary people. Be sure people who aren’t from the field in question can at least tell what of it means. If they can’t, you shouldn’t bank on your coders being able to and you should insist that the requirements document be written again in non-jargon. Even if that makes it a lot longer.
• Have a subject matter expert discuss the requirements directly with the engineers. Every mind and every document that separates subject expertise from coding is another mind or another document that has an opportunity to misunderstand or be misunderstood. You don’t want to be playing ‘telephone’ with requirements documents.
• Have a subject matter expert available for question-and-answer periods during the time the project is being coded.
• Have the engineers discuss what they can build or are coding with a subject matter expert occasionally – it may turn out that something more useful to the expert is even easier to code, or it may turn out that having an expert reviewing functionality saves you a very expensive mistake.