A mishap on Mars

Photo credit: Simon Lee on Unsplash

On September 23rd, 1999, the Mars Climate Orbiter fired its thrusters for a manoeuvre that would bring it into a stable orbit 226 kilometres above the Martian surface. From this orbit, it would gather valuable information about weather systems on Mars, as well as acting as the communication relay for subsequent missions. 226 kilometres was a safe height, well above the 80 kilometeres at which the atmosphere would be thick enough to cause problems.

But the manoeuvre went wrong, The Orbiter dropped to an altitude of 57 kilometres, and either burnt up in the atmosphere, or skipped off and flew away from Mars altogether. Whatever happened, it was never heard from again.

The investigation found that the problem was due to a mismatch in the units used by the different systems used to calculate and control the craft’s manouevres. One system was working in pound-force seconds (an Imperial measure), while the other was working in newton-seconds (a metric measure). The ratio between these units is 4.45:1 - no wonder the craft crashed.

This is a famous story, often told with a smile: look, even those rocket scientists can’t keep their numbers straight!

But for those of us who work in enterprise technology, that smile must always be at least a little strained. We know that the work of building software systems is prone to similar mis-communication, and that we would be glad if it was limited to confusion over different types of units. In software projects, we may also be confused about dates, costs, protocols, and even the fundamental concepts of the systems that we are trying to build.

We have developed many techniques to reduce the risk of mis-communication in enterprise technology. In traditional, waterfall projects, we have elaborate and comprehensive requirements gathering mechanisms which are intended to eliminate ambiguity. In Agile projects, we create short feedback loops which enable us to check and adjust our mutual understanding. And in Test Driven Development projects, we build tests which express the desired behaviour of our systems before we build the software. Each of these approaches have their adherents, and we could argue all day about which is most effective in what context.

However, these techniques are designed to ensure that technologists understand the non-technical aspects of what they are trying to build. They do little to help non-technologists understand the technical aspects of what is being built. And I believe that this is a major source of mis-communication. Even after decades of building systems, technologists usually don’t take the time to explain to non-technologists how things work. Indeed, they are often encouraged not to do this. Technology leaders frequently tell their teams not to bother their stakeholders with technical details, on the expectation that they will be baffled or bored.

I think that this is a mistake: it perpetuates the myth that there are ‘business’ and ‘IT’ people, that they come from different worlds, that they speak different languages, and that they can only communicate through formal structures such as those described above. It also perpetuates the myth that technology is somehow an adjunct or adornment to the true matter of business, and that it can be left to specialists who are paid to worry about it. As I wrote last week, it is increasingly the case that the technology is the business, and to assume that leaders, executives and decision makers are not interested in it is to do everybody a dis-service.

Of course, we should not merely jump to the other extreme and flood every conversation with technical details that nobody could be expected to understand. That’s just another way of mis-communicating, of creating the bafflement and boredom that leads to mistakes. Instead, we should assume in each conversation that our interlocutors are intelligent enough to understand anything which is explained well, but ignorant enough that the explanation is required. This makes communication hard work, but it is work worth doing.

I suspect that the teams working on the Mars Climate Orbiter shared deep specialisms and common languages, and were not scared to share details with each other. And yet they managed to mis-communicate at a fundamental level. Imagine how much more mis-communication arises when we choose not to speak at all.