We often find ourselves navigating complex decisions where multiple valid approaches exist. The phrase “it depends” has become somewhat of a running joke in our field, yet it reflects a fundamental truth: most engineering decisions involve tradeoffs. However, while balancing competing concerns is often necessary, we must be careful not to fall into the trap of always seeking middle ground. Sometimes, one approach is clearly superior, and compromising can lead to worse outcomes than choosing either extreme. Today, I want to explore how to identify real tradeoffs, recognize false dichotomies, and understand when compromise might actually be harmful.

A tradeoff occurs when improving one quality or characteristic diminishes another. It represents a fundamental limitation where you cannot optimize for everything simultaneously. For example, you can’t have both maximum performance and minimum resource usage - these goals are inherently in tension. A false dichotomy, on the other hand, presents two options as mutually exclusive when they aren’t. When someone says “we either need to ship fast or write tests,” they’re presenting a false dichotomy. You can often do both, even if it requires more effort or creativity.

A tradeoff many of us face is trying to choose where to live, especially for us techies who are somewhat privileged in that this is a choice we get to make. Do you want to live downtown, paying high rent for minimal space but a short commute and easy access to amenities? Or do you want to live in the rural boonies, paying low rent for lots of space but long commute with limited access to services. Or, perhaps somewhere in the suburban middle with medium rent for a medium sized space with a medium commute? The decision is yours, and the best part is that different people make different decisions. People making different decisions even with the same information is natural. This is a spectrum and you get to choose where in the spectrum you fall, and you probably will need to compromise with your significant other.

In system design, tradeoffs are everywhere. The CAP theorem is a classic example: in a distributed system, you must choose between Consistency and Availability when network Partitions occur. If you choose consistency, some users might not be able to access the system during partitions. If you choose availability, users might see inconsistent data. This is a hard tradeoff [Some people are challenging this - but lets treat it as true for this example]. You physically cannot have both, so pick one - it is a true dichotomy.

While identifying tradeoffs is valuable, we must be vigilant about recognizing situations where compromise is and is not appropriate. Watch out for scenarios where the middle ground inherits the weaknesses of both approaches - a half implemented security or authorization - gives a false sense of security. If an approach is objectively superior in terms of every meaningful metric, don’t compromise for the sake of harmony. But, sometimes there is a true dichotomy like in the CAP theorem, and you need to recognize these and critically evaluate your principals and requirements. The goal isn’t to find a compromise for every decision, or to achieve harmony with everyone by incorporating everyone’s opinions - its to gather information and make the right decision given your constraints. Even if that means choosing an extreme.