Goal: Help students identify problematic assumptions that cause code crashes.

It’s common to say programmers provide instructions to computers — a more accurate statement would be that programmers provide a workflow. While instructions typically are step by step and always follow the same order, a workflow can take you along different paths depending on the situation. Think back to the toaster and waffles exercise. The participants might have given these seemingly perfect instructions: put the waffles in the toaster, push the slider down, wait, and then take out the toast. But this doesn’t cover us if the toaster isn’t plugged in.

Programming is a constant back and forth between checking something and doing something. Check if the toaster is plugged in. If it isn’t, plug it in. Put the Eggo in, and press the slider. Wait — but don’t just wait, wait and check if it’s warming, if it’s popped up, and so on.

In Software Engineering, we call this need to check something a condition. A lot of programming toys and kid-focused coding tools overlook the importance of conditions. They’re very easy to learn and very important to not skip.

Exercise 1: Conditions

This is a simple exercise that involves the whole group. I start by telling the class that they are the computer, and I’m going to hand out the program instructions to them. I tell them the goal (usually, I have them all stand up, and the goal is to get everyone to sit down). I then hand out a set of cards I’ve created specifically for this exercise.

Each card has a condition — if the condition passes, you take one action, if the condition fails, you take a different action. Once the cards are handed out, I “start” the program by selecting a student and giving them a stuffed animal “mouse.” The mouse helps us track whose turn it is. (I’ve included these files as an attachment at the bottom of this article.)

The student with the mouse then reads out their card. Here’s an example:

Discussion:

As the exercise goes on, have students look out for any problematic assumptions in the cards. For example, some of the cards state: “If your dog’s name is….” which presumes that the student has a dog. When an incorrect assumption exists in programming, this can create what is called an exception. If the program is not made to handle such situations, it will mean the program completely crashes, and you have to start from the beginning. Rather than restart the program, challenge them on how this condition can be fixed. Because the cards are in limited supply, students may sometimes get the same card again. While it’s not directly related to this exercise, help them strategize on how to get everyone seated by having them be selective on how many spots to move the mouse so it doesn’t keep landing on the same person. If you’re using the cards I created, you may also find yourself in an infinite loop where the program can’t end. That’s by design! Have the students evaluate and fix the bug so that the program can properly end. At the end, ask them about their own experience with programs or mobile phone apps. Have they ever seen one crash or sit there in a loop? They’re now equipped to explain why — it’s either through incorrect assumptions the programmer made, or because they made a mistake that caused the application to loop. As a fun fact, be sure to mention how Apple’s original headquarters was addressed: “1 Infinite Loop”

Exercise 2: (Re)Diagramming Concepts

Have the students redo the toaster exercise from the last article (either independently or in pairs) but now thinking about assumptions, conditions, and exceptions. How would they improve their instructions? Are there any risks of creating a loop?