SLOP4481: Debugging Systems You Did Not Build
A forensic approach to understanding and repairing unfamiliar software. Students investigate systems they did not build, using a fixed six-stage cycle to move from an observed failure to a defensible, verified diagnosis and repair.
You have just been handed a system you did not build. Its author is not in the room. Something in it is failing, the documentation is partial or out of date, and the only way to find out what is actually wrong is to investigate it — read it, run it, question your own assumptions about it, and prove a diagnosis with evidence before you touch anything. That situation, not a topic on a syllabus, is what SLOP4481 teaches.
This is not a tour of debugging tools, and it is not a general software engineering survey organised by technology. Every system you meet here was built by someone else and is already running; nothing in this course asks you to build one from a blank slate. What is graded is the investigation itself.
The cycle
Every exercise runs the same fixed sequence. What changes across the semester is not the sequence, but how much of it is scaffolded for you.
- Observe
- Hypothesise
- Gather Evidence
- Reduce Uncertainty
- Intervene
- Verify
Weeks 1–2 model this cycle closely. From there, scaffolding recedes: evidence sources widen, hypotheses start to compete with each other, and by the final weeks you are running the full cycle, unassisted, on a system you have never seen before.
Who it is for
Students who already write software competently but have found themselves — in an internship, a group project, an open-source contribution — responsible for code they did not write and do not yet understand. No specific language, framework, or tool is assumed; the bar is judgment and code literacy, not familiarity with a particular stack.