Why is the pronghorn so much faster than any of its predators? (Stick with me here.)
This is an antelope-like animal native to western and central North America. Their name comes from the two long, black horns that each have a forward-pointing tine.
And they’re the fastest land mammal in the Americas, reaching speeds up to 55 miles per hour. Their predators don’t even come close: bears and wolves top out at around 35 mph. Why would a prey animal have evolved to be so much faster than what chases it?
You might think there’s something missing here, and you’d be right.
During the Ice Age, there was a species in North America that we colloquially call the American cheetah. It looked a heck of a lot like today’s cheetahs, and probably acted somewhat like them too. Even if it couldn’t reach the modern cheetah’s 60 mph top speed, it likely got close.
So while today’s pronghorn was evolving over the last couple million years, it was contending with a predator that could match its speed, pushing it faster and faster.
But when the American cheetah went extinct 16,000 years ago, that evolutionary context vanished. We were left with this antelope-looking thing that was absurdly fast for no reason.
Something similar happens in engineering programs, from aircraft design to software development.
There’s always some initial factor that pushes certain design choices. Maybe you use a specific type of connector because of the weird part you had to source. Or you pick a given propeller design because it’s just good enough to fly at your quickly-approaching demo.
The team progresses with the design. Maybe that initial limitation disappears because there are more commercial part options. Or the timeline of the project relaxes, allowing for more analysis and test before any demos.
And later down the line—whether it’s a few months, or even years later—someone is trying to deal with that design choice, and they’re wondering why the original engineers did something so pointless. What were they even thinking?!
It seems “pointless” because that initial engineering context is gone. The original design pressure was removed, leaving behind an echo of its existence. Just like how the pronghorn seems out of place, because its context is gone, too.
This is all a nerdy way of saying: document everything to the best of your ability, including your design choices, as silly as that might seem.
Choose a propeller because it’s the one COTS option that will work right now? Write that down.
Avionics bay has a goofy shape because there’s another component mounted underneath it? Make sure that’s recorded somewhere.
A chunk of code has values hard-coded because it was originally meant to be a one-off snippet? Leave comments to explain it.
I’m definitely not perfect at this. But I want to get better. Too many times the team will make a choice for a specific reason, and then seven months later I second-guess myself when we’re debating why that choice made sense at the time.
Engineers are pretty decent at documenting the math and physics behind our designs. But we really ought to remember to document all the other factors behind a choice, too.