Surviving the HSC computing major project

Both HSC computing courses finish with a substantial project, and it is where marks are most often lost.

Rarely because the student could not do the work. Almost always because the scope was too ambitious, the planning was thin, or the documentation was written in a panic during the final fortnight.

Scope small, then go deeper

The most common and most damaging mistake is choosing something enormous.

A student picks an idea they are excited about, spends three months building 40% of it, runs out of time, and submits something incomplete with rushed documentation. It marks poorly, and it does not reflect their ability at all.

A small project done thoroughly, documented properly and fully working marks better than an ambitious one that is 70% finished. Every time.

Pick something you could realistically finish in half the available time. You will need the other half, because you will underestimate.

Then, if you finish early, add depth: better testing, better error handling, an extra feature done properly. Depth is easy to add. Rescuing scope is not.

Plan on paper before you build

Resist opening an editor for the first fortnight. It feels like wasted time and it is not.

Write down what the system is supposed to do, who uses it, what each screen or component is for, and what “finished” means. Sketch the interface on paper. Draw how the data moves.

Two reasons. You will build the wrong thing otherwise, and rework is expensive. And this planning material is directly assessable: the marking criteria reward the design process, not just the artefact.

Keep the messy early versions. Marks come from showing how the design evolved, and a clean final diagram with no history behind it evidences less.

Document as you go

This is the single highest-value habit, and almost nobody does it.

Keep a log. Every session, write three lines: what you worked on, what went wrong, what you decided and why.

It takes two minutes at the time. Reconstructing it in October takes days, and the reconstruction is always worse, because you have forgotten the decisions and the dead ends. Those are exactly the things that demonstrate the process.

Use version control if your course covers it. Git history is a documented record of your work at no extra effort, and it protects you against losing everything.

Test properly, and write it down

Testing is heavily weighted and consistently under-done.

Do not simply state that you tested it. Record what you tested, what input you used, what you expected, what actually happened, and what you changed. A table is fine.

Test the failures deliberately. What happens with no input? With text where a number is expected? With a date in the past? Handling those gracefully is a large part of what separates a good project from a working one.

Back it up, three ways

Every year, somebody loses a major project.

• Cloud storage, syncing automatically
• Version control, pushed regularly
• A copy on a USB stick or external drive, updated weekly

This is not paranoia. A failed drive in September with no backup is a catastrophe that cannot be recovered from, and the extenuating circumstances process will not give you back three months.

A realistic timeline

Weeks 1 to 2: Choose and scope. Write requirements. Sketch the design. Do not build.

Weeks 3 to 4: Build the smallest thing that works end to end, even badly. Getting something running early tells you what you did not understand.

Weeks 5 to 10: Build properly, in small pieces, testing as you go. Log every session.

Weeks 11 to 12: Stop adding features. Test thoroughly and fix.

Weeks 13 to 14: Documentation, using the log you have been keeping.

Final week: Buffer. You will need it, and if you do not, you will be the calmest person in the room.

On using AI

Be careful and be honest.

Using it to explain a concept you do not understand is study. Having it write the code you submit is cheating, breaches NESA rules, and puts your HSC at risk.

There is also a practical trap: if AI wrote your project, the written examination will find out, because it examines the same content and you will not have learned it. The longer guide on this covers where the line sits.

The safest test: never submit a line you could not explain if a marker asked.

Where to get help

Your teacher first. They know the marking criteria in detail and they have supervised many of these.

Where I help is the industry side: scoping something realistic, reviewing a plan and pointing out what will hurt you in eight weeks, explaining a concept you are stuck on, and showing you what professional documentation and testing actually look like.

What I will not do is write any part of it, because that would breach the rules and remove the entire point of the exercise. Details on the school subjects page.

Get help early rather than in the last fortnight. By then the only available advice is about damage limitation.