ITiCSE 2003 Tips & Techniques
Peer Evaluation in an Algorithms Course

Students need a lot of practice in expressing themselves clearly and concisely; making their ideas understood; and presenting their work in a professional manner. For this reason, in my courses I generally try to emphasize that the programming part of the projects is just the beginning and that, in addition to a working program, I expect a clear, convincing, and complete report describing the work. I describe one such project that I gave to a graduate algorithms class at Villanova University and which was then graded by other students in the same course. I have given similar projects to undergraduate classes, but so far I have experimented with peer evaluation only in the graduate classes.

There are several good reasons for incorporating peer evaluation:

• Students are often locked into a particular way of thinking about a problem. Seeing the work of others makes them realize that there may be alternative viewpoints.
• When explaining a solution to their professor, who, they assume (rightly or wrongly!) knows all about it already, students are not really focused on actually explaining their thinking --- they are just trying to show that they know "the answer." If they are aware that someone else who is just familiar with the problem, but has not actually solved it, will be reading their report they are better disposed from the outset to write a clear explanation.
• We can talk ourselves dry with the importance of good programming style and documentation. They need to see the horrors produced by someone else, because it is hard to recognize their own.

I choose a relatively complex project that has several parts and divide the students in two groups. Students of each group work individually. Some parts of the project are tackled by students of both groups, while others are only done by one of the groups. For example, in Fall 2002 I gave a project to implement some graph algorithms. All students had to implement depth-first-search to find cycles in graphs represented using adjacency matrices and they also had to write a module that, given a probability p, generates a random graph such that the probability of an edge between two vertices is given by p. Group A also had to implement depth-first-search using adjacency linked-lists, whereas Group B had to implement breadth-first-search instead. Each group then had to experiment with their programs in order to answer specific graph-theoretic questions: - How large does p (density) have to be so that the probability of a cycle is 50%? How is this affected by graph size? (Group A) - Which algorithm finds a cycle faster: DFS or BFS? How is this affected by graph density and size? (Group B)

Some specific guidelines for experiments were included in the project description. See http://www.csc.villanova.edu/~map/8301/f02/proj2.pdf for details.

Note that both groups were working on similar, but not identical problems. This puts them in a good position to understand each other's work, without having already done it themselves. Having done something similar, they have a clear appreciation for the difficulties involved.

This project was a big success overall and an enormously rewarding experience. The only real difficulty, for me, was the logistics of administering such a project. The students were asked to write a brief summary of what they learned after the peer evaluation phase and these were most enthusiastic, sometimes pointing out benefits that I myself had not anticipated. Several of my students already have industry jobs and they said how valuable this type of project is and how they wished they had been given such projects when they were undergraduates. So, that is my next goal.