At a glance
Teams of three or four · launched Unit 3, Day 8 and running underneath every class of Unit 4 · a real community partner, a version-controlled team build, reviewed code, and a handover package somebody else can act on · the culminating project of this course
What you are making
Software for a real community partner, built by a team, using version control, reviewed before it lands, documented for the person who comes after you, and handed over so it survives your graduation.
Last year, in ICS3U, one student built one small thing for one client. This year the escalation is not size — it is that nobody on your team can hold the whole program in their head, and that is the point. You will read code your teammate wrote this morning, disagree about a design, resolve a merge conflict, review work you did not write, and hand the result to somebody who was not in the room for any of it.
Your partner is a person or a small organisation who can talk to you more than once: a teacher who runs a club, a coach, a librarian, an office administrator, a community garden, a food programme, a neighbourhood association, a small business somebody’s family runs. Not “students in general”. Not the school as an abstraction. Not hypothetical.
The bar is unchanged from last year and it is still the only bar that matters: a month after handover, is it still being used?
Your team
Three or four people. Everyone writes code — there are no non-programming roles in this course — but each person also owns one responsibility, named in writing, that they answer for:
| Role | Answers for |
|---|---|
| Partner liaison | Every conversation with the partner, and consent |
| Integration lead | The shared branch stays working; merges get resolved |
| Test lead | The testing plan exists and somebody ran it |
| Documentation lead | The handover package is real and readable |
Rotate them if you like, but write down when you rotated. Roles are not a hierarchy: the integration lead does not approve their own code, and the partner liaison does not get to promise features the team has not agreed to.
Disagreement is expected and has a protocol — see Working in a Team and use it before the argument becomes about people.
Consent, privacy, and honest scope
This is the craft, not the paperwork.
- Consent to be named, in your documentation and at the handover. If your partner says no, they are “a community garden coordinator” in everything you write, permanently.
- Consent for the time. Name the cost in minutes — one interview, one testing session, one handover — and keep to it.
- Collect nothing you do not need. Initials instead of names, a count instead of a list of people. Every field you do not store is a risk you did not create.
- Never collect contact details, marks, health or financial information, or anything about a third party who is not in the conversation. If the problem seems to require it, change the design, not the rule.
- Say where the data lives, what is in it, how to back it up, and how to delete it. Your partner must be able to delete it without you.
- They can stop, at any point, including after the handover.
- Name your core: the one feature that, if nothing else worked, would still be worth your partner’s time. Build that first, finish it, and keep a “deliberately not doing” list from the first week. An item you can defend is a decision. An item quietly attempted and abandoned is a mess.
Your team’s code of practice
Before any code is written, your team writes one page setting out how you will work and what you will not do. It is not decoration: at the handover, your partner is told it exists and what is in it.
Ground it in a real professional code — the ACM Code of Ethics and Professional Conduct, the IEEE Code of Ethics, or the Canadian Information Processing Society’s — and say which one you drew from. Read the actual document; do not summarise a summary. Your page has four parts:
- What we owe the person we are building for: honesty about what the software does and does not do, and about when we are behind.
- What we owe people who are not in the room: anybody whose data passes through this, anybody affected by a decision it makes.
- What we will not do, specifically, even if asked.
- Why a profession needs a written code at all — in your own words, two or three sentences. Engineers, doctors, and lawyers have one for reasons; programmers now build systems with comparable reach and, in most jurisdictions, no licence at all.
Then apply it. When a decision in the build runs into the page — a shortcut that would collect one extra field, a demo that would overstate what works — record the decision and what you did. Those records are marked. A code nobody consulted is a code nobody wrote.
Milestones
Checked in class, on the day named. Nothing here is a final-week scramble; a project that reaches Unit 4, Day 9 without a working core is a project I will help you cut down, not one you should rescue by staying up.
- Unit 3, Day 8 — launched. Two possible partners per team, each with the problem in their own words.
- Unit 3, Day 12 — partner, roles, and algorithms agreed. One confirmed partner; roles posted in writing; your search and sort choices defended out loud with their costs.
- Unit 3, Day 13 — interviewed, with consent and scope in writing. The problem in your partner’s own words, their consent recorded, and the scope document submitted with its “deliberately not doing” list.
- Unit 3, Day 16 — the walking skeleton runs, badly, end to end, on invented data — or you say plainly what stopped it.
- Unit 4, Day 1 — version control running. Repository set up, at least one commit from every member, and one conflict already resolved on purpose.
- Unit 4, Day 2 — building on branches. First feature branch open with readable work on it and commit messages a stranger could act on.
- Unit 4, Day 3 — testing plan, and tests you did not author. Written plan naming who tests what, plus tests over code another teammate wrote.
- Unit 4, Day 5 — reviewed. Every member has reviewed a teammate’s code and had their own reviewed, using the protocol in The Code Review; agreements recorded in the history.
- Unit 4, Day 9 — tested by your partner, in the room, with your hands off the keyboard, and what you saw triaged into defect, request, or misunderstanding.
- Unit 4, Day 11 — feature freeze. Defects fixed, every test re-run. Only repairs and writing after this.
- Unit 4, Day 15 — privacy statement, drafted in that day’s build period and finished for Day 16’s review: what it stores, where, and how your partner deletes it, in their language.
- Unit 4, Day 16 — reviewed by another team, against your code of practice as well as your code, and the top three comments acted on in the same period.
- Unit 4, Day 18 — handover rehearsed on a team who play your partner, and whatever they could not follow repaired.
- Unit 4, Day 19 — documented and submitted. Final build, and the handover package complete.
- Unit 4, Day 20 — handed over. Your partner runs it in front of the room at The Handover and takes it home.
The handover package
“Handed over” means your partner can use it next month without you, and somebody else can change it next year without you. That takes more than a folder of files. The full contents, and the standard they are judged against, are set out in The Handover — read it in Unit 4, Day 1, not in Unit 4, Day 19.
How your individual contribution is evidenced
A team mark alone would be a lie about who did what. Your individual work is assessed from four sources, all of which you create as you go and none of which can be manufactured at the end:
- The history. Your commits, with messages that say what changed and why. A hundred commits saying “update” evidence nothing. This is also why the repository must be running from Unit 4, Day 1 — a history that begins the night before the deadline documents exactly that.
- Your review comments. What you asked of teammates’ code, and what changed because you asked. Reviewing well is contribution.
- Your Code Journal. An entry at every milestone, including the honest ones: what you got wrong, what you rewrote, what you argued for and lost. Per Journal Checklist.
- Your role. What you answered for, and whether it held.
Per How Marks Work, the working periods are where two of the three kinds of evidence come from: what I watch you do, and what you tell me at the milestone check-ins. This project is judged across five weeks, not on the last day. Judging Your Own Work is how you read the table below before I do — Unit 3, Day 18 is the period set aside for it, and Days 20 and 21 are where the two rows it names get fixed.
Success criteria
| Quality | What it looks like in your project |
|---|---|
| A real partner | Named or deliberately anonymised, consenting, met twice |
| Their problem, their words | The agreed sentence is theirs, confirmed |
| Honest scope | Finished core plus a defended “not doing” list |
| Defended algorithms | Choices stated with their costs, not copied |
| Version control as practice | Branches, real messages, conflicts resolved |
| Reviewed before merged | Every member reviews and is reviewed |
| Tested, including inherited code | A plan, plus tests over others’ work |
| Privacy as craft | Nothing collected that was not needed and agreed |
| A real handover | Package complete and in your partner’s hands |
| Visible individual work | History, reviews, and journal all agree |
Reflect
Two questions, in your Final Reflection. First: what did your team build that your partner did not need, and at what point could you have known? Second — the question this course has been circling since the first morning, when you were handed a program nobody in the room had written — what did your team do so that the person who inherits this does not have the day you had? Then read What Happens When You Leave and answer it honestly.
If your team is stuck, at any stage
Three failures account for nearly all of them. No partner by Unit 3, Day 12: come to me, I keep a list of people in this building and the neighbourhood who have already said yes. The team has stopped talking: run the disagreement protocol in Working in a Team in a working period, with me present if you want. The scope is too big, which shows up as three half-features and no working core: cut it in the working period, tell your partner what they will and will not be getting, and finish the smaller thing properly. All three are ordinary and all three are recoverable — in week two. In week five, only the third one is.
Curriculum connection
B1.1
create a software project plan by producing a software scope document and determining the tasks, deliverables, and schedule;
Link to original
B1.2
develop the software product according to the project plan (i.e., ensure that the software meets end user needs, functions as intended, and can be produced within quality standards, budget, and timelines);
Link to original
B1.3
produce the software according to specifications (i.e., code, test, deploy), and create user documentation and training materials;
Link to original
B1.4
use an appropriate project management tool (e.g., Gantt chart, PERT chart, calendar) to manage project components;
Link to original
B1.5
close the project (i.e., confirm that software meets all user requirements, deliver software in appropriate format, plan software support and maintenance);
Link to original
B1.7
demonstrate the ability to use shared resources to manage source code effectively and securely (e.g., organize software components using shared files and folders with timestamps, and proper version control).
Link to original
B2.1
demonstrate the ability to contribute, as a team member, to the planning, development, and production of a large software project;
Link to original
B2.2
demonstrate the ability to meet project goals and deadlines by managing individual time during a group project;
Link to original
B2.3
reflect on, and assess, team and individual progress during the project review.
Link to original
A4.4
create clear and maintainable external user documentation (e.g., Help files, training materials, user manuals).
Link to original
D2.1
investigate and analyse an ethical issue related to the use of computers (e.g., sharing passwords, music and video file downloading, software piracy, keystroke logging, phishing, cyberbullying);
Link to original
D2.2
describe the essential elements of a code of ethics for computer programmers (e.g., ACM [Association for Computing Machinery] and IEEE [Institute of Electrical and Electronics Engineers] standards) and explain why there is a need for such a code (e.g., plagiarism, backdoors, viruses, spyware, logic bombs);
Link to original
D2.3
outline and apply strategies to encourage ethical computing practices at home, at school, and at work.
Link to original