Small Releases Mean Big Progress

Students in our nonmajor's programming course as well as our first- and second-year major's courses sometimes work on large projects in groups, in which they may be given as much as three weeks to complete the project. The projects are not designed to require students to work full-time for the duration of the assignment; instead, the schedule is typically padded to allow them time to work out group meetings, to do other course work, and to learn the topics necessary to complete the assignment. Typically, the assignment is discussed repeatedly in and outside of class during this time, but rarely do most curricula require students to demonstrate their progress until the final deadline. This practice has caused mixed success in these large projects sometimes groups fail to deliver even a compiled program!

This past year, we have changed to requiring many small releases before the final project is completed, giving the students only a few days to a week to submit part of the final product. We then work with our teaching assistants to look at these releases and provide groups with feedback while they are still working on the project. Using this practice, every group successfully completed the project, and the quality was much higher than what we experienced in previous semesters.

Student View

Many students abuse the time given in a large project by ignoring the project until the last minute and then coding in long spurts until it is finally done. This style of working gives the computer science department a reputation for being hard and requiring all-night coding sessions. Although this process may make sense in the context of juggling all the demands placed on a student, it leads to many problems when creating a good software project.

• Communication between group members is generally very tenuous unless they are all in the same room. Because no one is certain when a specific feature will be worked on, it is hard to count on a feature getting done, let alone planning to use it, improving on it, or adding to it.

• One way of dealing with the communication problem is to meet once at the beginning of the project and break it into chunks that can each be managed by one student working alone. The students then meet again at the end of the project and attempt to integrate their individual parts into a working whole. The first step goes well, but, unfortunately, the last step rarely does for average groups.

• When dividing the work, some students may have much more to do than others in the group, either because some features were not understood well enough when the project was planned or because one student got very excited about a part and added many extra features. Additionally, most students do not understand the details of the other parts of their project.

Making small releases has helped relieve these problems simply because it requires the group to communicate more often. Not only can the course staff better monitor the group's progress, but so can the students. Because they had to integrate their code more often, they typically had something that they could run while they were working.

Students reported that this led to even more intragroup communication because having a running program gave them more to discuss with their group members: how to improve specific features, curiosity about how other parts of the project were implemented, and plans to determine what parts remained to be done.

Students also reported that they were actually proud of their projects. Many more groups were inspired to add more features as they worked with their programs to make them easier to use or more interesting. In one case, students were asked to complete a game that could be run from a Web page. One group told other students in their dorm about the Web page and soon had a large user community. As people played, they made suggestions for new features. The group published new versions of the game as often as every 20 minutes! Many of these features were not part of the specification for the game but ended up being extra credit.

Educator View

The instructor developing small releases for large projects must do some more work to take advantage of these benefits. First, one must decide what will be required for each release and schedule these deadlines as if they were real, including minimizing conflicts with the university schedule. In essence, each release becomes an assignment in itself. This extra work is balanced in some sense because it may make it possible to better plan the order of topics in the course.

Additionally, each release must be checked and feedback given to the group as quickly as possible. This is even more important because these mini-assignments build toward a single final project, and feedback after the assignment is over is all but useless to the group. In our courses, we typically meet with the group as a whole once a week during the project, demonstrating their project, discussing its design, and planning for the next deadline. In fact, the role of the course staff is often crucial to realizing truly big progress from these small releases.

For example, in our advanced programming course, we have asked students to complete a LOGO interpreter and programming environment [Papert1980]. They had three and a half weeks to complete the assignment, and we gave them six deadlines: Three required written submissions, and three required running code. The first two deadlines attempted to get students to think about the project by asking them to explain specific design issues and use cases with respect to the project [Cockburn2001]. For each of the next three weeks, they turned in successively larger releases of their project, the last being the final version. In each case, they were told to focus on getting the current, smaller set of requirements finished rather than trying to show that they had started, but not finished, all parts of the project. Finally, after the final version was submitted, each student in the group was asked to complete an individual project postmortem, reflecting on the group experience [Kerth2001].

An unexpected benefit of these small releases was that the course staff was able to grade the projects more quickly and give better feedback because they already knew the details of the code. They had learned the details as the project was built instead of having to learn them after the fact. Teaching assistants reported that student groups were more open when talking with them if they started from the beginning of the project as opposed to only starting a dialogue after the project was complete (and the student's grade was more clearly on the line). This resulted in faster, higher-quality grading.