Most students arriving at INFO5990 have spent years in units with a marking key. The code compiles or it does not, the query returns the right rows or it does not, the proof closes or it does not. This unit removes that safety net.
Most students arriving at INFO5990 have spent years in units with a marking key. The code compiles or it does not, the query returns the right rows or it does not, the proof closes or it does not. This unit removes that safety net. Its published outcomes ask you to analyse ethical dilemmas, evaluate the impact of information technology across industries, and construct effective written and oral communication for IT practitioners. None of those has a correct answer waiting at the back of the book, and students who keep hunting for one tend to hand in work that is technically unobjectionable and lightly marked.
Author: MAAS Editorial Team · Reviewed by a MAAS subject mentor
Last updated: 2026-08-18
Category: writing-tips
What the unit is, and who is sitting next to you
Direct answer: INFO5990 Professional Practice in IT is a 6-credit-point postgraduate unit at the University of Sydney, taught by the School of Computer Science within the Faculty of Engineering, with no prerequisites and no corequisites.
Evidence: Sydney's entry for the unit describes it as introducing concepts, standards and techniques associated with current professional practice in information technology in the business environment. It records prohibitions against INFO1111 and OINF5990, lists Semester 1 and Semester 2 offerings for 2026 in normal evening attendance at Camperdown and Darlington, and states assumed knowledge as a bachelor's degree in some area of IT, a completed graduate diploma, or many years of experience as a practising IT professional.
That assumed-knowledge line is the most important sentence on the page, and it is easy to skim past. The unit assumes you already know how IT works and spends the semester on everything around it. It is not a technical unit with a professional flavour. It is a professional-judgment unit that happens to sit inside an IT degree.
The evening delivery tells you something else. A meaningful share of the room is working in the industry during the day and will bring lived examples to seminar discussion. If you are a full-time international student without local work experience, you are not disadvantaged on knowledge, but you are competing on illustration. That gap is closable through reading and case preparation, and it is worth closing deliberately rather than hoping it does not show.
Before you search for anything: the INFO prefix is among the most reused code families in higher education, attached to informatics, library science and information systems units at institutions on several continents. Sydney itself runs INFO5301, INFO5995 and the online twin OINF5990. Search the unit title rather than the bare code, or most of what you find will belong to a different degree.
If there is no right answer, what is being marked?
Direct answer: The quality of your reasoning under conditions where reasonable professionals disagree, and your ability to make that reasoning legible to a non-specialist reader.
This is the single largest adjustment for students coming from programming and systems units, and it explains most of the disappointing grades on a unit like this one. A technically strong student writes a conclusion and treats the working as scaffolding to be removed. Here the working is the assessed object. A recommendation with no visible path from evidence to judgment is unmarkable no matter how sensible it turns out to be.
| What a technical unit rewards | What INFO5990 rewards |
|---|---|
| The correct answer | A defensible position with its reasoning exposed |
| Efficiency of solution | Awareness of who bears the cost of the solution |
| Handling the specified case | Naming what the specification left out |
| Confidence in the conclusion | Calibrated confidence, with limits stated |
| Precision of technical language | Clarity for a reader who is not a specialist |
Evidence: Toulmin (2003) supplies the structure that examiners are effectively looking for even when they do not name it. An argument needs a claim, the data supporting it, a warrant that explains why that data licenses that claim, and a qualifier that marks how strongly it holds. Most weak submissions on professional-practice units carry claim and data but omit the warrant, which is exactly the part that shows judgment rather than retrieval.
Example: Asked whether a firm should migrate a legacy payroll system to a cloud provider, one answer set out the cost saving, the scalability gain and a recommendation to migrate. A stronger answer reached the same recommendation, then stated the warrant that made it hold, namely that payroll load is predictable and the firm's constraint is capital expenditure rather than data residency, and added the condition under which the recommendation reverses. The recommendation never changed. What changed was that the second version showed its working, which is the thing the outcome list actually asks for.
Why do ethics answers fall flat?
Direct answer: Because students identify the ethical issue, name a framework, and stop, when the outcome asks them to analyse and resolve a dilemma.
A dilemma is a situation where every available option costs something that matters. If your answer arrives at a course of action with no residual harm to acknowledge, you have almost certainly reframed the dilemma into a compliance question and answered that instead. Recognising a problem is the entry ticket, not the performance.
Evidence: Moor (1985) argued that computing generates genuinely new ethical situations rather than merely new instances of old ones, because the technology creates capabilities for which no policy yet exists. He called these policy vacuums, and the work of computer ethics is filling them under conceptual uncertainty. That framing matters for your marks: an answer that reaches for an existing rule and applies it mechanically has missed the case where no adequate rule exists, and those are precisely the cases set as assessment.
Evidence: The Software Engineering Code of Ethics (Gotterbarn et al., 1999) is useful here for a reason students often miss. It is organised around obligations to distinct parties including the public, the client, the employer, the profession and colleagues, with the public interest set as paramount when those obligations pull against each other. Its value in an assignment is as a map of who has a stake, not as an authority to cite and move past.
Where the marks actually sit: in the part after the decision. Name the option you rejected, say what was lost by rejecting it, and state what would have to change for you to choose differently. Three sentences of that work do more for a grade than another paragraph restating the facts of the scenario.
Example: Given a case in which a project team discovers a defect late and shipping on schedule would expose a small number of users to data loss, weak answers concluded that the team must disclose because honesty is a professional duty. A well-marked answer reached the same conclusion, then addressed what disclosure costs the client commercially, why that cost does not outweigh the exposure, and which threshold of severity would make the balance genuinely contested rather than obvious.
The research outcome that students read as decoration
Direct answer: LO6 asks you to apply investigative research methods, models and tools to IT professional practice, which makes this partly a research-methods unit, and it is usually the least prepared-for outcome in the list.
Students see the research language, assume it means find some sources, and then submit assignments whose evidence base is vendor marketing material and consultancy blog posts. The reasoning may be sound and the evidence layer collapses under any scrutiny, which caps the mark regardless.
The distinction that matters is between a source that reports evidence and a source that reports a conclusion. A vendor white paper claiming a ninety per cent efficiency gain is a claim about a claim. A peer-reviewed study that describes its method, sample and limitations is evidence you can weigh. You are permitted to cite industry material, and in a professional-practice unit you often should, but you must handle it as an interested party's testimony rather than as a finding.
Evidence: Flyvbjerg and Budzier (2011) is a useful model of the standard because it is both industry-relevant and methodologically explicit. Their analysis of 1,471 IT projects reported an average cost overrun of twenty-seven per cent, while roughly one project in six ran to about a two hundred per cent overrun, which is a materially different picture from an average alone. The figures come from a Harvard Business Review article that sits behind a paywall, so if you intend to cite them, find the authors' own open version rather than quoting them from a secondary summary. The transferable lesson is not the number. It is that a distribution tells you something an average conceals, and an answer that quotes the mean without the tail has under-read its own source.
A test before you cite anything: can you state who collected the data, from whom, and what would have made the finding come out differently? If not, you are citing an assertion, and you should either find the underlying study or lower the strength of your claim to match the evidence you actually have.
How to prepare for the communication outcome
Direct answer: Write for a competent reader who does not share your specialism, because that is what LO5 describes and what practitioners are actually paid to do.
The failure mode is not bad grammar. It is unexamined jargon, where a term does real work in the sentence and the reader cannot evaluate the argument without already knowing what it means. In professional practice the audience for your recommendation is frequently a finance director or a clinical lead, and a recommendation they cannot assess is a recommendation they will not act on.
Three habits carry most of the improvement. Put the recommendation in the first paragraph rather than building to it, because business readers read the top and skim the rest. Define a technical term at first use in one clause without a digression. State uncertainty in plain terms, since "we do not have data on peak load" is more professional and more useful than a confident number nobody measured.
Evidence: Brooks (1987) remains on reading lists for professional-practice units four decades after publication because of the distinction he drew between essential and accidental complexity. The essential complexity of a system lies in the problem it models, and no tool removes it. That distinction is directly usable in your writing: it gives you a principled reason for which details a non-specialist reader needs, namely the ones belonging to the essential complexity of the decision, and which are implementation detail you can compress.
Preparing across the semester
Case-based units punish the pattern of starting an assignment the week it is due, because your stock of illustrations is the constraint rather than your writing speed. A student who has been collecting examples all semester writes a grounded answer in a few evenings. A student starting cold spends most of the available time searching for something concrete to say.
The cheap version of this discipline is a note after each seminar, written the same evening while the discussion is still sharp: what the situation was, what was genuinely at stake, who ended up bearing the cost. Do that consistently and by the time assessments arrive you are selecting from material you already understand rather than searching for something to say. The secondary benefit matters almost as much. Cases you collected yourself are not the cases the rest of the cohort will find on the first page of search results.
Prohibitions matter here too. The unit page lists INFO1111 and OINF5990 as prohibited. At Sydney the O prefix marks an online delivery of a unit, which is what the pairing suggests here, though the page states the prohibition without explaining it. Confirm on the page for your own year before enrolling, since these lists are reviewed between years.
What a second reader is actually for on this unit
The hardest thing about a judgment unit is that you cannot mark your own reasoning. Once you have written an argument you can no longer see the step you skipped, because in your head the step is still there. That is the specific gap a MAAS mentor fills, and it is why the sessions look less like teaching and more like interrogation.
The question that does the most work is simply: why does that evidence license that conclusion? If the honest answer is that it is obvious, the warrant is missing from the page even though it exists in your head. From there a mentor will want to know which option you rejected and what rejecting it cost, whether a source you leaned on reports evidence or only somebody's conclusion, and what a reader outside IT would make of the paragraph you thought was clear.
The positions stay yours. So does the writing. What changes is that the argument has already survived one competent objection before an examiner sees it.
Frequently asked questions
Whose unit is this?
The University of Sydney, where INFO5990 is Professional Practice in IT, a 6-credit-point postgraduate unit taught by the School of Computer Science within the Faculty of Engineering.
Do I need prior study to enrol?
The unit page lists no prerequisites and no corequisites, but it does state assumed knowledge of a bachelor's degree in an area of IT, a completed graduate diploma, or substantial professional experience. Assumed knowledge is not enforced at enrolment, so the responsibility for the gap sits with you.
Can I count this alongside a similar unit?
The published prohibitions are INFO1111 and OINF5990. Holding credit in either blocks enrolment here. Verify on the page for your own year.
When and how is it taught?
The unit page shows Semester 1 and Semester 2 offerings for 2026 in normal evening attendance at Camperdown and Darlington. Delivery patterns change between years, so confirm before you plan around it.
Is this an easy unit because it has no coding?
Removing code does not remove difficulty, it changes where the difficulty sits. Marks here depend on argument quality, evidence handling and clarity for a general reader, which are skills many technically strong students have had little practice in and consequently underprepare for.
How technical should my examples be?
Technical enough to be specific and framed so a non-specialist can follow why they matter. LO5 asks for communication appropriate to IT practitioners working in a business environment, which means the technical substance stays and the presentation adapts to the audience.
Related reading
- INFO5995: introduction to cybersecurity
- INFO5301: information security management
- How to write a university essay
Ask a MAAS mentor about your unit
References
Brooks, F. P. (1987). No silver bullet: Essence and accidents of software engineering. Computer, 20(4), 10–19. https://doi.org/10.1109/MC.1987.1663532
Flyvbjerg, B., & Budzier, A. (2011). Why your IT project may be riskier than you think. Harvard Business Review, 89(9), 23–25.
Gotterbarn, D., Miller, K., & Rogerson, S. (1999). Software engineering code of ethics is approved. Communications of the ACM, 42(10), 102–107. https://doi.org/10.1145/317665.317682
Moor, J. H. (1985). What is computer ethics? Metaphilosophy, 16(4), 266–275. https://doi.org/10.1111/j.1467-9973.1985.tb00173.x
Toulmin, S. E. (2003). The uses of argument (Updated ed.). Cambridge University Press.