A Child's View of Debugging

This summer, a friend of mine asked me if my eight year old son would be interested in a Summer Robotics Club. Completely thinking of my son (wink wink), I agreed.

The group meets about every other weekend over the summer covering various topics such as basic theory of atoms, introductory programming and of course, assembling a robot from a kit.

It was my job to do several sessions on introductory programming skills. We used a program called Alice, a free tool for learning programming skills by building 3D animations and even some simple games.

The first session was to go through a tutorial of the User Interface and modify a simple pre-made animation. The second session was troubleshooting a 'broken' animation.

The 'broken' animation showed a top view of an airport, with a single car in the parking lot. The car attempts to drive around the airport, but it goes through the building at one point. It also goes 'too fast' at other times.

Here is one solution by one team of kids. Note that these two were nine years old.

Here are some observations from this solution. They were time-limited, and didn't quite finish.

- The car ends up going off the screen at a couple points
- The car speed issue wasn't addressed
- In the original animation, the car ended up at the exact same spot it started from. In each solution, including this one, the car ended up in a different location (even if just slightly).
- etc.

Overall, I saw some very familiar themes in the whole process. See if any of these sound familiar.

Kids
The car ends up going off the screen at a couple points
Adults
Some attempts at repair cause other issues, even if the attempts don't have any impact on the issue being solved.

Kids
The car speed issue wasn't addressed
Adults
Some bugs will never get fixed.

Kids
In the original animation, the car ended up at the exact same spot it started from. In each solution, including this one, the car ended up in a different location (even if just slightly).
Adults
Sometimes, we break existing functionality when we fix issues. Functionality that isn't listed as a requirement is the most succeptible.

Kids
Note the pause at the end of the video, followed by a short drive forward. This was an attempt to get the car closer to the original location.
Adults
Not all solutions are elegant. It may get the job done, but it could be done more easily.

Kids
Is this close enough?" was a question I got in regards to getting the car back to it's starting point.
Adults
While it may be possible to get an 'exact' solution, 'good enough' may be all that is done.

Kids
"Just a minute! I'm almost done!" was a protest I heard when I told them we needed to move on.
Adults
Debugging is difficult to estimate.
Everyone wants to do a good job and finish the task given.

Kids
In the beginning, changes were being made to the wrong part of the code. There wasn't a clear understanding of where the actual issue was. When a change was made to the wrong part of the code and the animation didn't change as they expected, they blamed the computer for not working right.
Adults
Sometimes we get stumped by a problem. We think we are doing the right thing, but we don't see any progress.

Overall, we had a great time. We still have more sessoins left, so there may be more stories.