1.13: Debugging with Marty Blocks

• Debugging
• Code
• Testing

Warm Up

Introduce a game learners may have played before, but they need to listen to the instructions carefully because they may have changed. Stress that it is important that they follow the rules of the game. You could choose to display the rules on the board but it is recommended that you read them aloud to focus learners' listening skills. If learners start telling you that they know this game, gently remind them that it is important that they listen to the rules, this time.

1. 7 volunteers are needed at the front. (take time to get 7 volunteers)
2. The people who are sitting need to put one hand on the desk with their thumb up.
3. The 7 people at the front need to touch the thumb of a person who is sitting at their desk and then return to the front.
4. The people whose thumbs were touched get to guess who they think touched their thumb.
5. If the guess was correct, they need to swap places.

This will likely not even get past the second or third step, but it might: learners will likely protest. Pretend to look flustered and appear to consult some notes, then have some sort of 'ah-hah' exclamation and say you missed part of the instructions. Read the following list of steps:

1. 7 volunteers are needed at the front.
2. The people who are sitting need to put one hand on the desk with their thumb up.
3. The 7 volunteers at the front need to close their eyes (say, "I missed that step before, sorry" or something like that)
4. The 7 people at the front need to touch the thumb of a person who is sitting at their desk and then return to the front.
5. The people whose thumbs were touched get to guess who they think touched their thumb.
6. If the guess was correct, they need to swap places.

Likely the learners will not agree to this either; in fact, it is hoped they will disagree before you get to the end. Display the list of rules; it is in the resources section in word format, feel free to paste the text into a different program if you are more comfortable editing that on the board.

As learners discuss potential changes to the instructions, inform them, "This process is what people, who work with computers and code, call debugging. The instructions, or code, are written but there is something that isn't quite correct so the program does not perform as expected. The people who debug need to understand what the code is meant to do, like you needed to understand how the game was supposed to work. The 'debuggers' then need to test each of the parts of the code to find the problem, much like you checked each of the steps of the game to see what needed to change so you could play properly.

Keep the updated rules somewhere to access later, perhaps you could play at the end of the cool down section.

Share the presentation and read the objectives, success criteria and story text.

Get Learning

Share some fairly basic examples from MartyBlocks where the code is complete and Marty carries out some actions but they do not go as initially intended. Share with learners what the person who wrote the code had wanted Marty to do. Have learners explore the blocks and work with their groups to see if they think it will work and record their ideas in the workbook. Have learners create the code in MartyBlocks to see if their thoughts were accurate. As a class, find the bugs and fix the code. Have learners build the updated code in MartyBlocks and have them run the code to check.

Time for Practice

For each subsequent block in the workbook, learners need to follow the same process:

1. Explore the code together and see what each part does.
2. Interpret what the goal of the code is.
3. Decide if the code works as intended (one example has no bugs, which learners will discover).
4. Copy the example into MartyBlocks to see how Marty performs.
5. Make small changes to the code and test the result after each change.
6. Repeat until the code works as it should.

Some of the blocks have only one bug, others have more than one, and one has no bugs.

Cool Down

Bring learners back together to discuss the bugs they discovered. Check to see how many bugs learners found in the examples that had more than one mistake. Have learners share challenges they faced and any successes they experienced.

Suggested questions you might ask:

• What steps did you take to decide what the purpose of a program was?
• Did you discover anything that helped you to more easily discover where the bug was, in the code?
• Can you suggest anything that might support other people in identifying what code is supposed to do, in case there are bugs in it?

Carry out any end of lesson routines.

Log off devices and clear everything away.