English for Software Engineers: A C1 Design-Review Lesson
A design review asks engineers to do more than explain a preferred solution. They need to distinguish evidence from assumptions, question a proposal without attacking its author, and record what the team has actually decided. This English lesson gives advanced adult learners a small technical problem they can discuss without specialist knowledge of a particular programming language.
Use it primarily with C1 learners who work in software, product, or technical delivery. B2 support is included below. The task is to compare two notification designs and agree a conditional next step. There is no universally correct architecture hidden in the exercise. Assess the clarity of the reasoning and interaction, not whether students choose the design you personally prefer.
The scenario, measurements, and company are fictional. They are practice materials, not benchmarks or recommendations for a production system. If you replace them with a real workplace example, remove confidential details and agree what can be discussed before class.
Lesson aims, timing, and materials
Plan for 80 minutes with groups of three or four. Learners need the brief, two option cards, four role cards, and a blank decision log. On a video call, share one copy of the brief and send each role privately. In a one-to-one lesson, the teacher can act as a reviewer while the learner alternates between proposing and evaluating.
By the end, learners should be able to state a proposal with a reason, challenge an assumption using a specific question, summarize a competing view accurately, and define a test or condition before committing. Tell them that these are the observed outcomes. “Use impressive technical English” is not a useful assessment criterion.
Start with a vocabulary check limited to terms needed for the scenario: queue, retry, duplicate, peak load, and acknowledgement. Ask learners to explain each in ordinary English. Accept a clear paraphrase. This is not a vocabulary quiz about tools they do not use at work.
The fictional design brief
Product: Cedar Tasks. Small teams use the application to assign work. When a task is assigned, the recipient should receive an email notification. An email delay must not prevent the assignment itself from being saved. The team can run a limited pilot before wider release.
Supplied evidence: In a classroom load-test scenario, the assignment endpoint without email completes in 180 milliseconds at the stated test load. Calling the email service during the request adds between 400 and 1,200 milliseconds in those tests. The email provider can return a temporary failure. These observations describe only the supplied test conditions; students cannot infer behavior at every possible traffic level.
Constraints: The team has one week for the pilot. It can add one small background worker, but it has limited time to build new operational tooling. Users should not receive repeated emails for the same assignment. The expected frequency of provider failures is unknown. The team has not measured how long a queued notification would wait during peak demand.
Decision required: Choose a pilot approach, identify the main unresolved risk, and define what must be checked before wider release. Students may recommend a limited experiment instead of unconditional approval. They may also request more evidence, but must explain which decision that evidence would inform.
Option cards for the review
Option A: Send during the request. The application saves the assignment, then calls the email service before returning a response. If the provider fails, the assignment remains saved but the notification may be missing. The proposal does not yet define a retry process. It avoids operating a separate worker during the pilot, but adds the observed delay to the response path.
Option B: Send through a background worker. The application saves the assignment and records a notification to be processed separately. A worker attempts delivery and retries temporary failures. The proposal still needs a clear plan for avoiding duplicate notifications and for finding messages that remain undelivered. The team has not yet tested queue waiting time under the pilot's expected peak load.
Do not add facts that make one option magically safe. “A queue guarantees delivery” is not supported by this brief. “The simpler design has no risks” is also unsupported. Learners should discuss what each proposal currently specifies and what remains unresolved.
Before assigning roles, ask everyone to write one advantage, one risk, and one missing detail for each option. This gives quieter learners an independent position before the group discussion begins.
Role cards and information priorities
Proposer: Recommend Option B for the pilot. Explain how it separates assignment creation from email delivery, but acknowledge the unresolved duplicate and monitoring questions. You may change your recommendation if the discussion reveals a reason.
Reliability reviewer: Focus on temporary provider failure, repeated attempts, and undelivered messages. Ask what the team will observe and how it will recognize a problem. You do not have permission to invent an existing monitoring system.
Product reviewer: Focus on what users see when an assignment is saved but the email is delayed or missing. Ask which user experience the team is committing to during the pilot. Avoid turning a preference into a technical fact.
Facilitator: Keep a record of claims, questions, and decisions. Ask speakers to clarify whether a statement is evidence, an assumption, or a proposal. At the end, summarize the agreed next step and check that the group accepts the wording.
In groups of three, combine product reviewer and facilitator. Rotate roles for the second discussion so the same learner does not always perform the technically confident role. Everyone should practise both presenting and questioning.
Minutes 0–15: separate evidence from assumptions
After reading the brief, give learners five statements to classify:
- A: “The tests described here show extra response delay when email is sent during the request.”
- B: “The provider will fail only once a month.”
- C: “A background worker could let the request finish without waiting for email delivery.”
- D: “We should approve Option B for every customer immediately.”
- E: “We still need to measure queue waiting time at the expected peak load.”
Answer key: A reports supplied evidence. B is an unsupported assumption. C is a reasoned possibility, appropriately expressed with could, rather than a measured result. D is a recommendation that goes beyond the agreed pilot decision. E identifies a documented evidence gap.
Ask students to repair B and D. A possible repair for B is, “We don't know the failure frequency yet; what data can we collect during the pilot?” A repair for D is, “I suggest testing Option B in the limited pilot before deciding on wider release.” Other answers are acceptable if they preserve the uncertainty and scope.
Minutes 15–30: practise precise disagreement
Write three moves on the board: recognize the aim, identify the concern, and ask for evidence or propose a check. Model: “I agree that separating delivery from the request could help. My concern is duplicate emails after retries. How would we detect that in the pilot?” The acknowledgement must refer to the actual proposal, not become an empty compliment.
Compare it with “That won't scale” and “Your design is wrong.” Ask what information those statements fail to provide. Expected answers include the relevant load, failure mode, or condition. A direct disagreement is not automatically impolite; the problem here is that the listener cannot evaluate a vague objection.
Offer a small language bank: “That conclusion depends on…”, “What would change your recommendation?”, “Can we distinguish the test result from the assumption?”, “I see the benefit, but the unresolved issue is…”, and “Would a limited test answer that question?” Students choose two phrases they can use naturally, rather than trying to insert every phrase into the review.
Practise one exchange in pairs. The proposer makes a claim, the reviewer asks for its basis, and the proposer either supplies evidence or revises the claim. Score the revision positively when it becomes more accurate. Changing a position in response to information is part of the task.
Minutes 30–50: hold the first review
Give the proposer two minutes to present. Reviewers then have six minutes for questions, followed by four minutes to compare options. The facilitator uses a visible log with four headings: claim, evidence, unresolved question, and next action. Reserve the remaining time for writing a provisional decision.
Require each participant to paraphrase someone else's point once before responding. For example: “If I understand you, the concern is not the worker itself but how we know a notification is stuck.” The original speaker confirms or corrects that summary. This creates an observable listening task rather than a sequence of prepared speeches.
If the discussion stalls, introduce one neutral prompt: “What would you need to know before expanding the pilot?” Do not rescue the group by naming a particular vendor or architecture. Their task is to frame a decision and identify useful evidence within the supplied constraints.
A realistic model exchange and decision log
Proposer: “I suggest Option B for the pilot because assignment creation would not wait for the email call.” Reviewer: “That addresses response time, but what happens if the worker retries after the provider has already accepted a message?” Proposer: “The current proposal doesn't answer that. We need to define how we identify each notification and test repeated attempts.”
Product reviewer: “Can we also be clear about what users see if delivery is delayed?” Facilitator: “So we have two open questions: duplicate handling and the user-visible status. Are we approving a limited test, or the design for general release?” Proposer: “A limited test only, with those checks completed before expansion.”
A possible decision log reads: “Pilot Option B with a limited group. Before the pilot starts, define duplicate handling and the delivery status shown to users. During the pilot, measure queue waiting time and inspect undelivered messages. Review the findings before wider release. Assign an owner and review date for each check.” This is a classroom example, not a complete technical implementation plan.
The group could instead choose a tightly scoped test of Option A if it explains the response delay and missing-notification risk. Evaluate the reasoning against the brief, not against the model's choice.
Minutes 50–70: introduce a change and repeat
Give a new fictional condition: “The pilot group wants to assign several tasks at once. The team has not tested that pattern.” Ask learners which earlier assumptions need review. They should not silently reuse the first decision as if the conditions were identical.
Rotate roles and run a shorter review. Require one sentence describing what is unchanged, one describing the new uncertainty, and one proposing a check. This prevents the second round from becoming a performance of memorized disagreement phrases.
Observers record a moment when a speaker narrowed an overconfident claim, asked a decision-relevant question, or summarized an opposing view accurately. Collect examples without naming a “winning” participant. The useful result is a better shared decision record.
Minutes 70–80: feedback and B2 adaptations
Use four criteria scored 0–2: accurate treatment of evidence, specific questions or objections, responsive listening, and a clear conditional decision. Give 0 when the behavior is absent, 1 when it needs prompting, and 2 when it is independently clear. Ask for one quotation or log entry supporting each score.
For B2 learners, preteach the five technical terms, shorten the brief, and provide sentence frames. Let them plan an objection in writing before speaking. Keep the same intellectual task; reduce the language and memory load. For C1 learners, ask them to reformulate a broad objection into a precise condition and explain what evidence would change their position.
For homework, learners revise the decision log into a short message for a colleague who missed the review. The colleague should be able to identify the decision, its limits, and the next check. If you want related classroom materials, inspect the Tech & Startup English Pack, whose lesson list includes design-review disagreement alongside pitching and postmortem communication.