Alternatives Analysis
Always consider at least 2 alternatives — the first idea is rarely the best, and 'no alternatives' is a red flag.
Why
The first architecture that comes to mind is usually the familiar one, not the best one. Considering alternatives forces you to enumerate what else is possible and why you're not choosing it — which either confirms the first idea (now with reasoning) or reveals a better option. 'No alternatives considered' is the most common ADR defect and the strongest signal that the decision was rationalized, not made. Even when the first idea is best, the alternatives section documents what was rejected and why, which prevents re-litigation ('why didn't we use X?' — it's in the ADR). The discipline is to generate alternatives before choosing, not to justify the choice after.
When
For every moderate+ decision. Takes 1-2 hours. Skip only for cheap decisions (see reversibility).
How
1. State the problem, not the solution — alternatives come from reframing the problem 2. Generate at least 3 alternatives (force yourself; the 3rd is often the insight): - The obvious one (what you'd do by default) - The opposite (what a contrarian would suggest) - A third way (a different framing entirely) 3. For each alternative, note: - What it does well - What it does poorly - What's required to adopt it (cost, migration, learning) 4. Compare on the decision criteria (see decision-criteria) 5. Choose; document the alternatives + the reasoning in the ADR 6. If you can't generate 3, you don't understand the problem — research more
Example
Problem: "rate-limit the API" Alternatives: 1. Token bucket in app (Redis + lua) — obvious, accurate, adds Redis dep 2. Cloud provider rate limit (API Gateway) — opposite, no code, less flexible 3. Edge rate limit (Cloudflare) — third way, before traffic hits origin, cheap Comparison: 1: accurate, but Redis dep + app latency 2: no code, but per-region limits + vendor-specific 3: cheapest, global limits, but coarse (per-IP not per-user) Decision: 3 for per-IP, 1 for per-user (authenticated). Both, layered. Alternatives + reasoning in ADR-017.
Common Problems
- ⚠Generating alternatives that are strawmen — 'alternative 2: do nothing' is not a real alternative; each should be a viable choice.
Best Practices
- ✓Force the 3rd alternative even when you think you know the answer — it's the one that reveals hidden assumptions in the first two.
- ✓Document the rejected alternatives with enough detail that a future engineer doesn't re-propose them — 'we considered X, rejected because Y' closes the question.