Pedagogical Pattern #21
Mission Impossible
originally submitted by:
Alan O'Callaghan
Object Engineering and Migration group and Software Technologies Research Laboratory
De Montfort University
Faculty of Computing Sciences and Engineering
The Gateway
LEICESTER LE1 9BH
United Kingdom
aoc@dmu.ac.uk
NAME:
Mission Impossible (a.k.a. Kobayashi Maru - see Note below)
DATE:
Originally submitted October 1996. Last updated 12th January 1999.
AUTHOR:
Alan O'Callaghan, De Montfort University, UK.
THUMBNAIL:
The Mission Impossible pattern is used to make learners suspicious about their understanding of important Object Technology concepts so that they continually question those concepts and improve their understanding of them. Learners occasionally need to be "shocked" into deeper thinking about what they are doing in order to appreciate some of the subtleties. This is all the more necessary when such ideas as "objects model the real world" can be understood in an entirely naive way which disarms the learner in the face of real problems when they occur. The Mission Impossible pattern achieves this by presenting apparently simple problems which cannot in fact be solved by the naïve application of received wisdom.
PROBLEM / ISSUE:
A fundamental issue in the teaching of OT, whether it is in a 15-week lecture, tutorial and lab-based course, or an industrial short course is that the educator is inevitably forced into a mode whereby abstracting and generalizing the subject into "key" concepts has the side-effect of oversimplifying a rich, deep technology which is full of subtleties.
AUDIENCE/CONTEXT:
The pattern is best used selectively, after a logical block of learning in the form of instruction, lectures, reading and hands-on work has been encountered and conquered by the learner. It works best in group work situations. The pattern can also be used to form a link between the learning of basic and more advanced topics (the advanced techniques being needed to master the "impossibility" of the problem). It is abstracted from experiences of learners from level 1 computing science students to postgraduates; and from novice programmers in industry to highly skilled and experienced developers new to OT.
As such it is generally usable by instructors and educators.
FORCES:
OT is, in software engineering practice, arguably concerned about "programming-in-the-large" and about the structure of software systems. It is difficult, if not impossible, to reproduce such systems (and therefore the problems they exhibit) in the classroom. Key truths about OT, that distinguish it as a paradigm from say "structured methods," are often given a naive expression (notoriously Meyer's "Objects are there for the picking" answer to the rhetorical question, "Where do I find the objects?"). This can lead to the learner badly underestimating the intellectual effort needed to master
object-oriented concepts. Students learn best from "hands-on" experience.
SOLUTION:
The idea of the pattern is to present the learner with a problem that the basic concepts do not appear sufficient to solve, in order to provoke further questioning, exploration and self-study . A problem is presented which, at first look, seems to suggest a straightforward solution. A complete solution will, however, require careful consideration of a number of issues and will not normally be possible because: there is insufficient time to study the full range of issues thrown up, or there is insufficient information to complete the exercise, or no solution is possible despite first impressions. The contrast
between first impressions ("simple problem!") and the result of some study ("a deeper, more difficult problem than first we thought!") is crucial to the successful application of this pattern. A brief summary (5 mins. maximum) by the educator explaining why the problem was "impossible" is vital.
SPECIAL RESOURCES NEEDED:
A prepared example (see Example Instances section below)
DISCUSSION:
If used appropriately, and successfully, the result is a wide-eyed learner keen to explore the deeper recesses of the technology and the philosophies which underpin it, including areas of controversy. Arguably the pattern draws on an historic experience of pedagogy, traceable back at least to the Zen Koans. The pattern has been likened to the "sound of one hand clapping" and other difficult questions posed by the Zen masters to encourage their students to lose their worldly inhibitions and achieve enlightenment. In our context the questions need not be so hard, or the road to travel quite so long and difficult.
The problem should be able to be presented in a short form, and yet be "complete" in the sense of there being sufficient information for the learners to begin their work. There should be no more than 45 mins. work involved before the learners can appreciate that there are issues which require further explanation. There should be no need for a "complete" solution to the problem. Indeed for the best implementations of it there is no solution. Closure comes with an understanding of the problem's "impossibility" not its solution. It is probably best, for reasons of learners' self-confidence, to sandwich the
use of Mission Impossible between blocks of teaching which are aimed at delivering measurable competencies.
CONTRAINDICATIONS:
Misused, or overused, the pattern can destroy a learner's confidence in what she or he is learning. The pattern carries a health warning. The instructor should be careful to look for any contraindications in the overall learning context. For example, certain learning programmes engender an expectation of the student that they will be 'spoon-fed' instruction. In industry there is also a widely-held misconception that learning OT is about learning a new toolset or programming environment which requires 'instruction' rather than 'education'. The Mission Impossible pattern requires initiative and risk-taking on behalf of the learner, and would therefore not be appropriate in such contexts.
RELATED PATTERNS:
Can be considered as a special variant of the Plan-Do-Reflect (PDR) pattern [Lilly 1996]
EXAMPLE INSTANCES:
This pattern is used in the teaching of a number of OT courses at De Montfort University, Leicester, UK to both undergraduates and postgraduates. It is also employed in training courses delivered to software professionals in industry by the University's Object Engineering and Migration group. These courses aim at preparing learners for the application of OT in the "real world" of commercial IT development where large-scale legacy systems and the issues surrounding them abound.
Learners take quite quickly to the idea that OT development is, in some sense, "seamless". Practical exercises reinforce the notion that objects identified in some conceptual model of the problem space can be mapped more easily into code than is the case with so-called traditional methods. This can lead to a naive confusion between "analysis objects" on the one hand, and code objects on the other. An exercise based on an anecdotal example in [Cook 1994] is used to disabuse learners of these naive ideas, and to provoke discussion about the nature of the mapping between objects in various models (e.g., analysis model, specification model, implementation model).
The learners are split into groups of 6-8 persons, given a scenario and asked to present an outline conceptual model (i.e., a modeling of the problem space), followed by a design model. The scenario is as follows: "The sky is dark. The ground is cold. All is silent. The sun rises. The sky brightens. Birds sing. A cock crows. The ground is warmed. Grasses grow".
Typically, learners do not complete the first part of the exercise. They get bogged down because they attempt to apply concepts about program or code objects to their modeling of the problem. In particular, they attempt to discover "appropriate" methods and messages and apply them in a single-threaded chain of cause and effect which (though suitable and indeed necessary for a machine-based simulation) can only distort a real world problem which is full of parallelism and chaos.
The educator can prompt fruitful discussion of the underlying issue (the difference between objects that model mental perceptions of the world and those that implement machine behavior) by posing simple questions in a timely manner:
- If the Sun sends a message to the Grass to grow - in what order do the blades of grass receive it?
- How does the Sun behave differently when its Rise method is executing as opposed to its Set method?
By the end of the exercise, timed to fit into a one-hour tutorial, learners realize that a relatively simple program (model the sunrise) becomes tortuous and difficult if a naive notion of object is applied in both kinds of model. Transformation is necessary. An object model built to get a better understanding of the main abstractions in someone's concept of the 'real world' will often not contain the causal connections required for a machine-based software solution. These have to be added in design, changing the nature of the abstractions as they are forced fit into the software design. The design model has
to 'cheat' just to make the thing work, as well as deal with machine-level forces that might need to be traded off (efficiency, memory usage, storage capacity etc.). In short, the lesson is learned that you have to think carefully about how you use objects at every stage of software development.
REFERENCES / ACKNOWLEDGEMENTS:
[Cook 1994] Cook S. and Daniels J. 1994. Designing Object Systems. Prentice Hall. Englewood Cliffs, NJ
[Lilly 1996] Lilly S. 1996. "Patterns for Pedagogy" in Object Magazine 1/96
Special thanks go to Linda Rising (who shepherded this pattern for the OOPSLA '98 Pedagogical Patterns Writers' Workshop) and Mark Skipper (who, in the author's absence, presented the pattern originally to the OOPSLA '96 workshop). Their invaluable insights have been incorporated into the current draft, as have those of the reviewers at the '96 and '98 workshops. It is a much better pattern today for the feedback it received on those occasions.
Note: The alternative names for this pattern (Mission Impossible, Kobayashi Maru) each evoke memories of popular TV series. The original name, Kobayashi Maru, is more accurate in what it evokes. Fans of the Star Trek TV and movie series might recognise it as the name of a 'no-win' computer-based training simulation at the beginning of the second Star Trek movie (and also the name Kirk gives to the operation to covertly hijack the Enterprise and rescue Spock in the next movie, The Search For Spock). In the training simulation a star ship of the name sends out an SOS from the neutral zone. Star Fleet regulations require the distress signal be responded to. But it is in fact a trap. Romulan ships decloak and the trainee inevitably loses her ship in an unequal battle. The movie reveals that only one graduate of the Star Fleet academy has ever succeeded in saving the ship, that was Captain Kirk (of course) and he did it by re-programming the simulation. In fact, he won by "cheating" which is also the only way learners can solve the example above (in the sense that they have to 'break' the abstractions in order to code them usefully). In the Mission Impossible TV series the so-called "impossible mission" was always accomplished in every episode. The name is slightly less accurate therefore, but has a wider appeal than to just
Trekkies. Hence it is preferred - AO'C.