Engineers are dogs, scientists are cats

You’ve heard of the book “Men are from Mars, Women are from Venus.” It’s a tongue-in-cheek title, but one that strikes a chord and perhaps helps us understand each other. Planetary scientist Ralph D. Lorenz went searching for an analog of his own to describe scientists and engineers. This is what he came up with.

I originally trained as an aerospace engineer, but if someone asks my profession today, I say planetary scientist. In reality, I work at the boundary of these two disciplines in a region of frequent communication challenges between engineers and scientists. Having reached the end of a long-term international project — the Cassini-Huygens mission to Saturn and Titan — on which I started as an engineer but progressively became a scientist, I have had cause to reflect on the difference between these disciplines and the outlooks of the people who make them their professions. Like any other pithy generalization (e.g., “Men are from Mars, Women are from Venus”), what follows is a caricature that is intended to help each side understand the other’s point of view. Whatever your preference in pets, no value judgment or offense is intended. The goal is to aid mutual understanding.

Engineers are dogs. They like well-posed problems that have a right answer (often, called the “optimum”), and they know it is the right answer. They just want to make their customers happy. Engineers also typically work in packs, hierarchical social structures that have a clear chain of command. They tend to work serial problems, going where the pack goes — when a project ends, on to the next thing.

Scientists are cats. They like finding new problems just as much as solving old ones, and are comfortable with uncertainty. They often like working alone, or at least don’t care whether others are working on the same thing, and certainly don’t like being told what to do. Cats are territorial, and scientists often stake out a problem or methodology as “their own” and may often pursue it even when there is little external support to do so.

The lines, of course, are blurred. An engineer may engage in a scientific process, such as correlating test data to build a predictive model. But the exercise is a success if an equation is found that works for the intended purpose, regardless of whether the form of the equation relates to some underlying insight into the physical processes at work. Contrariwise, many scientists build their own experimental apparatus or computer codes, but (like myself) tend to hack something together, without a formal architecture or systems-engineering validation to the process, just getting something that will work quickly.

A couple of examples illustrate the value of each perspective. As a Ph.D. student in a science department, I made a study of raindrops of liquid methane on Saturn’s moon Titan, assessing how large they could grow and how fast they’d fall. A fellow student asked how I was modeling the intermolecular forces in the drop — a microscopic perspective often adopted in physics. “That’s surface tension — that’s just a number I look up in a book,” I barked. All that this problem needed was the net effect of these interactions, a straightforward force balance problem from an engineering perspective.

Some years later, I was out at an airfield observing the motions of a scale model Huygens probe under its parachute, dropped from a radio-control airplane, to gain familiarity with the dynamics the actual probe would encounter during descent to Titan in 2005, I chatted with some students developing a much more sophisticated experiment. They were participating in an aerial robotics competition, and were using machine vision to perform navigation. A standardized marker (a black disk with a white cross) was used to designate their target, and they had written slick code to extract the marker diameter from images in real-time to deduce the distance to the target. Heady stuff! However, their code was failing at long and short ranges and they asked if I could help. I learned they had diligently — doggedly — placed the marker at a range of test distances, obtained the diameters, and they had fitted these data in a spreadsheet with a two-term polynomial. After blinking in incredulity for a second, I suggested, “Isn’t this just a similar-triangles problem? Have you tried fitting the distance against the reciprocal of the diameter?” They did so, and were most impressed with the accuracy of the results! In this instance, a little physical understanding of the underlying problem let us pounce on a solution much superior to that from the purely empirical approach sometimes favored by engineers.

Almost all scientist-engineer interactions I encounter in my business involve the engineer requesting a specification from the scientist, usually a single number, sometimes a minimum-maximum range or similar. Over the years I’ve participated in many such discussions — on both sides — as they relate to specification of the environment against which the engineer must design. The conversations often go like this:

E: I need to design the legs for our Mars lander. I need to know the horizontal velocity at landing, so tell me, what will the wind speed be?

S: I don’t know, that’s why we’re sending a lander with my 4-kilogram meteorology instrument! And it depends.

E: OK, fine, what will the maximum wind speed be at the Tharsis landing site in December 2020?

S: Well, I still don’t know, we’ve never been to this site before. And I can’t tell you with certainty what the winds will be here on Earth on that day either. I can tell you that the winds at the Viking
lander 2 site were less than 20 meters per second for 99 percent of the time in a three-year period in the 1970s. That’s the best data we have. And we have a numerical model that predicts the Tharsis winds to be less than 10 meters per second, but that model doesn’t include the latest dust information and […scientist elaborates with further caveats and interesting complications. …]

E: [Rolls eyes]. Whatever. I’ll say 99 percent winds are 20 meters per second, and I’ll add 20 percent as a margin. [Sucks teeth]. I have to make the legs pretty sturdy, they’ll be heavy. Can you do your meteorology package for 2 kilograms?

S: [expletive deleted]….

Ultimately, engineers and scientists in the space business are solving two nearly equivalent problems. For the engineer (and, cynically, for NASA as a whole), it is usually a constrained minimization — i.e., cleverly developing the lowest-cost design that will meet the requirements. Or put another way, the scientist customer is asked: “What is the minimum performance you will accept?” The scientist usually looks at the interaction another way, as a constrained maximization: “What is the best performance you can give me subject to the budget cap?” Of course, cost predictions are uncertain, and scientific value is notoriously difficult to estimate or even communicate meaningfully, but those are subjects for another article.

Sociologically, the inherent tension in the two perspectives is what — sometimes uncomfortably — has led to the generally successful missions we see. Hopefully this article, by offering a glimpse into the mindsets involved, may help smooth those interactions. Success usually emerges with the help of scientists who grasp at least some of the engineering realities, and engineers who comprehend the overall scientific intent beyond formally stated requirements.