Hasty design, futile patching and the elaboration of rigor

Abstract

Two wrongs don't make a right." In the last two years, we observed repeated hasty designs, followed by futile patching of programming solutions, which yielded (and re-yielded) erroneous outcomes. In this paper, we illuminate and illustrate diverse characteristics of these undesired design and patching phenomena, and offer a didactic approach of using them for elaborating students' awareness of rigor. We advocate such an elaboration in textbooks and teaching materials, as one may learn and benefit from the wrong way no less than the right one.

Abstraction, Declarative Observations and Algorithmic Problem Solving

“…Some noticed the latter, and offered erroneous patches. In a sense, they turned to "pseudo that" observations, that were unsound (Ginat, 2007). One of these students (P16) justified her rationale with unfounded arguments.…”

Time Travel Gamification of Learning and Training: From Theoretical Concepts to Practical Applications

“…Traveling back in time allows for patching the past. Patching may be considered insufficient due to its potential renunciation of a global understanding [63]. This is an issue of bounded rationality separating "the beliefs that people have and the choices they make from the optimal beliefs and choices" (see [64], p. 449).…”

Proceedings of the 7th Computer Science Education Research Conference

“…That is, stage 2 novices trace their buggy code with specific values, and then make what is often a myopic patch. That patch may "fix" the code for the specific initial values just used in the trace, but the patch may not address the general bug [9]. The strategy of "repeat-trace-patch-untilsuccess" is like "shotgun debugging", which Wikipedia defines as, "A process of making relatively un-directed changes to software in the hope that a bug will be perturbed out of existence".…”