Make a technical decision under constraint

2370. Lesson identity

Module

5.14 — Technical direction

Lesson

1 — Make a technical decision under constraint

Academic type

Case Study

Schema type

case-study

Order

1

Estimated time

35–45 minutes, including practice

2371. Learning objective

After this lesson, you can write an architecture decision record that compares bounded options, states the selected path, identifies its risks, defines evidence for revisiting the decision, and records a recoverable checkpoint.

2372. Why this matters

Technical direction is not a contest to select the most sophisticated architecture. In a game project, every additional system creates cost in implementation, testing, debugging, and future change. AI can quickly produce plausible designs, but plausibility is not evidence that a design fits the project. A concise decision record makes the reasoning inspectable and gives the team a way to reverse course when new evidence appears.

2373. Prior knowledge

You should be able to:

• distinguish a player-facing requirement from an implementation preference;
• identify risks and prioritize the safest intervention, as practiced in 5.13 L2 — Prioritize the safest intervention;
• describe a bounded game feature and its acceptance evidence;
• compare options using constraints rather than novelty.

No particular engine, framework, or codebase is required for this case study.

2374. Core concept

Choose the least complex option that satisfies the current requirement and preserves a deliberate path for learning or change. The decision must also name the tools used to record, evaluate, and review it—for example, the project issue tracker, ADR document, test or profiling tool, and version-control interface. Tool choice is part of technical direction because an option that cannot be inspected with the team’s available tools is not operationally sufficient.

A technical decision is not only a choice. It is a claim:

Given these requirements, constraints, and current evidence, this option is sufficient and its risks are acceptable.

A strong decision record makes four things explicit:

1. Tradeoffs: what the option improves and what it gives up.
2. Risk: what could fail, and how costly that failure would be.
3. Reversibility: how difficult it would be to replace the choice later.
4. Evidence: what observation would confirm, challenge, or reopen the decision.

2375. Mental model

The Sufficient Path test

A useful decision record has this structure:

Title
Status: proposed / accepted / superseded
Context and constraints
Decision
Options considered
Tradeoffs and risks
Reversibility boundary
Evidence and review trigger
Consequences

Do not rank options by prestige. Rank them by fit for the current scope and by the cost of being wrong.

2376. Concrete example

This hypothetical case is intentionally bounded.

A small game prototype needs to remember three settings between sessions: audio volume, display mode, and a control preference. The team has two weeks to make the feature reliable. There is no current requirement for cloud synchronization, multiple devices, or user accounts.

A sufficient decision for the stated scope is the local record, provided that the access boundary is isolated and the record has a version. The decision does not claim that remote synchronization is never useful. It claims that the current requirement does not justify its cost and risk.

The review trigger might be: “Reopen this decision if synchronized settings across devices become a committed requirement.” That is stronger than “use the better solution later” because it names observable evidence.

2377. AI-native workflow

Use AI as a comparison and criticism tool, not as the authority that selects the architecture.

1. Write the requirement, constraints, and two candidate options yourself.
2. Ask AI to identify hidden assumptions, likely failure modes, and missing evidence. Do not ask it to choose first.
3. Compare its analysis with your project constraints. Mark each suggestion as accepted, rejected, or needs evidence.
4. Ask AI to challenge your preferred option with a failure scenario.
5. Write the final architecture decision record in your own words.

A useful prompt is:

Act as a skeptical technical reviewer. Given this requirement, these constraints, and these two options, list the tradeoffs, failure modes, reversibility concerns, and evidence that would justify reopening the decision. Do not select an option for me and do not invent project requirements.

The learner remains responsible for the requirement, the decision, and the evidence threshold.

2378. Common mistake

The common mistake is choosing an architecture because it appears future-proof. A future possibility is not automatically a present requirement. Overbuilding can reduce reversibility by spreading one decision across authentication, data, testing, deployment, and debugging systems. A simpler option is not automatically correct either; it must still satisfy the requirement and expose a safe boundary for future change.

2379. Guided practice

Write an architecture decision record for this hypothetical case:

A two-week game prototype needs a run summary after each session. The summary must show score, elapsed time, and three collected item counts. It does not need to be shared online, persisted across devices, or queried by external tools. The team may either (A) pass an immutable summary object directly from the run system to the results screen, minimizing new infrastructure but coupling that handoff to the two systems, or (B) place the latest summary behind a small run-summary repository that the results screen reads, adding lifecycle and stale-data risks but providing a stable boundary if another in-prototype screen is confirmed to need the same data.

Complete the following steps:

1. State the requirement and at least three constraints.
2. Compare options A and B using immediate cost, failure risk, and reversibility.
3. Select one option, explain why it is sufficient now, and state what evidence about reuse or lifecycle risk supports your choice.
4. Name one boundary that would make replacement easier later.
5. Define one observable review trigger.
6. Record one consequence that the team accepts.
7. Create a reviewable decision checkpoint containing the ADR, its status, and the selected option. Use the project’s Git workflow to make one meaningful commit whose message identifies the decision and scope. Only if Git is genuinely unavailable, record a justified equivalent exception in the ADR, including why Git cannot be used, the exact versioned snapshot or review location, and who verified it.
8. Document a recovery path: state which checkpoint would be restored, what evidence would justify reverting or superseding the decision, and what must be reviewed before continuing. Do not implement the architecture or perform engine-specific work.

Your record should be specific enough that another developer could disagree with the decision for a stated reason rather than merely preferring a different style.

2380. Validation / evidence

Your work passes this lesson when the ADR contains all of the following:

• a bounded requirement rather than a broad technical ambition;
• explicit constraints, including at least one time or scope constraint;
• at least two considered options;
• a selected option justified by fit, not novelty;
• one named risk and its likely consequence;
• a reversibility boundary;
• an observable condition that would reopen the decision;
• consequences the team accepts;
• a reviewable decision checkpoint represented by a meaningful Git commit; use an equivalent versioned review point only under a documented, justified exception that names the limitation and verifier;
• a documented recovery path that identifies the checkpoint to restore or supersede and the evidence required to do so.

The checkpoint must make the decision easy for another person to inspect without reconstructing the reasoning from unrelated changes. The recovery path must describe how to return to the last accepted decision or formally supersede it; it must not depend on unrecorded memory.

If the record says only “Option A is simpler,” revise it. Simplicity is useful only when connected to scope, risk, evidence, and a recoverable review point.

2381. Key takeaways

• Technical direction is a constrained decision, not a search for the most impressive architecture.
• Evaluate options by requirement fit, present cost, risk, and reversibility.
• A decision record should state what evidence would cause review.
• A meaningful checkpoint and recovery path make the decision operationally reviewable.
• AI can expose assumptions and failure modes, but the developer owns the constraints and final choice.

2382. Next lesson

Continue to 5.14 L2 — Define technical gates for a small team.

2383. Knowledge check