To make a minimal reproducible example, copy the program, cut away everything that is not needed, and keep the wrong result. Write down what you expected and what you got. When you can fit the problem into five lines, the cause is usually visible.
This is one of the most useful debugging habits because it replaces guessing with testing. It also works for the trace-and-explain questions in Computer Science, where you must say what a piece of code does.
Why does a bug hide in a long program?
A longer program gives the bug more places to hide and gives you more reasons to doubt the wrong line. You tend to trust the code you wrote most carefully, which is often where the slip is.
Shrinking removes the crowd. What is left has nowhere to hide.
How to shrink a program
- State the expected and actual result in one line each.
- Copy the program so you cannot damage the original.
- Replace real input with a tiny made-up input that still fails.
- Delete one part at a time and rerun after each cut.
- If the wrong result disappears, undo that cut. The part you removed mattered.
- Stop when any further cut changes the result. Explain the cause in one sentence.
Worked example
Original program, where the teacher’s pass mark is 50 and a mark of exactly 50 is a pass:
names = ["Aiman", "Bee Ling", "Chandran", "Dina"]
marks = [72, 50, 38, 65]
pass_mark = 50
passed = 0
total = 0
for i in range(len(marks)):
total = total + marks[i]
if marks[i] > pass_mark:
passed = passed + 1
average = total / len(marks)
print("Average:", average)
print("Passed:", passed)Expected: 3 passed (72, 50 and 65). Actual: 2. The average, 225 ÷ 4 = 56.25, is correct, so the average code is not the problem.
Cut the names list, the total and the average. The count of passes still comes out wrong. Replace the four marks with one, 50.
marks = [50]
passed = 0
for m in marks:
if m > 50:
passed = passed + 1
print(passed)Expected: 1. Actual: 0. Five lines remain, and only one of them can be blamed: m > 50 excludes a mark of exactly 50, but the brief says 50 passes.
The mistake to watch for
A student deletes lines at random until the wrong answer stops, then decides the last deleted line was the bug. But they also deleted the mark of 50 from the list, and that is what made the problem vanish.
The correction: after every cut, rerun and check that you still get the same wrong result. If it changes, undo the cut. A reproducible example must fail in the same way as the original.
Check yourself
1. Why write the expected result before shrinking?
Show answer
Without it you cannot tell whether a cut has kept the bug. You need a fixed target to compare each rerun with.
2. After deleting a loop, the program prints 1 instead of the earlier wrong 0. What should you do?
Show answer
Undo that cut. The wrong result changed, so the loop was part of the problem.
3. A program counts how many scores in a list of 50 are at least 60, and gives a wrong count. Give two shrinking steps.
Show answer
Use a list of two or three scores, including one exactly 60. Then remove any printing or extra calculations that do not affect the count.
Where this leads next
The habit links to repairing an off-by-one error and to explaining an expected result before running code. Next, turn the bug into a test with designing a boundary test before editing code. You can practise on your own small exercises in the safe Python reasoning sandbox.
If you can shrink the bug but still struggle to explain it, one-to-one Computer Science tuition lets a teacher trace the small example with you. The Computer Science learning guide shows where debugging sits in the syllabus.