Sabotage: Teach Debugging By Stealth

The majority of my work at the moment is supporting ICT teachers who want to introduce and develop Computing within their own curriculum ahead of the changes planned for September 2014. Throughout my work with other teachers, I’ve been sharing some of the pedagogic devices and strategies I’ve been using with the aim of ensuring that their teaching of Computing is engaging and inspiring.

One such game that I’ve developed with my classes I call ‘Sabotage’. I’ve discovered that this can be used in a whole variety of ways, but to help you develop an understanding of it I will attempt to describe just one simple example for you.

The Problem:

I found when I first moved from teaching Scratch (a visual programming language) to Python (a text-based programming language) that children became very frustrated with the high numbers of syntax errors which prevented their scripts from working. This created negative associations with text-based programming as there was a much higher failure rate compared to Scratch. I discovered that children very easily gave up at the first hurdle and resorted to either giving up completely or put their hand up and sat there waiting for me to attend to them like a repair man and fix their problem for them. If I did help them, this became counter-productive as others then realised that if they too got stuck, they could put their hand up and wait for roadside assistance to arrive. Very soon, this behaviour spread like a contagion around my classroom with a crop of raised hands and frustrated faces. I knew that this was unsustainable.

Developing A Solution:

I then tried various responses when children started putting their hands-up for help, e.g. “No, sorry I’m not helping anyone at the moment, it’s a challenge that you have to fix”, “Why are you telling me it doesn’t work? Fix it and then put your hand up to show me and we’ll celebrate your achievement”, “How did you try to get assistance before you put your hand up?”. However, these did not necessarily encourage the children to independently problem solve, in some cases I’m sure it just made the children despise me all the more.

The Solution:

So, now we have progressed to playing Sabotage. The result is that children are no less prone to discovering bugs in their code, but they are far better at debugging and correcting errors.

1. Everybody starts with a script that definitely works, e.g. an example from a book or their own coded solutions to a problem. Let’s use the Guess The Number game here.

2. We then test the game, play the game etc. just to make sure that we know it definitely works. Sometimes this step is not necessary.

3. The teacher then asks everyone in the class to think of examples of syntax errors that might prevent the game from working properly. They then share as many of these as they can with their partner in just one minute. Then forming a group of 4 they see if they can get any more examples.

4. The teacher then compiles a list of generic examples by asking each group to suggest one typical error.

5. The teacher then explains to the class that they are going to deliberately sabotage the working code by hiding 5 errors in there. They don’t have to 5 different types, but there must be 5 errors in total, no more, no less. I suggest that one should be pretty obvious and one should be very sneaky, e.g. using the character zero instead of the letter ‘o’.

6. Then the teacher asks the pupils to swap with their partner and then take it in turns to debug the errors. The debugger should be coached by the saboteur, as the aim is for the saboteur to tie hints and clues that eventually enable the debugger to spot all 5 errors. They then swap over.

7. Finally ask for feedback. Who scored 5 out of 5? Who put really sneaky errors in? What were they? Who gets the prize for being the most helpful? Who gets the prize for being the most devious?

The Result:

Not only does this help children spot errors in their own code more readily, but it also encourages them to consider using their peers for assistance more frequently. The most noticeable difference was the experience of enjoyment and engagement as they first deviously hid errors in their own code and then rejoiced as they found errors in their partner’s.

I used this in one of my observed lessons and it was graded as “outstanding’. However, if you are planning to use it in a lesson observation yourself, I would strongly advise you to try it with some classes beforehand for you to own this technique and develop the use of it your own lessons. There are lots more suggestions and varieties I can suggest, but I wanted to share this in it’s most simple form to begin with for others to adopt.

And of course… Don’t just take my word for it, try it with one of your classes at the next available opportunity and judge for yourself. If you have any thoughts, comments or recommendations please make a comment below at the bottom and answer the poll just here.