7COM1025: why does working code still get a low mark?

The most disorienting moment on 7COM1025 arrives when a submission that compiles, runs, and passes every test comes back in the middle bands.

The most disorienting moment on 7COM1025 arrives when a submission that compiles, runs, and passes every test comes back in the middle bands. Students who have programmed professionally feel it hardest, because the standard they brought with them, the code works, is the standard this module treats as the starting line rather than the finish. Programming for Software Engineers is a Level 7 module, and Level 7 assesses engineering judgement: what you chose, what you rejected, and what evidence you can produce that the choice was sound. Below is what MAAS mentors find themselves explaining most often to Vietnamese students taking this module at Hertfordshire.

Author: MAAS Editorial Team · Reviewed by a Senior Computing mentor (PhD, Software Engineering)
Last updated: 2026-08-10
Category: writing-tips

What is 7COM1025 and where does it sit?

Direct answer: 7COM1025 Programming for Software Engineers is a Level 7 module at the University of Hertfordshire worth 30 credits, taught in Semester B. It is a core module on the MSc Software Engineering programme, and appears as an optional module on MSc Advanced Computer Science. At 30 credits it carries a quarter of the taught year, which is a useful signal of how much independent work is expected behind each artefact you hand in.

Evidence: These details come from the programme specifications the university publishes openly alongside its course pages, which tabulate each module by code, title, credit value, semester and core-or-optional status. The distinction matters practically: on MSc Software Engineering you cannot avoid this module, so it sits in the same year as Measures and Models for Software Engineering and Software Engineering Practice and Experience, and the three are designed to reinforce each other.

Example: At a first session, one student was convinced he was behind because classmates were discussing measurement and metrics he had not covered. He was not behind. He had assumed the modules ran independently, when the programme structure places them in the same semester precisely so that the vocabulary of one shows up in the assessment of another.

Note the source problem before you start searching. Hertfordshire keeps its Definitive Module Documents behind a student login, so a large share of what circulates publicly under this module code has been reposted by sites that sell coursework, often for an academic year that has already passed. Your own module handbook on Canvas is the only authority on this year's task, weighting and word count.

Why does postgraduate programming get marked differently?

Direct answer: Because the assessed object is not the program. It is your reasoning about the program, evidenced through the program. A Level 7 marker reads your code as a record of decisions, and the mark tracks how well those decisions are justified, tested and evaluated, not how quickly the software reached a working state.

Evidence: The programme learning outcomes this module is mapped against make the shift explicit. They include producing models of software engineering processes and artefacts using appropriate modelling techniques, applying measures to those processes and artefacts and using the resulting data to evaluate the work, and critically evaluating professional, social, legal and ethical issues in contemporary practice. Every one of those verbs, model, measure, evaluate, sits above implement. The UK Quality Assurance Agency describes master's-level work in the same register, expecting originality in applying knowledge and a critical awareness of current problems at the forefront of the discipline (QAA, 2024).

Example: Two students submitted functionally identical solutions. One presented the code with a short note saying it met the requirements. The other included a short design rationale: two alternative structures considered, the trade-off between them stated in terms of coupling and testability, the one chosen and why, and a paragraph acknowledging where the choice would age badly under a plausible change of requirement. The gap between their marks was not a gap in programming skill.

What does the marker look for that students leave out?

Direct answer: Four things, and they go missing in a predictable order. Justification of design choices disappears first, evaluation against evidence second, testing as argument third, and reflection on limitations last of all.

What is assessed	What a weak submission shows	What moves it up a band
Design justification	One solution, presented as the obvious one	Alternatives named, trade-offs stated in engineering terms, choice defended
Use of measurement	Assertions that the code is efficient or maintainable	Complexity, coverage or timing data reported, then interpreted
Testing	Tests that confirm the happy path	Tests that target boundaries and failure modes, with a stated selection rationale
Critical evaluation	A closing sentence saying the program works well	Named limitations, the conditions under which the design fails, what you would change
Literature and standards	No reference to anything outside the code	Established design principles and empirical work cited where they inform a decision

Evidence: This is not a local marking preference. Parnas (1972) set out the criterion that modules should be decomposed around hidden design decisions rather than around processing steps, which is why "I split it into functions" is a weaker answer than "I isolated the decisions most likely to change." Martin (2017) reframes the same principle for contemporary practice through dependency direction and boundaries. On the testing side, empirical work has repeatedly found that coverage alone is a poor proxy for fault detection (Inozemtseva & Holmes, 2014), which is exactly why reporting a coverage percentage without interpreting it earns little credit.

Example: A student reported ninety-four per cent test coverage in her documentation and expected it to speak for itself. Asked which of her tests would fail if she inverted a single boundary condition, she found that none would. The number was accurate and the argument behind it was empty. Rewriting six tests to target boundaries dropped her coverage slightly and strengthened the submission considerably.

How should the written component be structured?

Direct answer: Treat the report as an engineering argument in which the code is the evidence, and give proportionate space to the parts that carry marks. A structure that holds at Level 7: problem framing and requirements interpretation, roughly 15% of the words; design rationale with alternatives and trade-offs, roughly 30%; implementation notes covering only what the code cannot say for itself, roughly 15%; verification, meaning testing strategy and measurement with results interpreted, roughly 25%; and critical evaluation with limitations and future work, roughly 15%.

Most submissions invert this. Implementation swells to half the document because it is the easiest section to write, and the design rationale and evaluation are compressed into a page each. The two compressed sections are where the highest-value criteria live.

Evidence: The assessment strategy published for the programme states that intellectual and practical skills are assessed through in-course assignments and the project, and that knowledge must be shown to be applied in the context of substantial independent work. Applied, in that sentence, is doing the work. A description of what your code does is not an application of knowledge; a defence of why it does it that way is.

Example: One draft ran to fourteen pages, eight of which walked through the code class by class. Its author had assumed thoroughness was the virtue being tested. Cutting those eight pages to two, and spending the reclaimed space on why the persistence layer had been separated and what would break if it had not been, produced a shorter report and a substantially better one.

What about AI coding assistants?

Direct answer: Follow your own programme's stated position and your module handbook, and be aware that the risk on this module is academic before it is disciplinary. Code generated without understanding cannot be defended, and this module assesses defence.

Evidence: The module contributes to a programme outcome on critically evaluating professional, social, legal and ethical issues in contemporary computing practice, so the question of tool use is inside the syllabus rather than merely adjacent to it. Empirical work on assistant-generated code has found meaningful rates of insecure or incorrect output that developers nonetheless accepted (Perry et al., 2023), which is precisely the failure mode a Level 7 marker probes when they ask why a particular construct is there.

Example: Asked why his solution used a particular concurrency primitive, one student had no answer. He had not chosen it; a tool had, and it had worked, so he had moved on. Reconstructing the reasoning took him an afternoon and changed his implementation, because the primitive was defensible for one of his two use cases and wrong for the other.

How do international students on this module lose marks unnecessarily?

Direct answer: Through the written argument rather than the programming. Students arriving from Vietnamese undergraduate computing programmes are frequently strong implementers and are then assessed, for the first time, on a genre of technical writing they have never been taught: the hedged, evidenced, self-critical engineering report.

Evidence: The programme's transferable skill outcomes include expressing yourself coherently in writing and orally, and explaining, justifying and defending your work both in detail and in a broader context. Those are assessed skills in their own right, not presentation polish added at the end.

Example: One submission stated that its design "is the best solution for this problem." Pressed on what evidence would be needed to support a claim that strong, he revised it to state that the design was preferable under the stated constraints, weaker if the data volume grew by an order of magnitude, and untested against concurrent writes. The second version is more modest and marks higher, because a marker can see the boundary of the claim.

What do MAAS mentors actually do on this module?

MAAS works as an academic advisor. A mentor reads your draft and your design rationale against the module's learning outcomes, asks the questions a marker would ask about a decision you have taken for granted, and shows you where an argument stops at description. You write and submit your own code and your own report. On a module like this one, the sequence usually runs from clarifying what the brief is actually assessing, to reviewing your design rationale before you build too far on it, to a structural read of the full report with the criteria alongside. Referencing and academic-integrity questions are handled inside that read rather than as a separate service.

Frequently asked questions

Is 7COM1025 compulsory?
It depends on your programme. The published programme specifications list it as a core Semester B module on MSc Software Engineering and as an optional module on MSc Advanced Computer Science. Confirm the status on your own programme and year, since option lists change.

How many credits is it worth?
Thirty credits at Level 7, which is a quarter of the taught year on a standard full-time master's structure.

Which programming language does it use?
Your module handbook is the authority, and it may differ by cohort. Treat any language named on a third-party site as unverified, and note that the assessed skills of design justification, testing strategy and critical evaluation transfer across languages regardless.

Do I need professional experience to do well?
No. Experienced developers often start ahead on implementation and behind on justification, because industry rewards shipping and this module rewards defending. Both groups converge on the same gap.

How much of the mark is the code itself?
Weightings are set in your handbook, but the framing question is more useful than the percentage: on almost every task in this module the code is evidence for an argument, and a submission that supplies evidence without the argument has left marks on the table.

Should I cite academic literature in a programming assignment?
Yes, where it informs a decision. Citing a design principle or an empirical study to justify a structural choice is exactly the move that separates a Level 7 report from an undergraduate one.

Talk to a MAAS mentor about your module

References

Inozemtseva, L., & Holmes, R. (2014). Coverage is not strongly correlated with test suite effectiveness. In Proceedings of the 36th International Conference on Software Engineering (pp. 435–445). ACM. https://doi.org/10.1145/2568225.2568271

Martin, R. C. (2017). Clean architecture: A craftsman's guide to software structure and design. Prentice Hall.

Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. Communications of the ACM, 15(12), 1053–1058. https://doi.org/10.1145/361598.361623

Perry, N., Srivastava, M., Kumar, D., & Boneh, D. (2023). Do users write more insecure code with AI assistants? In Proceedings of the 2023 ACM SIGSAC Conference on Computer and Communications Security (pp. 2785–2799). ACM. https://doi.org/10.1145/3576915.3623157

Quality Assurance Agency for Higher Education. (2024). The frameworks for higher education qualifications of UK degree-awarding bodies. QAA.

Sommerville, I. (2016). Software engineering (10th ed.). Pearson.