At a glance
The finale · one class period, guests present · five minutes each: your client runs your app, you hand it over, the room asks one honest question · assessed on the handover and the critique, not on polish
What happens
Your client comes to class. They sit at the machine. They run the app — themselves, with their own hands, while you keep yours off the keyboard — and the room watches something you built being used by the person it was built for.
Then you hand it over properly, in front of everybody, and the class asks one question each.
That is the whole event, repeated across the period. It is not a presentation about software. It is software changing hands.
Your five minutes
- Twenty seconds of context. Who your client is (named, if they agreed) and the problem in their sentence, not your summary.
- Two minutes of them using it. They drive. You may say “go ahead”, and nothing else. If something breaks, let it break — a handled failure in front of an audience is a better demonstration than a rehearsed success, and it is marked as one.
- One minute of handover. Give them the folder and the one-page guide. Say out loud where the data lives, what it does not do, and when you will check in with them. Then say the date of that check-in, and write it down where they can see you write it.
- One minute of honesty. The one thing you cut and why, and the one thing you would do next.
- The room’s question. One question, from one classmate, answered straight.
Preparing
- Rehearse with somebody who has never seen it, the way you did at the hand-off in Unit 1 — silently. Whatever they hesitate over is what your client will hesitate over.
- Test the machine you will actually use, with the files where they will actually be. Most launch failures are a missing file, not a bug.
- Tell your client what will happen, how long it will take, and that they are not being tested. Offer them the guide beforehand so they are not reading it for the first time in front of an audience.
- If your client cannot attend, arrange a stand-in from the class to run it cold from your guide alone, and record your real client’s reaction separately. That is a legitimate route, and it is marked the same.
The critique, which is also assessed
You will watch a dozen launches. For each one, on a card, write two things and nothing else:
| What you write | What it must be |
|---|---|
| One thing that worked | Specific and observed, not “good job” |
| One honest question | Real curiosity, aimed at a decision, not a flaw |
The questions are the assessed part. “Why did you decide to ask for the date first?” is a question. “Why didn’t you add a menu?” is a suggestion wearing a question’s clothes, and it helps nobody at the moment when the work is finished. The manners here are the ones from The Bad Input Hunt: attack the design question, never the designer.
Hand your cards to the presenters at the end. Everyone leaves with a dozen specific observations of their own work in somebody else’s hands.
Per How Marks Work, both halves of the day count: your own five minutes, and the dozen cards you wrote while other people had theirs. A specific, generous critique of somebody else’s design is evidence of your own understanding, and it is marked as exactly that.
Success criteria
| Quality | What it looks like on the day |
|---|---|
| They drove | Your client used it; you did not touch the keyboard |
| Their words | The problem was stated as your client states it |
| A real handover | Files, guide, data location, limits, and a check-in date |
| Honest about limits | You named the cut and the reason without flinching |
| Composure under failure | Anything that broke was handled in the open |
| Generous critique | Your cards are specific, curious, and useful |
Reflect
Your last Code Journal entry, written the same day while it is still uncomfortable: what happened in the two minutes when somebody else was driving? Then finish Final Reflection, which asks you to read the whole semester back from your first entry — and to name the work habits that actually got this project finished, because those, far more than any syntax, are what carries into whatever you do next.
If the demo fails in front of everybody
Then you get to demonstrate the most professional skill in the course. Say what you expected, say what happened, say what you think caused it, and say what you would check first. That is a debugging narration, delivered live, and it is worth more marks than a smooth run — because a smooth run proves the app works today, while the narration proves you work on any day. This is Mistakes Are Data with an audience, and everybody in the room, including your client, will trust you more afterwards.
Curriculum connection
B2.2
use appropriate vocabulary and mode of expression (i.e., written, oral, diagrammatic) to describe alternative program designs, and to explain the structure of a program;
Link to original
B4.6
communicate information about the status of a project (e.g., milestones, work completed, work outstanding) effectively in writing throughout the project.
Link to original
D3.5
describe the Essential Skills and work habits that are important for success in computer studies, as identified in the Ontario Skills Passport.
Link to original