Importance of Using Correct Units

I first encountered the concept of unit conversion in the second grade. Where I was taught to convert pints to gallons, feet to inches, and ounces to pounds. Event with constant practice, there were a few units that I was just never able to get, such as the peck, fathom, or the hogshead. It amazes me to this day, that these units (all of the above) are still in use, when there is a clean, simple unit of measurement that has been accepted by the majority of the world: SI (metric).

Having a mixture of different methods to report the same concept (different units) introduces many engineering challenges. Primarily, one needs to be constantly vigilant when reporting data or receiving data, that the data has been properly labeled with the correct units. All data sheets should have standard locations to list units and software APIs should explicitly and cleanly state units on parameters and returned values.

The most famous example if software routines using the wrong units was the Mars Climate Orbiter probe that crashed due to a software conversion. In a nut shell, a routine was called to determine the amount of force exerted by the space craft thrusters after firing. The exerted force was factored into the navigation routines to determine the craft's new trajectory as it guided itself towards mars. The trajectory routines expected data in newtons (metric force unit) but was given thrust data in pound-force (imperial force unit). This resulted in a small amount of error each time a course correction was performed. Over the multi-million mile journey to Mars, the craft drifted roughly 45 km. A very small distance, but large enough to spell doom for the craft.

Earlier today, while sitting at my desk I overheard a conversation between two of our system's engineering engineers, taking about a small collection of requirements they had received from one of our customers. The two requirements dealt with the types of storage environments our final products would have to survive (temp, humidity, dust, ect). One in particular caught my ear. The requirement was worded similar to as follows:

The device shall not be damaged by dust particles, 100-500 micrometers in diameter, traveling at 50 mph.

Hearing this stopped me cold; one requirement mixed two different systems of measurements. I pointed this out to the guys and they laughed. Then they showed me an even more distressing requirement.

The device shall do something at either X g/ft or Y g/m^3.

In this instance, not only were systems of measurement mixed, the two provided units could not be converted into one another. One was mass per distance, and the other was mass per volume. I got assurances from the requirement guys that they would have the customer clarify what they meant. I then took a drink of coffee, put my headphones back on, and got back to work. My first order of business, verifying I'd documented all the units for my public facing routines in my code.