TITLE: Teaching Programming Plans Explicitly AUTHOR: Eugene Wallingford DATE: July 27, 2004 1:46 PM DESC: goals and plans in programming ----- BODY: Another article to catch my eye in the latest SIGCSE Bulletin was "Training Strategic Problem Solvers", by de Raadt, Toleman, and Watson. This brief paper discusses the gap between problem and solution that students face when learning to program. Most programming instruction relies on students to learn problem-solving strategies implicitly through repeated practice, much as they would in mathematics. This approach faces a couple of difficulties. First, as I discuss in an earlier entry, CS students don't generally get enough practice for this approach to be effective. Second, and more troublesome, is that this search for strategies occurs in a large state space and thus is prone to dead ends and failures. Most students will end up constructing the wrong strategies or no strategies at all. The authors report the results of an informal experiment in which they found that their students, after a semester's worth of programming instruction, had not mastered several simple plans associated with writing a loop to average a sequence of numbers -- a basic CS 1 problem. I've heard many other instructors tell a similar story about the students at their schools. I've seen many proposals for new approaches in CS1 offered to address just this problem. So, what's the solution? The authors suggest that explicit instruction about goals and plans will lead to better problem solvers. They harken back to Soloway's ground-breaking working on goals and plans as a source for the material that we should be teaching instead. I agree wholeheartedly. The elementary patterns community has devoted much of its energy to identifying the plans that novice programmers should learn and the problems that they solve. By making explicit the forces that lead to or away from a particular pattern, we hope that students can better learn to make systematic design decisions in the face of multiple goals. Notice the subtle shift in vocabulary. The pattern-oriented approach focuses on the thing to built, rather than the plan for building it. This allows one to recognize that there are often different ways to build the same structure, depending upon the forces of the problem at hand. The plan for building the pattern is also a part of the pattern description. Soloway's plans were, by and large, code structures to be implemented in a program, too. The name "plan" came be thought of in the same way as a pattern when one considers it in the sense of an architectural plan, or blueprint for a structure. Teaching patterns or plans explicitly isn't easy or a silver bullet, either. Mike Clancy discusses some of the key issues in his paper Patterns and Pedagogy. But I think that it offers the best hope for us to get it right. I hope that de Raadt, Toleman, and Watson will continue with their idea -- and then tell us the results off their new teaching approach. -----