Workshop Submission

Resources for Early Object Design Education

TITLE:

RESOURCE CONTACT

GOALS:

• Provide more effective feedback to students
• Enhance student judgment of quality
• Reduce grading drudgery/guilt for instructor

AUDIENCE:

• I have used this technique once; in an introductory programming class (the language used was COBOL)
• One should be able to use the approach in any class which attempts to develop student skill at producing an artifact (e.g., programming, design, writing, ...)

PREREQUISITES:

• No prerequisites have yet been identified. The technique should be useful at various levels.
• Utility may be limited in extremely heterogeneous classes as much of the discussion would be significantly above or below the current understanding of many students.
• The instructor may wish to have developed (and discussed) some rudimentary guidelines/rubrics concerning characteristics of quality artifacts (programs, design, etc.)

MOTIVATION:

• Grading for quality requires significant blocks of time, thus, feedback is often seriously delayed.
• Students seem to ignore feedback about the quality of their programs/designs. This may be due to time-delay, but it seems that students are more interested in the score received, than in the quality of their work.
• Characteristics of quality addressed by grading are somewhat superficial -- feedback regarding logical approach, data/problem representation, design, etc. is difficult to provide when using only written notes. Meeting individually with students is extremely time-consuming and will preclude students benefitting from feedback other students might receive.
• Students seem not to develop any explicitly-understood conception of the characteristics of a good program -- thus, they may be unable to judge when their programs/designs are good or "good enough".
• Quality is not easily taught using traditional lecture methods.

APPLICABILITY:

• Discussion centers on student work -- at least one of them will be interested in the current discussion.
• Students can benefit from mistakes of others and are exposed to alternative approaches they normally might not see.
• The discussion of tradeoffs in design becomes much more natural and powerful when students see real examples developed by their peers.
• Instruction can be better tailored to the students since the discussion will revolve around their actual work.
• Critiques can occur before assignment due dates, possibly making the instruction significantly more powerful.

STRUCTURE:

A more detailed outline of the steps in the technique is:

1. Request samples to critique.
   We want to get students to submit their work on the current assignment with the knowledge that the work may be critiqued in class.
   • Timing. Collecting and discussing works-in-progress before the due date seems most powerful. Students have the opportunity to use the better approach, representation, etc.; thus, they may be more likely to use the same approach in the future.
   • Encouragement. Students may be willing to submit items solely for the value of the personal critique. I offered a tiny amount of extra credit for submissions and a tiny amount more for submissions that were used in class.

2. Identify items for discussion.
   The instructor examines the submissions selecting those that catch her attention. Both positive and negative exemplars are useful. Items can relate to a large variety of topics:
   • adherence to expectations regarding program/class descriptions, interface & implementation separation, etc.
   • documentation (both commenting and identifier selection).
   • code layout
   • choice of language feature (switch vs if-else)
   • logical approach (e.g., sequential if vs nested if, nested if vs compound conditionals)
   • choices concerning data representation/definition
   • local design choices (problem decomposition in/for methods)
   • general design (class hierarchy/relationships)

3. Plan the discussion.
   Planning the discussion may require quite a bit or very little planning, depending on how comfortable the instructor is with the technique. Minimally, it appears that the instructor should:
   1. organize the selected exemplars into related groups
   2. identify the tradeoff issues illustrated by the items, e.g., correctness, efficiency, readability, maintainability, etc.
   3. identify questions to pose in case students fail to note some important aspect(s) of the example.
   4. plan the order of presentation and note whether (which of) the items might be shown simultaneously to illustrate alternatives or distinctions between good and less-good practice. An instructor example (for the same program/design) could be used if no satisfactory student is found.

4. Discuss the items.
   A major goal in the discussion is to have students examine and (begin to) identify characteristics of good programs. The instructor should elicit student thoughts and judgment rather than lecturing on characteristics or differences illustrated by the exemplars. (I find that I talk too much, but I keep trying to get better at having the students see the characteristics of good programs for themselves.)

5. Grade student artifacts.
   A major goal of the work was to alleviate grading time. The class discussion should have eliminated the need for providing feedback on individual programs/designs. A more quick and dirty perusal of the programs can now be used. (I found that it took more discipline than I had to do this. I still caught myself writing notes on programs. I did it less than in the past and will do it even less in the future, I hope.)

   
   

   CONSEQUENCES:

   • Students seem more than willing to submit their work for discussion. I did not specifically associate students with the exemplars, but also did not do anything special to hide authorship. I expect the miniscule extra credit helped.
   • I felt class was focussed on good content during the discussion days. Working from student examples also seemed to make them more interested.
   • We had good discussions. I talked too much.
   • Some instructors might consider this activity susceptible to students copying the examples and using it in their own work. The use of code segments should minimize this concern. Additionally, my goal is to have students learn to reuse good code that they encounter. I think there is little worry about cheating resulting from this technique.
   • I'm not sure that true novices are able to benefit from discussions about design quality. They likely do not have an adequate conception of the tradeoffs for considered thought about them. The technique is still useful for the many other aspects of program quality (style and simple logic considerations).

   
   

   IMPLEMENTATION:

   See the Structure section above.

   
   

   RELATED RESOURCES:

   This resource is a discussion methodology. I expect the most significant hurdle to overcome is that of the instructor's lack of experience in performing public critiques of student work. Insight and suggestions should be available in the literature on the case method (perhaps, case studies), on discussion techniques, and on questioning techniques.

   
   

   EXAMPLE INSTANCES:

   See the Structure section above.

   
   

   REFERENCES:

   
   

   ---

   [ COPYRIGHT | J. Philip East | east@cs.uni.edu | 1998 ]

   ---