Engineering Is the Art of Trade Offs

I did my systems engineering undergraduate back in 2002 when our software design professors were convinced that, in a few years, we wouldn’t be writing code anymore—that UML would somehow generate all the code we’d ever need.

While they were wrong about that, they were right about a lot of things I didn’t fully appreciate until later in my career.

Engineering is trade-offs management. — Prof. Trevor Pearce

Early in my career, I had a clear vision of what “good code” and “good architecture” looked like. When I got into real projects and products, I was regularly floored by the bad design choices people made. At 25, working my first job for the federal government, they put me in charge of managing five greybeard contractors. I remember proudly presenting my UML diagrams and explaining how a full rewrite of our massive legacy system would save us. From their seats, they leaned back, smirking subtly, as if to say, “You sweet summer child.”

Over the years, I went through the fire, like all other engineers:

  • Facing tight deadlines
  • Contributing to tech debt for the sake of shipping a product
  • Managing engineers from every kind of background giving vastly different perspectives on how to build things.

I began to realize that every moment as engineers, we are constantly calculating trade-offs in our technical decisions, and the “right decision” is rarely black and white. Some contrived examples

  • Should I make this implementation clever with less code? Or should I add another 10 lines of code to make it very clear that’s happening in the code.
  • For generating these unique IDs, should I generate a UUID? or should I make it easier to understand the context in the logs by writing something descriptive with a random number at the end?
  • Should I add a bunch of logging that will cost us more and probably not use? Or add them, so I can find an issue proactively to do a post-mortem?

And these are just very small examples that won’t take long to change if you end up changing your mind.

What about bigger decisions?

  • Should I break out this problematic module from the monolith? Scaling up the monolith is faster now, but breaking it out could scale better long-term—though it’ll require setting up infrastructure and advocacy.
  • Should I introduce a message bus for three different monoliths sharing data, or add yet another REST call?
  • Should I push for OpenTelemetry for flexibility in observability tools, or stick with Datadog and fully leverage its platform?
  • These are bigger decisions that could take weeks—or months—to implement or undo if you get them wrong.

And you know what? There’s rarely a right answer. Just choices with trade-offs based on today’s context. It’s even more complicated because I’m evaluating the trade-offs from my perspective. Others, with different experiences, might bring valuable insights that shift the equation. Including their perspectives can make decisions more complex but also more robust. To make it even more complicated, including more folks takes more time, but if we DON’T have those people’s insights, we will miss their perspective and potentially make a worse decision. Deciding who to involve in itself is an exercise in trade-off management.

Engineering at its heart is tradeoffs management

Realizing that everything has tradeoffs helped me see that engineering has a creative, almost artistic side. It’s less about solving a math problem with a single correct answer and more about navigating nuance.

What I didn’t realize those contractors were teaching me 20 years ago is that we need to deeply consider the current landscape—both organizationally and culturally—when making decisions.

If engineering is the art of trade-offs management, how do we navigate decisions when multiple options are on the table?

  • Embrace imperfection: Accept that there’s rarely a perfect answer. This mindset makes it easier to stay open to alternative approaches others might suggest.
  • Recognize one-way vs. two-way doors: Jeff Bezos’ 1997 shareholder letter outlines this well. A “one-way door” is a decision that, once executed, can’t easily be undone—these require careful deliberation. A “two-way door” is reversible with minimal effort. If it’s two lines of code that you can change later, ship it. If it’s months of work that would be hard to unwind, take the time to explore options and prototype.
  • Get the right people in the room: Include those with relevant experience, even if they might challenge your thinking. Avoid including too many people, though, as it can slow down decision-making.
  • Prioritize cultural acceptability: If the technically superior approach introduces something unfamiliar to your organization, treat that as a significant con. Educating leadership and peers on something entirely new is an uphill battle and can delay execution. For example, in one organization where we had three monoliths passing data synchronously at midnight, I advocated for a Kafka event bus solution. It was technically superior but freaked out the other engineering leaders. Ultimately, it wasn’t the path we chose. Pick your battles wisely.

Ultimately, navigating trade-offs has taught me that great engineering isn’t about finding perfect solutions—it’s about building the best systems we can with the time, tools, and insights available.

I write this article to engage with others with a similar mindset. Don’t hestitate to reach out!