Debugging—identifying and fixing errors in computing programs—is an essential skill for all programmers, yet it is one of the most challenging aspects to teach. Secondary classrooms can be a tough environment to learn to debug, where there may be lots of students demanding the teacher’s help. This blog introduces PRIMMDebug, a new teaching process for text-based debugging, which we are currently testing in the classroom. Find out how to get involved in our research below.
Common challenges with learning to debug
Learning to debug in text-based programming languages can be a challenging experience for students for several reasons:
- Learning a text-based programming language hugely expands the scope for errors compared to a block-based language.
- Successful debugging experiences in these languages usually require prior knowledge and experience that beginner programmers don’t have.
- Programming error messages are not always a useful source of feedback and can instead be confusing and intimidating for young learners.
- Many students use strategies that don’t help them resolve errors in their programs, sometimes even adding errors to their programs.
- Consequently, many students ask their teachers for help with debugging their programs. For teachers, this creates a potentially chaotic classroom atmosphere which isn’t useful for teachers nor students.
Introducing PRIMMDebug
To tackle these challenges, we’ve developed PRIMMDebug, a process and a tool designed for teaching text-based debugging to secondary school students. It is an adaptation of the PRIMM framework that is already very popular for teaching text-based programming.
The PRIMMDebug process starts with a PRIMMDebug challenge. This is simply a program containing a common error that students often make at the start of their programming journey. It also includes a description of what the program should do.
To facilitate positive debugging habits, PRIMMDebug guides the learners through the following steps as they try to find and fix the error(s) in the buggy program.
- Students first predict the outcome of the buggy program. To help with this, the PRIMMDebug challenge would ideally contain one or more sets of input values for the program.
- Students then run the program, using the test input values if there are any. For each set of test input values, one cycle of the predict and run stages is completed.
- After running the program one or more times, students need to consider the difference between the actual and intended function of the program. It is useful for students to note down their findings. In doing so, they are spotting the defect.
- Next, students generate hypotheses about what could be wrong with the program. They inspect the code, run it with different input values, reread the description, and rerun the program to give them clues about the error.
- By this point, students should have enough information to find the error. If they’re not sure where exactly the error is, they’ll need to repeat steps 3 and 4 (with appropriate feedback).
- Once they’ve successfully found the error, they then try to fix the error. To help with this process, students’ changes need to be intentional; they should write down (or tell a partner) what they’ve changed and why they think it will work.
- Students test that the program now works as it should. If the PRIMMDebug challenge has some test cases, they can use these. If the program doesn’t work as intended, they’ll need to have another go at steps 3 and 4 (again, with appropriate feedback). At this point, it’s important to emphasise that this repetition is a completely normal part of debugging and nothing to be ashamed of.
- If the program works as intended, students can end the PRIMMDebug challenge or continue with the original modify and make stages of PRIMM if useful.
The PRIMMDebug tool
It’s important that students aren’t just taught a process, but guided through it. One way this is possible is by creating something that enacts the steps of PRIMMDebug, which is what we’ve done.
The PRIMMDebug tool implements the process with some extra features. For example, students cannot edit their programs until they have first hypothesised where they think the error is. The idea of these features is to encourage intentional reflection and changes over the ineffective trial-and-error-type strategies many students resort to. We feel that this kind of tool is missing from secondary computing education.
Our Aims
Through all of this, we want PRIMMDebug to:
- Teach good debugging strategy; the following of a process.
- Help students be successful debuggers, encouraging independent debugging over teacher reliance.
We think this has the potential to improve students’ self-efficacy around solving errors as well as teach them effective debugging strategies.
Be the first to try PRIMMDebug in the classroom
Now that we’ve done some modelling and development, we’re keen to research its usefulness in the classroom.
To do this, we’re running a study between October 2024-February 2025 with secondary school computing teachers, consisting of these three main stages:
- We’ll meet with you (the teacher) to show you PRIMMDebug in more detail and discuss how you might use it in the classroom.
- You (the teacher) use PRIMMDebug in some of your computing lessons.
- Your students complete a short survey about their experiences with PRIMMDebug and you take part in a short interview for the same purpose.
We’re excited to find out about the effect of PRIMMDebug and will share the findings in a follow-up blog post next year.
If you’re a secondary computing teacher interested in trying PRIMMDebug in your lessons, we’d love for you to get involved! Click the button below to participate in our study and help us improve debugging education.
As a teacher, your involvement in the study will probably last around a month, but we want to work around what’s best for you. We’re looking for teachers until mid-November. If you’re interested and reading this beyond then, get in touch with Laurie at lpg28@cam.ac.uk! We’d still love to hear your thoughts.