CS10, SPRING 2009, UC Santa Barbara

The students started these images in lab03, working individually. The images you see here are the result of pair programing collaborations in lab06, where the students combined their individual efforts into a single image—in the process, learning several lessons about refactoring, generalization, and encountering several uses of inheritance and interfaces.

The individual part (lab03): In lab03, each student had to write code that used Java objects such as Line2D, Rectangle, Ellipse2D, etc. to create an image, and draw it in a JFrame. This involved inheritance (students had to extend from javax.swing.JComponent.)

Each student had to draw two objects that could be drawn with simple combinations of lines, rectangles, circles, and ellipses. To make it more creative, and to discourage plagiarism, each student had to draw something that no other student in the class had chosen. Students used an online discussion board to register what they wanted to draw, and they could only choose an item if no other student had already chosen that item. In lab03, students could hard code the points in their images, since the object was simply to use the Java drawing classes to draw a single picture.

The pair programming part (lab06): In lab06, students worked in pairs to refactor their lab03 code—generalizing their image drawing code by writing classes that implemented the java.awt.Shape interface—a separate class for each basic shape (star, house, tree, skateboard, etc.) The intent was to provide practice in refactoring, generalization, and "implementing an interface".

Additionally, as a way of introducing pair programming, students had to work in pairs to combine the images they drew separately into a single image for their pair—one that illustrated how they could now draw their individual images at any location on the screen, and at any size. Students were not told before choosing their would happen, so there was an additional creative challenge of finding a way to combine their images.

Part of the design of these assignments was that students complete an individual assignment first, and then used pair programming to combine their individual efforts. The idea was to reinforce the notion that "everyone brings something to the table" when we work in pairs.

To prepare students for pair programming, the pair programming video from Laurie Williams' group at NC State was shown in lecture, and a homework assignment was given that students had to complete in pairs.

Part of that homework assignment involved answering basic questions about pair programming—students were encouraged to watch the video again together to review the information. Perhaps equally important, as a graded part of the homework assignment, students were responsible for finding times that they could commit to working together in pairs outside of class. Students had to report these times in an email to the instructor, cc'd to both members of the pair, in order to earn full credit for the homework assignment. Our hope was that this would result in increased accountability.

Students were also told that if they could not find any times they could commit to working together (in between the scheduled labs) they needed to ask the TA or instructor to assign them to a different pair. Since students were initially given the option of choosing their own pair partners, it was our hope that the spectre of being reassigned to a different partner (not of their choosing) would provide a strong incentive to "work out" any scheduling conflicts up front.

To prepare the TAs in the course for pair-programming, the instructor screened the pair-programming video together with the TAs, and provided them with an annotated bibliography on the use of pair programming in introductory programming courses (along with encouragment to read the full papers.)

This web page is created using the Galleria plugin for the JQuery JavaScript framework, and is based on a Galleria demo by monc. Visit the galleria project: http://galleria.googlecode.com