5 exercises — master will, going to, and present continuous for talking about launches, deadlines, plans, and decisions in software project management.
Future tense guide
will → spontaneous decision / formal written docs: "I'll fix it", "The API will return 404"
going to → intention already decided / prediction from evidence: "We're going to refactor it"
A project manager says in a stand-up: "We ___ launch the new billing module next Tuesday — it's already in the release calendar." Which future form is most appropriate?
Are launching (present continuous for future) is most appropriate. When an event is scheduled and already arranged — booked in a calendar, assigned in a project tracker, confirmed with stakeholders — English uses the present continuous. This signals a firm, pre-planned commitment: "We are launching on Tuesday", "The team is demoing to the client on Friday", "The sprint is ending on Thursday."Will launch works too but feels more like a spontaneous decision or prediction. Going to launch implies intention — slightly less fixed than a scheduled event. Present simple (launch) is used for timetabled events: "The conference starts at 9am" — technically valid but less common for software releases. In project management English, present continuous is the natural choice for diary-based plans.
2 / 5
A developer says: "Look at these memory leak graphs — the server ___ crash under tonight's load if we don't patch it." Which form expresses a strong prediction based on current evidence?
Is going to crash is correct. Going to + infinitive is used for predictions based on present evidence — something you can see is clearly heading toward an outcome. The key phrase is "look at these graphs" — visible evidence supports the prediction. Compare: "It is going to rain" (you can see dark clouds). In tech contexts: "The disk usage is going to hit 100% by morning — look at the trend." · "That query is going to timeout — the execution plan is terrible."Will is used for predictions without specific present evidence — general beliefs or forecasts: "I think the migration will take two weeks." The distinction: going to = evidence right now; will = general expectation or spontaneous decision.
3 / 5
A CTO says in a planning meeting: "We ___ migrate all services to Kubernetes by Q3. That's the direction we've decided on." Which future form expresses a firm intention or plan?
Are going to migrate is correct for a firm intention or plan already decided. When a decision has been made prior to the moment of speaking, going to is the standard choice: "We're going to refactor the authentication layer — we decided last week." · "The company is going to adopt a platform engineering model." The phrase "that's the direction we've decided on" confirms this is a pre-existing decision, not a spontaneous one. Will could also work here (and is common in formal written communication), but going to better signals that the decision is already made. Are migrating (present continuous) would imply it's already in the calendar with a specific date — possible, but the Q3 timeframe makes going to more appropriate.
4 / 5
A junior developer messages a colleague: "Can you review this PR? I ___ fix the failing tests while you look at the logic." Which future form signals a spontaneous offer or decision made at the moment of speaking?
'll fix (will) is correct for a spontaneous decision or offer made at the moment of speaking. When you decide something as you say it — not based on a pre-existing plan — use will. Examples: "I'll take care of the merge conflict." · "We'll schedule a call to discuss it." · "I'll open a ticket for that." This is the most common use of will in day-to-day tech communication: responding to a situation in real time. Contrast with going to: "I'm going to fix the tests" implies you already had a plan to do so. Am fixing implies it's already in progress. Will is the natural form for offers, promises, and instant decisions — all extremely common in team communication.
5 / 5
A product manager writes in a roadmap doc: "The API v3 ___ deprecate API v2 automatically after 12 months." Which form is most appropriate for a scheduled, timetable-based future event in documentation?
Will deprecate is the most appropriate form for a scheduled, policy-driven future event in written documentation. In formal written English (roadmaps, specs, RFCs, API documentation), will is the standard future marker because it sounds authoritative and definitive: "Version 3.0 will replace version 2.0." · "This endpoint will return a 410 status after deprecation." · "The feature flag will be removed in the next major release."Going to can sound too conversational for spec documents. Is deprecating implies a specific date already set — possible but less precise for a "12 months from launch" policy. Note the spelling error in option D: depreciates means loses monetary value (depreciation), not technical removal (deprecation) — a common confusion worth remembering.