Why Unit Conversion Bugs Are So Expensive

Most software bugs cost time. A small category of unit-conversion bugs has cost spacecraft, aircraft, and in at least one case nearly a hospital patient's life, and the pattern behind them is almost always the same: two systems, two unit conventions, and no check at the boundary where they meet.

The Mars Climate Orbiter

In 1999, NASA's Mars Climate Orbiter burned up in the Martian atmosphere instead of settling into orbit around it, after a $327.6 million mission. The investigation traced the failure to one piece of navigation software, built by a contractor, that calculated thruster force in pound-seconds — an imperial unit — while every other piece of the mission's ground software assumed the metric unit, newton-seconds. One pound-second equals roughly 4.45 newton-seconds, so the trajectory data being fed into NASA's navigation model was off by a factor of about 4.45 for months of cruise trajectory corrections, gradually steering the spacecraft toward a final approach roughly 100 km lower than planned — low enough that atmospheric friction destroyed it. No single person mistyped a number; two teams each built correct software using a different, valid unit system, and nothing forced the interface between them to agree on which one was in use.

The Gimli Glider

A different failure mode, same root cause: in 1983, an Air Canada 767 flying from Montreal to Edmonton ran completely out of fuel at 41,000 feet and had to glide, engineless, to a landing on a decommissioned runway in Gimli, Manitoba — a feat that only worked because one of the pilots happened to have glider training. The fuel had been calculated in pounds by ground crew, using a manual conversion, because the aircraft's fuel gauge was inoperative and Canada had just switched its aviation fuel measurements from imperial units to metric. The conversion used the wrong density figure — a pounds-to-kilograms factor applied where a volume-to-mass factor for jet fuel was needed — and the aircraft took off with less than half the fuel its flight plan required, all because a single conversion step, done by hand under unfamiliar new units, was wrong by roughly a factor of 2.2.

Why these bugs are so hard to catch

A wrong number usually looks wrong — a negative age, a five-digit temperature. A unit conversion error doesn't; it produces a number that's perfectly plausible in isolation. 4.45x too much thruster force is still a normal-looking force value. A fuel figure computed with the wrong density is still a normal-looking weight. The error only becomes visible once it interacts with the real world — atmospheric entry, an empty tank — by which point there's no graceful recovery. This is also why unit bugs disproportionately show up at organizational boundaries: the Orbiter bug crossed a contractor/NASA boundary, the Gimli Glider bug crossed an imperial/metric transition boundary. Within one team, using one convention consistently, the risk is much lower; it's the handoff between systems built on different assumptions where conversions get skipped, guessed at, or applied with the wrong factor.

Precision and rounding: the quieter version of the same problem

Not every conversion failure is as dramatic as a spacecraft loss — plenty are smaller, silent rounding errors that compound. Converting a temperature between Celsius and Fahrenheit involves both a multiplication and an offset (°F = °C × 9/5 + 32), not just a scale factor, so rounding at the wrong step introduces an error that a pure multiplicative conversion — miles to kilometers, say — wouldn't have. Currency-style unit chains are worse: converting fluid ounces to milliliters to liters to gallons in sequence, rounding at each intermediate step, accumulates error that a single direct conversion (ounces straight to gallons) avoids entirely. Recipe scaling, engineering tolerances, and medical dosing are three domains where this kind of compounding rounding error, not a single dramatic wrong-factor mistake, is the more common failure — a few tenths of a percent lost at each of four conversion steps adds up to a result that's measurably off despite every individual step looking reasonable.

What actually prevents this class of bug

The fix that emerged from the Mars Climate Orbiter investigation wasn't "be more careful" — it was a policy change requiring all interface specifications between contractors and NASA to explicitly state units for every value crossing the boundary, with validation checks on the data itself. That's the generalizable lesson: unit bugs aren't solved by better mental math, they're solved by making the unit explicit at every point data changes hands, and by using a single conversion step with a precise, standard factor rather than a chain of hand-rounded intermediate ones. That's the entire design goal behind a dedicatedunit converter — one direct, unambiguous conversion per calculation, with the unit always labeled, instead of a mental shortcut that quietly assumes which system is in play.