Defend the System You Actually Built

The design defense is not a sales pitch.

You are not trying to convince the reviewer that your project is amazing. You are showing that you understand the decisions, evidence, and limitations of the system you actually built.

Five-minute defense structure

1. Problem and user

In 30-45 seconds:

Who is the user?
What problem does the program solve?
What is intentionally out of scope?

2. Architecture

Show one diagram.

Explain the responsibilities of the major components and the direction of dependencies.

Do not read every class name. Explain why the boundaries exist.

3. Data and object model

Defend:

• primary collection/data structure;
• key class/record choice;
• one invariant;
• interface/composition decision;
• inheritance use or rejection.

4. Validation evidence

Show the test matrix and one passing normal/boundary/invalid case.

If you used JUnit 6, show runner evidence. If you used the browser core, show the deterministic harness and say so plainly.

5. Failure and revision

This is the strongest part of the defense.

Show:

Version 1 failure
first divergent state
root cause
controlled Version 2 change
regression result

A real failure you can explain demonstrates more engineering understanding than pretending development was flawless.

6. Limitation and next experiment

Name one limitation and one specific next test or design change.

Do not finish with "I would add more features." Name the evidence gap you would close.

Be ready for challenge questions

Examples:

• Why a Map instead of a List?
• What happens with empty input?
• Where is invalid state blocked?
• Why is this an interface?
• What would break if this implementation changed?
• Why did you use composition here?
• What proves the bug is fixed beyond one input?
• Which part did you not test in the browser environment?
• Where would the design become difficult to scale?

If you cannot answer, say what evidence you would inspect. Do not invent behavior.

Final architecture check

Before presenting, remove claims your evidence does not support.

Examples:

• "works on every computer";
• "secure" with no threat model;
• "handles any file" after testing one fixture;
• "fully tested" with only happy paths;
• "fast" without measurement.

Use precise claims:

Version 2 passed the 12-case matrix shown here in the Java 25 environment used for this project.

That is defensible.

Final artifact

Package the code and dossier so another person can follow the evidence chain without relying on your memory.

The project is complete when its decisions and validation are inspectable, not when the last slide looks polished.