The class in question was called ``Software Components Using Ada.'' The lectures heavily emphasized the trade-offs evident with A/E/L principles, and presented a detailed engineering discipline for designing, formally specifying, and correctly and efficiently implementing Ada generic packages. We used [Booch 87] as a supplementary text and did one project using the Booch components. But the majority of the course used our own component designs and our own engineering discipline [Harms 91,Weide 91]. Several programming assignments illustrated main points from the lectures. On some of the assignments, we asked the students to keep track of the effort they spent on various activities (which we defined as carefully as possible), and on the number of bugs that caused run-time errors that they found and fixed.
Two of the assignments were particularly relevant to the point of this paper. In the first, we provided an implementation of a generic ``unbounded queue'' package that exported the standard primary operations: enqueue, dequeue, and a test for emptiness. We asked the students to add four secondary operations: copy, clear, append (concatenate two queues), and reverse. We formally specified all the operations and discussed them in class so there would be no doubt as to their intended semantics. We asked the students to implement these secondary operations using two different methods: (a) by layering them in a new generic package on top of the provided queue abstraction, and (b) without layering, i.e., by directly modifying the underlying generic package to export the four additional operations. Half the class (nine students chosen at random) did part (a) first; the other half did part (b) first. Below we call these Group A and Group B, respectively.
For the next assignment, we provided a standard solution to part (b) of the above assignment, and asked the students to change the underlying representation of queues. This required that they redesign and recode the implementations of the original primary operations as well as the four secondary operations. We asked that all the students first reimplement the primary operations, then the secondary operations.
For both assignments we asked the students to keep careful records of the time they spent in designing/coding, testing, and debugging/recoding each operation. We also asked them to report how many bugs they fixed in each operation. We emphasized the importance of being internally consistent in keeping and reporting this data, and stressed that grades in the course would have nothing to do with the reported numbers. After discussing the study with each of the students before and after the assignments, we found no reason to believe that the results were significantly affected by variations in reporting methods, by collaboration, by severe outliers, or by latent fears that honest effort/bug data would influence course grades.