Mistake
From Elearning
NB: This is an test pattern only, borrowed from computer science teaching (see references)
Students are asked to create an artifact such as a program or design that contains a specific error. Use of this pattern explicitly teaches students how to recognize and fix errors. We ask the student to explicitly make certain errors and then examine the consequences.
Contents |
PROBLEM/ ISSUE
People make mistakes. Students often don't know how to interpret the error messages provided by their tools or what to do to solve problems that are diagnosed by the tools. Debugging is an essential skill, whether done with a sophisticated debugger, or just by comparing actual outputs with expectations. Students don't initially know what occurs when errors are made and so don't know what to do when they see program diagnostics and incorrect outputs.
AUDIENCE/ CONTEXT
This is very applicable to the early stages of learning programming. Syntax and semantic errors are frequent and students need to become familiar with the messages produced by compilers and run-time systems and what they indicate about the program.
The pattern could also be used in an analysis or design course in which certain specific, but fairly common, errors are required to be part of the design. The instructor can provide a part of the design, which is flawed in some way, and the students are asked to complete the design without changing the instructor's part. (See the Fixer Upper pattern also.)
This pattern is often used in Database and Operating Systems courses where the students are asked to explore the conditions leading to deadlock, by specifically causing it. Similarly, in learning concurrent programming, students are often asked to write programs in which race conditions between processes lead to the corruption of data.
FORCES
Students, like professionals, make errors. Professionals generally know what the indications of an error are, but students do not.
We usually help students avoid errors, but they occur anyway. Students should have a way to explore the effects of errors so that they can recognize them by their effects.
SOLUTION
Ask students to produce an artifact with certain specific errors (usually a single error). The effect of the error is then explored.
For example, give students an assignment in which they are instructed to create and run a program with certain specific errors. Ask them to comment on the diagnostics produced and/or why no diagnostics were produced for the error.
DISCUSSION/ CONSEQUENCES/ IMPLEMENTATION
Students become more familiar with errors and how to correct them. Having seen specific errors, they can learn to avoid making them in the first place.
You should carefully prepare exercises using this pattern and be sure to do the exercise before the class does, so that unanticipated occurrences can be prepared for and you can later provide explanations of precisely what happened.
Follow up. It is important that the students get a chance to discuss interesting things that occur while making these errors.
One especially useful technique is to ask students to make errors that, when they occur accidentally, are especially hard to diagnose when made accidentally. One example of this is errors made in C++ template instantiations.
SPECIAL RESOURCES
The instructor simply needs knowledge of common errors.
RELATED PATTERNS
In Fixer Upper the instructor makes the errors and the students correct them.
In Test Tube (i.e. another pattern, not this site) we ask for explorations. Here we ask for explorations of specific errors.
EXAMPLE INSTANCES
In addition to those mentioned above, this pattern can be used effectively to teach students about pointers in languages like C or C++, by having them make all of the common pointer errors purposely. This particular use is somewhat dangerous on computers that have memory mapped i/o and unprotected operating systems. Both syntax and semantic errors can easily be explored using this pattern.
One exercise from an old book [Teague] was to write a program that produced every diagnostic mentioned in the manuals for a given (Fortran) compiler. This is, not surprisingly, very difficult to do. Impossible, for some compilers, as the documentation and the compiler are not completely parallel.
CONTRAINDICATIONS
This pattern can be over used. It is best used early and in response to student questions.
REFERENCES
Taken from http://csis.pace.edu/~bergin/PedPat1.3.html#mistake
See also Computing Problems for Fortran Solution, Robert Teague, Canfield Press, 1972.
