On September 23, 1999, NASA's Mars Climate Orbiter reached Mars after a nine-month journey. It entered the atmosphere at the wrong angle and was destroyed.
The spacecraft worked. The navigation worked. The teams were among the best engineers on the planet. What failed was something so mundane it's almost embarrassing to say out loud:
One team produced thruster data in pound-force seconds. The navigation software expected newton-seconds.
That's it. That's the whole failure. Two systems, two teams, one assumption about units — never written down, never verified, never tested across the boundary. The contract between the two systems existed only in the shared understanding of engineers who had not explicitly communicated it.
Total cost: $327.6 million, and a decade of scientific opportunity.
You have this exact bug in production right now
I don't know your system, but I'd bet on this: somewhere in it, two services are communicating through an agreement that exists only in someone's head.
A consumer that assumes a timestamp is UTC, while the producer sends local time. A field that one team treats as nullable and another treats as guaranteed. An amount in cents on one side, in euros on the other. An event schema that "everyone knows" — meaning the two people who wrote it three years ago, one of whom has left.
These are all the same failure as the Orbiter: an undocumented assumption at a module boundary, undetected until the worst possible moment.
In software the cost is measured in outages and regressions rather than orbital disasters, but the root cause is identical — and so is its invisibility. Implicit contracts are accurate at the moment of creation and drift silently from that moment forward.
Why "good engineers" doesn't protect you
The standard takeaway from the Orbiter story is "test more" or "communicate better." Both miss the point. NASA tested extensively. NASA communicated constantly. The failure survived all of it, because testing and communication operate on what people know to check — and nobody checks an assumption they don't know they're making.
The Lockheed Martin team didn't decide to use imperial units against spec. They built to their own internal conventions, the way every team does. The navigation team didn't skip verification. They verified against their own understanding of the interface, the way every team does. Each side was locally correct. The system was globally wrong.
This is why implicit contracts are the most dangerous artifact in a distributed system: they fail at the boundary, where neither side is looking, and the failure manifests far from its cause — in the consumer, in production, months later.
The fix costs an hour. The alternative costs the mission.
The defense is not heroics. It's a discipline: no integration between two modules without a prior, written, versioned contract. What the interface receives. What it returns. What units, what formats, what error behaviors, what guarantees. Agreed before implementation starts, not reverse-engineered after the incident.
For a typical service interface, that's a one-page schema. An hour of work, maybe two with review. Against that hour, weigh what the implicit alternative costs when it fails: days of cross-team debugging per incident, multiplied by every integration point in your system, multiplied by the years the assumption sits there waiting.
NASA's post-mortem reached the same conclusion. The recommendations were not "hire better engineers." They were process and verification at the interfaces — making the implicit explicit, structurally, so that correctness no longer depended on two teams happening to share an assumption.
A contract defined up front takes hours. A contract discovered through failure takes weeks — or, at sufficient altitude, a spacecraft.
Top comments (0)