So for most of the students these ideas, the driving ideas behind what we teach, remain a figment of our imaginations. They have to take our word for what we say it is and program ahead on blind faith. Eventhough the students learn what we teach them, these driving forces are never fully realized until, perhaps later, they take a larger software engineering course.

Changing the emphasis on projects from being an assignment used to test and develop knowledge of the subjects being taught, to something which will be worked upon by other students, and used by real people, appears to provide an answer on how to drive home these important concepts.

It is discussed that one of the features of a system like this is that students are forced to develop group skills which rapidly become necessary for completing the project. Indeed, in the _real world_ most projects are created from multiple groups each staffed by many people. Using groupwork indeed does prepare students for this kind of situation.

But is it really possible, in the scope of an introductory course, to do this? Social engineering is always an impossibility to master. Can people who have never programmed before actually get together and work on a project that a) may be too large for their currnt scope of understanding, and b) entails working with other people who, like themselves, do not possess a mastery of software engineering skills?

It seems that, for this scope, group work may not be the best way to reienforce these kind of skills. What could be done, instead, is to have students work on a project at one time with the full knowledge that in the future they will have to add extensions to it. Then, in a future project, the student would be forced to use her old code to work with her newly developed code. This could, if engineered properly, allow for some understanding of maintainability and extendability.

Having mentioned this idea, it is noteworthy to mention that we did try something like this with the Swarm I and II projects. The result was that students were frustrated in having to deal with the same program twice in a row. Also, it was not necessary to use one's old code for the new assignment. TO be properly designed and motivating, a project like this would have to entail two different aspects of the program over two different assignments and feature full reusability.

But what might be even better would be to have students form two person groups where the two design the full, two-part assignment together, then split up the work. For the first part one student writes their code with a provided interface (created by the team) for the second person. Then, for the second half the other teammate would have to write the second half of the program using the first teammembers code. Problems between the two parts of the assignment would become readily visible during this stage. In order to give these experiences in full to each member another sister assignment could follow where the roles were exchanged.

In general, I think the idea of attempting a real world motivation for projects is a good idea. Students who have never been faced with such a process are forced to learn the motivating concepts in practice rather than in theory.

A project more along the lines of what you mentioned might be helpful, but it would have to be carefully monitored. The groups might end up being mismatched, and one person would end up doing all the work. The problem is that no one wants to fail; if one group member knows how to do what their partner does not, they'’ll most likely do it for them. This means that one person isn’t learning what the program is suppose to be emphasizing. Also, it doesn’t seem right that one student should fail simply because their assigned partner failed to do the work, or didn’t have a solid an understanding of the concepts being taught. If these issues could be resolved, I think a group final project at the end of an introductory course would be a great way to introduce CS students to larger, more complex programming situations.

I agree with the benefit of a group project, perhaps in the Swarm or Tetris phase for CS 15. However, I think that the stated problems of having to deal with group dynamics in an intro course are very relevant, and may be too much for a course with such a tight schedule.

And it is a tight...tight schedule.

I think that the idea of working in cumulative projects into 15 is one that begs further discussion. It's something that we should seriously look at as a possible addition.