الدرس 1 من 4
Trade-off Analysis: There Is No Best, Only Fit
A repeatable method for comparing options that does not collapse into whoever argues most confidently.
Most technical arguments are unwinnable because the participants are optimising for different things without saying so. One person is protecting delivery speed, another is protecting operability, a third is protecting a technology they enjoy. Trade-off analysis is the discipline of making those priorities explicit first, so that the comparison has something to be a comparison against.
The method
Five steps, in this order
- 1
State the decision as a question with a boundary
"How do we store and query booking availability for the next three years?" — not "should we use Redis?". Naming a technology in the question has already made the decision.
- 2
List the forces, and rank them
Quality attributes with numbers, plus the constraints: team size and skills, deadline, budget, compliance, existing systems you cannot change. Ranking matters more than scoring; if everything is important, nothing is decidable.
- 3
Generate at least three options, including "do nothing"
Two options tend to become a false binary. "Keep what we have" is a real option and is frequently the right one — it must be on the list or it cannot win.
- 4
Score each option against each force, and say what it costs
An option with no cost has not been analysed. The output of this step is not a winner; it is an honest picture of what each choice sacrifices.
- 5
Choose, then write down what would change your mind
Name the observation that would make this the wrong call. It converts a future argument into a future measurement, and it is what makes a decision revisitable rather than permanent.
| Force (ranked) | Option A: shared DB | Option B: DB per tenant |
|---|---|---|
| 1. EU data residency by Q3 | Requires a routing layer we do not have | Native — a tenant lives in a region |
| 2. Team of six, no dedicated DBA | One database to operate | Migration and backup across N databases |
| 3. Onboard a tenant in under an hour | Insert a row | Provision, migrate, verify — needs automation |
| 4. Cross-tenant analytics | A single query | Requires an aggregation pipeline |
| What it costs | A residency solution has to be built anyway, later and under time pressure | Operational complexity from day one, permanently |
Someone proposes a technology you dislike
As a developer
Argue against it from experience — the last time you used it, it was painful. The argument is real and it is also unfalsifiable, so the discussion becomes a contest of anecdotes.
As an architect
Ask which of the ranked forces it serves better than the alternatives, and what it costs on the others. If it wins on the top-ranked force and the cost is acceptable, your preference is not relevant. If it loses, you now have a reason that does not depend on anyone trusting your past experience — and the person who proposed it can see the same reason.
Two engineers have been arguing for forty minutes about REST versus gRPC for an internal service. How do you unblock it?RevealHide
Stop the comparison and ask what the ranked forces are. Almost always one of these is decisive and settles it in two minutes: are the consumers browsers (REST, effectively decided), is the p99 latency budget tight enough that serialisation matters, do the teams already operate gRPC infrastructure, and how important is being able to debug a call with curl at 3am? The argument runs long precisely because nobody has said what they are optimising for — and when they do, the options usually stop being close.
Key takeaways
- Agree the criteria and their ranking before looking at any option.
- State the decision as a question without a technology in it.
- Always include "keep what we have" as a real option.
- An option with no stated cost has not been analysed.
- Weighted scoring matrices launder judgement into false objectivity — use the table to expose costs, then decide openly.