Debugging as a Thinking Skill: Unplugged Activities

Quick answer: Most students debug by changing something and running it again. That is guessing. The skill is isolating where the behavior first diverges from what you expected, and it can be taught entirely on paper. Trace tables, human robots and halving take about three periods and transfer to any language, including the ones your students will use after you.

Why does "just try something" become a habit?

Because it works often enough. A student changes a number, the output looks better, and the lesson learned is that fiddling pays. Then they hit a program with three interacting faults and fiddling stops working, and they conclude they are not good at this.

The alternative habit has two parts and both are teachable. The first is stating the expectation before running anything: what should the output be, exactly, for this specific input. Students who cannot answer that cannot recognize a wrong answer when they see one. The second is narrowing: finding the earliest point where reality and expectation part company.

Neither of these needs a computer. In fact, a computer gets in the way at the start, because the run button is right there and it costs nothing to press.

What is the trace table activity?

Give students a short algorithm in plain English or pseudocode, six to ten lines, with one deliberate fault. Something like: set total to zero, set count to zero, for each number in the list add it to total, add one to count, at the end divide total by count and report the average. Then a fault: the list is empty for one of the test cases.

The table has one column per variable and one row per step. Students fill it in by hand, line by line, writing the value of every variable after each step. No skipping. The row where the table goes wrong is the fault.

What this teaches, and nothing else does as well, is that a program has a state at every moment and that state is inspectable. Students who have filled in twenty trace table rows by hand understand what a debugger is showing them the first time they see one.

Expect resistance. Filling in the table is boring and slower than reading the code. Say so and do it anyway. Point out that the table found the fault in ninety seconds and reading the code had not found it in five minutes.

How do you run the human robot activity without chaos?

One student is the robot. They follow written instructions literally and do nothing that is not written. The class writes instructions to get them from the door to a chair, or to draw a specific shape on the board.

Three rules keep it useful. The robot may not interpret. If the instruction says "walk forward" with no number of steps, the robot walks until told to stop, including into a wall, at walking pace, safely. The robot may not ask questions. And the class may not shout corrections; they must write a revised instruction.

Run it with a clear task and let it fail. The failure is the content. Then ask the debugging question rather than the fixing question: which instruction was the first one that did not do what you intended. Students want to jump to the last one, because that is where the visible mess is. The fault is almost always earlier.

Add a second robot for the extension. Two robots following the same instruction list produce different results if the instructions depend on unstated starting conditions, which is how students meet the idea that a bug can be conditional on state they did not think about.

How do you teach halving?

Take a twenty-step procedure with one fault. Do not trace from the top. Check the state at step ten. If it is correct, the fault is in steps eleven to twenty. If it is wrong, the fault is in one to ten. Then check the midpoint of that half.

Twenty steps takes at most five checks. Tracing from the top takes up to twenty. Write both numbers on the board, because the argument for the method is arithmetic, not opinion.

A neat unplugged version: hide a marked card in a sorted deck of thirty-two and have students find it by halving. Five guesses maximum. Students who race each other on this get the idea faster than students who are told about it.

How do you differentiate?

Approaching: four-line algorithms, two variables, and a partly completed trace table where the first two rows are done. The fault should produce a visibly absurd result, such as an average larger than every number in the list.

On level: eight to ten lines, three variables, one fault, blank table. Require them to write the earliest wrong row number as their answer, not the fix.

Above level: two faults, one of which masks the other, so fixing the first makes the output look worse. That is the most realistic thing you can hand them and it produces the best conversations. Follow it with a task where students execute a step-by-step encoding procedure and find the error in someone else's work, which is exactly the structure used in How the Internet Works when packets go astray.

Frequently asked questions

Does this work if my students have never coded?

Yes. Everything here uses plain English procedures. If anything, teaching it before the first programming lesson saves time later.

How do I stop the human robot activity becoming a performance?

Rotate the robot every four instructions and pick quietly rather than asking for volunteers. The students who volunteer are the ones who want an audience.

Should students name the bug types?

Three categories are enough: it will not run, it runs and crashes, it runs and gives the wrong answer. The third is the hard one and the one worth most of your time.

How long is the sequence?

Three periods. Trace tables need a full one on their own, and rushing them wastes the activity.

Related posts

• Binary and Data Representation, Unplugged
• How Artificial Intelligence Works: Grades 6-9 Without Hype
• Building a Math Escape Room From Scratch