At a glance
Solo · four working periods and two dress runs in the final weeks · the launch itself is in the last full week of building · one artifact, one growth statement, one design defended at the Day 12 questions
What you are making
The culminating task: a computational artifact designed and built for a real user who is not you — a younger sibling, a club you belong to, a teacher, a coach, a family business. Two full-credit paths exist:
- a working program that does something your user needs —
structured into subprograms and leveraging standard or add-on
libraries/modules (such as
random,math,time, or string utilities as introduced in Subprograms and Modules) where appropriate, or - a thoroughly designed plan plus prototype — the user research, the algorithm, the interface sketches, and a working core piece — for something bigger than one course can build.
Either way, five things must be present: a plan (what the core is, and the pieces it breaks into), a user-needs statement (who they are, and what they need), a working core (leveraging modular design and external or built-in modules as needed), an honest known-limits list, and documentation clear enough for a stranger to reuse your work. The launch itself: a short demo, the questions your guests ask, and a growth statement built from your Dev Journal. The design you defend in conversation is defended on day 5, in the questions I ask while the room documents — the launch is too busy for it, and this page’s teacher notes say so.
This is the course’s final evaluation — the thirty per cent described in How Marks Work — which is why it asks for the whole of the building side at once: planning, programming, documenting, and saying out loud why it works this way. The only part done outside class is the first one — finding your user and talking to them. Everything that carries a mark is built here: the plan and the building across three periods, a whole period for the documentation, two dress runs, and the growth statement written in class the day before the launch.
How to work
- Find your user and actually talk to them. Write down who they are and what they need — their words first, then what it must do.
- Plan with the four moves from Computational Thinking and choose your path — program, or plan-plus-prototype. Check with me first.
- Build the core first. A small thing that works beats a big thing that almost does — the ceiling is open, but the floor is “it runs”.
- Keep the known-limits list as you go — every limit you name is a decision, not a confession, and How Marks Work says why.
- Write the reuse documentation: what it does, how to run it, how to change it, one line on who else this touches besides your user, and one on what it stores — where that lives, who can see it, and what you did about it. Writing Good Comments goes inside the code itself.
- Build your growth statement the way Showing Growth describes, quoting your own early journal entries as evidence. It is written in class on the second dress-run day, when you have just watched your own work run end to end.
The launch itself
The event is a room with guests in it, so three things get rehearsed rather than improvised: the two sentences you open with, the failure plan — what you say and do when it breaks in front of somebody, because sometimes it will — and the room, meaning where guests stand, where machines go, and who greets people at the door. The first dress run period sets the room, runs every machine, and then runs the whole event in order; the second has the failures triggered on purpose.
Success criteria
| Quality | What it looks like at your launch |
|---|---|
| A real user served | The needs statement names a person, in their words, and the documentation says who else this touches |
| A plan you can point at | The pieces of the artifact match the way you broke the problem up |
| A working core | The central thing your user needs demonstrably works |
| Modular and library integration | Subprograms, functions, or external/built-in modules are used cleanly to solve user tasks |
| Honest limits | The known-limits list is specific, current, and unashamed |
| Built for reuse | A stranger could run it, follow the code, and change it — your comments and names do that work |
| Careful with what it keeps | The documentation says what the artifact stores, where that lives, who can see it, and what you chose to do about it |
| A defended design | You can say why it works this way and what you rejected |
| A demo that lands | The room sees the thing working, in order, in the time you had |
| Visible growth | The growth statement quotes your own journal as evidence — what is judged is the evidence and the argument, never your verdict on yourself |
Reflect
The growth statement is the reflection, and it feeds your Final Reflection: read your Dev Journal from the first entry forward, find where your thinking changed, then add one last entry — what would you tell the you who started this course about building for other people?
If you cannot find a user (click to expand)
Look closer. The sibling with spelling words to practise, the club tracking dues on paper, the teacher retyping the same schedule, this classroom itself — real users are within ten metres of you. Ask three people what annoys them; one answer will be your project.
Curriculum connection
A1.1
apply computational thinking concepts and practices when planning and designing computational artifacts
Link to original
A1.2
use a variety of tools and processes to plan, design, and share algorithms and computational artifacts
Link to original
A1.3
develop computational artifacts for a variety of contexts and purposes that support the needs of diverse users and audiences
Link to original
B2.1
use file management techniques, including those related to local and cloud storage, to organize, edit, and share files
Link to original
B3.2
apply safe and effective security practices, including practices to protect their privacy, when using digital technology in various contexts
Link to original
C2.7
write clear internal documentation and use coding standards to improve code readability
Link to original
C3.4
write programs that make use of external or add-on modules or libraries
Link to original
C3.5
explain the components of a computational artifact they have created, including considerations for reuse by others
Link to original