VCE Software Development common mistakes
VCE Software Development · Understand the traps and how to avoid them.
When asked to design a solution, the candidate jumps straight to writing code or naming a programming language instead of stating the functional and non-functional requirements and a design (data structures, modules, user interface) first.
Students practise coding far more than design, and under exam time pressure the concrete task of writing pseudocode feels safer than producing an abstract design. They also misread 'design' as 'build'.
What to do instead
Before answering any design question, spend 60 seconds writing a short requirements list (what the solution must do, plus constraints such as performance, security, accessibility) and a module/data breakdown. Practise past design prompts by producing only the design artefacts, never code, and self-check against the marking scheme's design criteria.
The candidate writes pseudocode that is ambiguous or not language-neutral, mixing in Python indentation rules or Java syntax, or uses a diagram with unlabelled arrows and undeclared variables.
Students learn one language deeply and default to its idioms; they also assume the assessor will 'work out' what they meant. Pseudocode conventions are rarely drilled explicitly.
What to do instead
Adopt one consistent pseudocode convention (declared variables, explicit INPUT/OUTPUT, IF/ENDIF, LOOP/ENDLOOP) and use it in every practice response. Have a peer read the pseudocode aloud and execute it literally; any step they cannot follow is ambiguous and must be rewritten.
When tracing an algorithm or writing a test, the candidate checks only typical input and misses boundary and invalid cases, or traces a loop without tracking variable values line by line and so reports the wrong final output.
Students test with 'nice' numbers because that is what they do when their own code appears to work. Tracing is slow and error-prone, so they guess the result instead of simulating it.
What to do instead
Use a fixed test-case template: at least one normal case, one boundary case (empty, zero, maximum, first/last element), and one invalid or error case. For traces, draw a table with one column per variable and one row per iteration, and update every value before moving to the next line.
The candidate describes a data structure as 'a place to store data' or confuses a flat file with a relational database, and cannot explain why a particular structure or storage method suits the scenario.
Definitions are memorised as slogans without being linked to a purpose, so students cannot select or justify a structure when a scenario is presented.
What to do instead
For each structure (array, record, list, stack, queue, associative array, relational table), memorise three things: its defining property, one operation it makes efficient, and one scenario where it is the wrong choice. Practise scenario questions by writing a one-sentence justification that names the required operation (search, insert, ordered retrieval) and links it to the structure's property.
The candidate designs a database with no primary key, stores the same fact in several tables, or repeats a group of values in one field, and fails to identify anomalies in a supplied schema.
Students model tables as they would a spreadsheet, copying columns between sheets for convenience, and have not practised spotting redundancy or update, insert and delete anomalies.
What to do instead
Apply a checklist to every schema: does each table have a primary key; does every non-key field depend on the whole key; is any fact stored twice; can a record be inserted or deleted without losing unrelated data. Normalise practice schemas to third normal form and write down which anomaly each change removes.
The candidate answers a security or data-integrity question with a single generic word such as 'encryption' or 'validation' without saying what is protected, where it is applied, or what threat it addresses.
Keywords are easy to recall and students hope the marker awards the point; they have not learned to expand an answer into a mechanism plus purpose.
What to do instead
Use a three-part sentence pattern: the control, where it is applied, and the risk it reduces (for example, hashing passwords before storage so a stolen database does not reveal user passwords). Practise converting every one-word answer in your notes into this pattern.
When asked about project management, the candidate lists phases of the development model but does not sequence them, allocate time, identify dependencies, or name a deliverable and evaluation point for each.
The model is learned as a vocabulary list rather than as a plan, and students do not connect milestones to the project's actual constraints.
What to do instead
For each model (waterfall, agile, spiral), write a one-page plan for a small scenario: phases in order, a time estimate per phase, dependencies between tasks, and the artefact that marks each milestone. Include at least one risk and its mitigation, since planning questions usually award marks for risk handling.
The candidate evaluates a solution by asserting 'it works well' or 'the interface is good' instead of referring to the original requirements, measurable criteria, and evidence from testing.
Evaluation is treated as a closing formality, and students lack practice in turning requirements into testable criteria, so they have nothing concrete to judge against.
What to do instead
Before writing an evaluation, restate each requirement as a measurable criterion and give a verdict with evidence for each. Use the frame: requirement, test performed, result, whether the criterion was met, and what would be changed. Keep a written record of test results during practice projects.
The candidate answers an 'explain' or 'justify' question with a bare definition or a list of features, omitting the reasoning that links the feature to the scenario's needs.
Students match the keyword in the question to a memorised definition and stop, underestimating how many marks come from the causal link rather than the term.
What to do instead
Count the marks and write one linked sentence per mark using because, so that, or which means. After each practice answer, underline every causal connective; if there are fewer than the marks available, add reasoning rather than more terms.
The candidate runs out of time because they spend too long on early multiple-choice or short-answer items, leave extended responses unfinished, and do not attempt questions on topics they find hard.
No timed rehearsal, so students cannot judge how long a multi-part question takes; perfectionism on easy items and avoidance of weak topics both consume or waste marks.
What to do instead
Sit at least three full timed papers under exam conditions, allocating minutes proportional to marks and enforcing a move-on rule when a question exceeds its budget. Log every topic you skipped and revise those first. In the exam, write a brief plan for extended answers before writing, and always attempt every question, since partial reasoning earns marks.