5 exercises on comparing options objectively, using "we chose X over Y because", balanced pros/cons in prose, and closing with a traceable decision summary.
Key patterns
Credit every alternative honestly before explaining rejection: "It offers [pros]; however, [con]".
"We chose X over Y because" requires a specific, quantified, context-tied rationale.
Use parallel structure for pros/cons: each option gets the same grammatical schema.
Name the rejection blocker: coordination cost, operational complexity, team expertise, cost.
Close with a falsifiable summary: criteria → chosen approach → decisive trade-off → fallback.
0 / 5 completed
1 / 5
You are writing the Trade-offs & Alternatives section. Which sentence best introduces a rejected alternative objectively?
An objective trade-off evaluation names the alternative, its genuine strengths, its disqualifying weakness, and links the weakness to your specific context.
Option C does all four: it acknowledges what MongoDB does well (flexible schema, sharding), names the concrete limitation (multi-document ACID transactions), and ties it back to the workload (financial records). Reviewers trust evaluations that credit the alternatives honestly.
Standard structure: "We evaluated X. It offers [pros]; however, [con] because [context]."
Useful connectors: "however", "that said", "on the other hand", "this comes at the cost of".
Avoid editorialising: "bad idea", "obviously wrong", "less popular" signal bias, not analysis.
Options A, B, and D all dismiss the alternative without engaging with its merits, which weakens the credibility of your recommendation.
2 / 5
Which sentence uses the native English phrase pattern "we chose X over Y because" most effectively in a design doc?
The "chose X over Y because" pattern must complete the sentence with a specific, comparative rationale.
Option B delivers: it states the requirement (high-frequency, latency-sensitive calls), the mechanism (binary framing, HTTP/2 multiplexing), a quantified benefit (40% overhead reduction from benchmarks), and the disqualifier for REST (JSON serialisation, unacceptable p99 tail latency).
The "because" clause must answer: why X specifically, and why not Y specifically.
Quantify when possible: "40% reduction", "p99 latency under 10ms", "3x throughput".
Name the requirement the choice satisfies: "latency-sensitive", "strongly consistent", "horizontally scalable".
Option A provides no reasoning. Option C is accurate but superficial — "faster" needs quantification and context. Option D expresses preference ("we think") rather than evidence.
3 / 5
In a pros/cons table description in prose, which version presents the comparison most balanced and professionally?
A balanced pros/cons description gives each option a genuine positive and a genuine negative, using parallel structure.
Option C follows the ideal form: Option A — pro (faster initial load, SEO) + con (CPU, cache complexity); Option B — pro (simpler server, interactivity) + con (TTFB, SEO for JS-agnostic crawlers). The structure is parallel and neither option is dismissed.
Use parallel grammatical structure: both options should get the same sentence schema.
Contrast pairs: speed vs. complexity, simplicity vs. capability, cost vs. performance.
Avoid weasel terms: "way better", "too many problems", "equally valid" without evidence.
Option A is biased. Option B is non-committal — a balanced comparison should still lead to a recommendation. Option D defers to a table without providing any prose analysis.
4 / 5
A reviewer says your alternatives section "does not explain why you did not choose the alternatives". Which addition best addresses this?
Explaining rejection requires naming the specific blocker, its organisational or technical context, and (ideally) a future revisit condition.
Option C does this precisely: the blocker (simultaneous migration of six teams), the risk type (coordination), the context (Q3 delivery commitments), and the revisit trigger (H1 next year / bandwidth resolved). Reviewers accept rejections that come with a "not yet" rather than a "never".
Name the blocker category: coordination cost, operational complexity, maturity of the technology, team expertise, licensing cost.
Useful phrases: "we assessed this as high-risk because", "the cost of X outweighs the benefit of Y at this stage", "we will revisit when".
Options A, B, and D provide conclusions without reasoning. Option D ("team voted") is the worst: it replaces engineering judgement with social consensus.
5 / 5
Which closing sentence for a Trade-offs & Alternatives section most effectively summarises the decision?
A decision summary should restate the key criteria, name the chosen approach, state the decisive trade-off, and acknowledge the fallback.
Option C references the three criteria (latency, Kafka expertise, migration scope), names the approach (Approach A, event-driven pipeline), states the trade-off balance (delivery speed vs. maintainability), and names a fallback (Approach B if ordering guarantees fail). That closes the section with full traceability.
Key collocations for summaries: "given X, Y, and Z, we recommend", "balances A with B", "remains a viable fallback if", "at this stage".
A good summary is falsifiable: a reader should be able to check whether the criteria actually point to the conclusion.
Avoid: "think", "seems", "will proceed" (the last one belongs in the implementation plan, not the trade-offs section).
Options A and B express confidence without evidence. Option D is an action statement, not a decision summary.