Observations and Student Reactions

Metaphor Definition

XP projects need a guiding metaphor to help everyone on the project "understand the basic elements and their relationships" [Beck2000]. We provided both groups with an initial story and suggested a metaphor. We also mentioned possible future enhancements such as chat capabilities, in which the basic elements of each project could be exchanged. We did not require that the group explicitly develop their own version of a metaphor.

About halfway into the semester, we asked the students to give a one-sentence description of what their team was constructing. Their responses showed that in most cases the enhancements had become an integral part of their perception of what they were doing. For both teams, this fuzziness appeared to make it harder to get started with a simple first version. It might work better to require students to develop a simple metaphor themselves and then ask them every so often to recall what it is.

Coding Standards

One of the first things that we asked each team to do was to develop and publish coding standards to be followed by all team members. Almost all students reported that they followed their standards and that 60 80% of their group members did also. Almost all felt that the standards made it easier to read any team member's code and that they enhanced the attitude of group ownership of the code.

Stories and Preliminary Design

One student in each group was elected manager. This person was responsible for leading group planning sessions, identifying tasks, and coordinating all activities. The fact that this person was a peer made it somewhat unrealistic, but both managers performed quite well.

We felt that, as novices, our students needed some structured activities in order to make a start. A metaphor might be enough for an experienced programmer who has done similar things before, but beginners need something more. We provided a big "story" and several smaller ones, and asked that each group create a concept diagram [Larman1998] and then turn that into a class diagram. The students may have viewed this task, as one put it, "like a big pain in the …," but their thinking changed when they saw how much the diagrams helped keep their group on track. From our perspective, even considering the fact that student responses in the evaluation may lean toward what they thought we wanted to hear, the diagrams did help create within each group a better sense of what they were building. The group that had more trouble with their project looked back at this part of the process and speculated that more care in making the diagrams and determining class responsibilities would have helped.

Unit Testing

Unit testing is fundamental to the XP process. We used the JUnit testing framework and spent several lab periods getting somewhat familiar with it.^[2] We asked our students to write tests, gave a number of demonstrations, and encouraged them to write tests before coding the class. A number of tests were written, but no one would admit to writing one before the class code was written! There was little indication that tests that were actually written were used extensively. Part of this is due to the fact that automated tests for graphical applications are harder to write, and the teams could and did run quick visual tests to verify that a method was working. But the fact remains that automated unit tests were not used very much.

^[2] See the JUnit Web site at http://www.junit.org/.

Probably the fundamental reason for this lack of unit testing is that our students have not been trained in writing them. The idea that writing tests helps in designing a class is not a natural one for them. Their tendency is to want to get the job done and see some "results." And in an academic environment, where the life cycle of most student projects ends after the program works, there is little to point out the value of having a suite of tests available. Our efforts to demonstrate how to incorporate tests in the normal coding patterns had little effect, and we believe that no matter what one might do at this point in our curriculum, the results would be much the same.

Unit testing should be incorporated into the curriculum at least as soon as objects are introduced and earlier if possible. Then testing would become a programming habit whose value would be taken for granted (like coding standards). We have taught coding standards for some time, so they now come naturally to students. (When asked whether it was difficult to follow the coding standards adopted by their team, students typically responded, "No, that is the way I program normally.") Testing, if taught early and often in the curriculum, would become just as natural. The benefit would be better code, an admirable goal no matter what development method is chosen.

Pair Programming

Following the XP practice, we asked our students to code in pairs at one computer. Our students are used to working in small groups, but none had experienced pair programming. We suggested that one way they could work would be for one partner to code tests or class methods while the other worked on strategy. After a time they should switch roles. We also encouraged them not to work with the same partner every day.

It is hard to judge just how good a simulation of an XP environment this turned out to be. The students did quite well in pairs even though they might not have followed the XP model exactly. As mentioned earlier, testing was an afterthought for them in spite of our instructions. So instead of having one partner start by implementing some tests while the other developed a strategy for implementing the responsibilities of the class, they would first work on strategy and planning together. Then one partner would start to type while the other checked for typos and syntax errors, while at the same time asking the partner questions about how and why something was done. We asked our students to give us their impressions of pairing, and we believe that their responses show that it served both the student and the project well.

There were several areas in which 80% or more of our students felt that pair programming helped. For instance, they overwhelmingly reported that pairing helped them understand the project as a whole. These were some responses.

Some parts I would not have understood at all. But after a couple days working with someone on it, I was much more comfortable.

Talking a lot helps you know the project code inside and out.

Most felt that they had learned more about an unfamiliar area by working with someone who knew more. The few who did not respond positively reported that neither of them knew much about their tasks, so a lot of time was spent with the documentation.

One of the criticisms of XP is that it cannot be efficient to have two skilled programmers working on a single task when they could be working separately on two. Most of our students do not agree. About two-thirds thought pairing made the process go faster, while another quarter thought sometimes yes, sometimes no. Only a couple felt that pair programming was wasteful. Part of the speedup perceived by most of the students was probably due to having more than one person catching syntax errors and typos. As one commented:

Having someone looking over your shoulder and asking questions and pointing out errors early saved time.

They frequently responded that the design of a class was a joint effort that benefited from more than one perspective.

It helped bring up more ideas …

A second person can … introduce more ideas …

Those who were more skeptical of pair programming felt that the communication process really slowed them down.

But communication of those ideas takes time.

Slowed me down since I had to make sure my partner understood what was going on.

Even these statements indicate that pairing helps with overall team communication.

In an effort to obtain student perceptions of how well the teams worked together, we asked them to comment on whether one person tended to dominate the pairing. Here the students were divided roughly evenly in their opinions. As mentioned earlier, only a few responded that they split the work along the lines of one partner coding a method while the other focused on strategy. So it is probably quite natural that the "better" programmer would dominate. Few reported any personality difficulties that seriously impaired their work. These results demonstrate what Beck claims in [Beck2000], that pair programming "is a subtle skill, one that you can spend the rest of your life getting good at." We made many process mistakes, such as not developing tests in a timely manner. So a good question might be, "Was there enough learning to justify our approach?"

Even with the mistakes made, we are satisfied that we have made a good start in using pair programming and the XP software development process in general. We asked our students to give a positive (thumbs-up) or negative (thumbs-down) assessment of pair programming. Fourteen gave it a thumbs-up (some even two thumbs-up), three said it depends on the project, and five just did not like it. The following comments from those who liked it indicate that they felt they learned a lot and that pairing helped the team work together better.

Project B was tight.

Gave a chance to work with other styles of programming.

I did like it; getting multiple ideas and then going with the best helped avoid unnecessary trial and error.

It made the project more fun.

Focuses on understanding how the given class functions.

There were some valid criticisms and useful suggestions. Several reported that they were unable to accomplish very much in our two 50-minute periods, although they were much happier with what they could achieve during the two-hour lab period. Even when the pair continued on the same task, a certain amount of start-up time was needed whenever they reassembled. Toward the end of the semester when the teams were hurrying a bit, the better programmers tended to become more dominant and especially found at this time that having a partner slowed the process.

The few who remained unconvinced about the merits of pair programming said:

I found that it slowed the process. Working individually causes everyone to have to carry their share of the load.

I code better alone. So do most of our better programmers. If I don't know what I am doing, pairs can help, though.

I would still prefer to work independently, though it was good to try something different.

The only time it worked well was in the lab, where you had time to get things done. It might work better in a workplace environment, where the XP protocol could be held more closely.

Even these thumbs-down votes show an openness to later reevaluation of the process.

On the whole, we were pleased with the way our students used pair programming. What we did was not a perfect simulation of the pair programming process, but almost all students came to see its potential as an important part of the development process.

Multiple Small Releases

Neither of our groups produced a simple working version of their project for early "release." The group working on the floor plan drawing tool came the closest. Because their output was primarily graphical, they did build an early integration of their three windows to test it. They did a lot of testing of the type "If it doesn't look the way it is supposed to, fix it." In their view, they had a working version quite early, and subsequent work enhanced the current version.

The group doing the MathML editor was unable to integrate until near the end of the project, and they underestimated how difficult this would be. Too many members of the group had never had any experience implementing many of the elements of the project they were dealing with. Perhaps this is where a full-time customer on the project would have helped this group establish simple early-release criteria so that some of the integration problems at the end could have been solved in a simpler context.

Collective Ownership of Code

We required that both groups open all code to all team members so that anyone could improve existing code as long as they did not break it. Most class members reported that there was a feeling that the whole group owned all the code. They were more split on whether this was helpful, however. It seemed to work better in the group that could do more visual testing. Students responding positively to group ownership made comments such as these.

People would refactor others' code and make it more efficient. It was definitely a help to the group.

If you were going through and found something that could be refactored, it could be done right then.

I had no problem with others changing my code, as long as I could still understand the code. The open ownership of code seemed to help the project.

The few who thought it hindered progress said things such as, "It was helpful if you had done something wrong, so someone else could fix it, but annoying if someone changed something you thought was right."

Refactoring

We spent a number of class periods demonstrating systematic refactoring according to [Fowler1999]. Although both groups made changes in their code that amounted to some sort of refactoring, the lack of automatic tests prevented them from doing this in any systematic manner. They also ran out of time in the semester. The amount of refactoring they did was a result of the fact that they were doing pair programming. The need to make bad code better is clearer when lots of people are reading it.