Unit conversion looks like the most boring code in any system, right up until it destroys something expensive. Two of the most-studied engineering failures on record were unit errors, and the same class of bug is sitting in ordinary business software right now. Here is what goes wrong and the handful of rules that prevent it.
In 1999 NASA lost the Mars Climate Orbiter because ground software produced thruster impulse figures in pound-force seconds while the spacecraft's navigation software expected newton-seconds. The trajectory was off by enough to put the probe into the atmosphere. In 1983 Air Canada Flight 143 ran out of fuel at 41,000 feet because the refuelling calculation used pounds where kilograms were required, loading roughly half the fuel intended. Nobody in either case wrote a wrong formula; both systems exchanged bare numbers with no units attached.
Every one of these bugs has the same shape: a value crosses a boundary — function call, API response, database column, CSV import — carrying no information about what it measures. The fix is not "be careful". It is to make the unit part of the value or part of the schema, so that a mismatch is a type error rather than a silent miscalculation.
distance_m, mass_kg, duration_ms. Never distance.0.1 + 0.2 is 0.30000000000000004 in every IEEE-754 language.Temperature conversions are affine, not linear. Converting 20 °C to Fahrenheit is 68 °F, but converting a 20-degree difference is 36 °F, because the offset must not be applied to a delta. The same applies anywhere you have a non-zero origin: gauge versus absolute pressure, calendar dates versus durations, altitude above ground versus above sea level. If your conversion function does not distinguish absolute values from differences, it will be wrong half the time.
Python's pint attaches units to quantities and raises on incompatible arithmetic — adding metres to seconds fails immediately instead of producing a number. F# has units of measure in the type system. Java has JSR-385. In JavaScript, js-quantities or convert-units cover the common cases. The value is not the conversion factors, which you could look up; it is that the library refuses to do something dimensionally meaningless.
Round-trip property tests catch factor errors: convert to another unit and back, assert you land within tolerance. Add a boundary test for zero and negatives, which is where affine conversions break. And put one explicit test on every external interface asserting the unit of what it returns — that is the boundary where both famous failures actually occurred.