A couple weeks ago in a meeting, I finally got the chance to say out loud one of my guiding engineering principles:
“It’s an airplane.”
“…well duh, Carly,” you’re thinking. Let me explain.
Between all the complex systems and myriad disciplines involved, as engineers it can be easy to forget that what we’re making isn’t just the sum of its parts. It’s not just lines of code, a few bundles of electrical cables, and some aluminum and carbon fiber.
Once we put it together, it becomes a single entity. It’s subject to the same laws of physics and gusts of air as you and I. It has weight and inertia and purpose.
I’ve encountered a few cases in my career where this principle applied:
Once, while discussing with a colleague why a certain airfoil had been chosen, he stated it had a better maximum lift over drag than one I had recommended. He was insinuating that this airfoil was more efficient because of it. I pointed out that with the airplane’s weight and cruise speed, it wasn’t even flying where it could achieve that max L/D. Remember, it’s an airplane.
Years later, during an investigation of some odd takeoff behavior on an aircraft we found that one VTOL (vertical takeoff and landing) motor had been pegged at 100% throttle for multiple consecutive seconds. I called this out as concerning—a VTOL motor should be at 100% throttle for fractions of a second in normal operation, if that. We design with margin on purpose.
A controls engineer I worked with pushed back, saying that the pitch-roll-yaw commands for the aircraft all added up and made this 100% throttle state reasonable. He later came to me and admitted that after thinking about what I’d said, there really was no reason for those commands to add up to that high of a response, and there had to be something abnormal going on. Remember, it’s an airplane.
Sometimes when colleagues are briefing me on proposed changes to an aircraft design, they jokingly brace themselves. They expect me to panic about the additional drag that a specific payload integration will contribute. They’re always a little surprised when I’m unconcerned, until I remind them that if the mission-specific payload isn’t on board there’s no reason to fly anyways. Remember, it’s an airplane.
With just a few exceptions, pretty much anything you or I make is meant to solve a problem or carry out a mission. It is so important to keep that fact in mind. Use it to filter though everything you could care about, to focus on what really matters.
Does an efficiency matter if it’s outside your operating region?
Does a certain quirk of your code make sense, or is it pointing to something broken below the surface?
Can you make compromises so your solution is easier to use or understand?
And if you’re like me, and you make a living by taunting gravity on a regular basis—
Remember, it’s an airplane.