Everything Is a Trade-off
There are no best practices, only trade-offs in context. If you can't name the downside, you don't understand the choice.
To an executive
Every choice gives something up. A proposal that lists no downsides is incomplete, so ask what the business is giving up and whether that is the right price.
To an engineer
Write down what each design choice costs you, such as consistency, latency, flexibility or money. Record the conditions under which the rejected option would win.
The idea
Economics teaches that every choice has an opportunity cost: choosing one thing means giving up another. Architecture is the same. Each quality attribute you optimise, such as consistency, latency, flexibility or cost, is paid for with another.
Mark Richards and Neal Ford call this the First Law of Software Architecture: everything in software architecture is a trade-off. Their corollary is that if you think you have found something that is not a trade-off, you probably have not yet found the trade-off. The architect's value lies in making those trade-offs explicit and deliberate, not in knowing the "right" answer.
Why it works
It moves the argument from preference to priorities. Two people arguing about technologies are usually weighting different qualities. Once the qualities are ranked, the choice often follows.
It exposes hidden costs. Naming the downside of the favoured option, before choosing, surfaces costs that enthusiasm would otherwise hide.
It makes decisions revisitable. A decision recorded with its trade-offs can be reopened when the context changes, without re-running the whole debate.
Where it applies
- Design reviews, where options are compared against stated quality attributes.
- Vendor and product selection, where every package trades features, lock-in, cost and fit.
- Enterprise standards, where a single standard trades local fit for consistency and lower operating cost across the estate.
- Stakeholder conversations, where "best practice" claims need to be turned into explicit choices with owners.
How to apply
- Agree the quality attributes that matter, and rank them for this context.
- List the realistic options, including doing nothing.
- Name the cost of each option against those attributes, especially the favourite.
- Decide, and record the rejected options and why, in an architecture decision record.
- Note what would change the decision, so it can be revisited on evidence rather than opinion.
Example scenario
Two teams argued for months over event-driven versus request–response integration for a new order platform. Each had good arguments, and each meeting ended where it began.
The architect asked the business to rank the qualities: auditability first, latency second, simplicity third. Written down against those priorities, the trade-offs settled it in an hour: events for the audit-critical flows, synchronous calls elsewhere. The decision record captured both options, so the next team did not reopen it.
Questions to ask
- What are we giving up by choosing this option?
- Which quality attributes matter most here, and in what order?
- Under what conditions would the option we rejected be the better one?
When not to use it
- Choices with an obvious, cheap and reversible answer, where a formal trade-off analysis costs more than a wrong guess.
- Hard constraints, such as legal or safety requirements, which are not up for trade.
How it misleads you
Using "it depends" to avoid committing. Trade-off analysis can become an endless list of pros and cons that nobody acts on. The point is to evaluate the trade-offs, choose, and own the consequences.
In the wild
Further reading
Last reviewed · Suggest an improvement