Five Types of Creative Debugging


Debugging experience is an important part of learning how to diagnose and fix problems in software. Learning to debug can be helpful to more than just aspiring software engineers since it usually involves an empirical approach to problem solving. Yet the notion of debugging as empirical problem solving does not fully account for programming experiences which are personally expressive and artistically creative. In this ethnographic study among Scratch communities, I draw attention to five types of creative debugging, only one of which can be explained by engineering-focused models: fixing bugs, finding cheats, making glitches, reaching coherence, and designing by feel.


Across this study, Scratch users demonstrated a wide range of creative responses to bugs. Some students did fix their projects in respect to an established goal. Much of what I observed cannot be easily accounted by this narrow view of debugging. In addition to fixing things, students were finding cheats, making glitches, trying to reach coherence, and designing by feel.

Further ethnography and theory on creative debugging may broaden notions of debugging yet more. Future work should include greater correlation to certain kinds of settings, ages, genders, or learning styles. Discourse analysis of projects and comments on the Scratch website could also yield insights about feedback and debugging. The practices and language surrounding "glitches" are an especially promising area of research.

Although we should not make too much of the overlap in terms, "glitch art" is an artistic genre which closely resembles the \x93spazzing\x94 \x93glitches\x94 of Scratch Club. According to Rosa Menkman, glitch art responds to computational accidents with an informed critique on the notion of process. She explains that "glitch artists make use of the accident to \'disfigure\' flow, image and information," to "break from procedural flow" (Menkman, 33-4). Perhaps creative play with glitches is a special opportunity to explore powerful ideas about the nature of process and its limits.

After these initial encounters with two Scratch communities, I now think the notions of debugging held by software engineers are too narrowly defined. Debugging can be a powerful strategy for diagnosing and fixing something which is broken. Yet the learners at Scratch Club and Animation Class applied a broader set of creative responses to bugs than just fixing things. Further research in this area may reveal an even richer range of debugging creativity.