Cooperation in CS Education?

fwitness asks: "The college I currently attend, like most colleges, is on a form of 'Academic Honesty Policy'. It has been explained to me in various ways, but mostly it boils down to: If you catch someone's code out of the corner of you eye, that's cheating, and you need to come up with your own 'original' ideas. I'm a CS major, so I write a lot of code, and I imagine when I get in the work force, I'll be writing a lot more. The difference is, in the workplace, I'll be in a team of people. I won't have control and I'll have personnel and political issues to deal with in addition to my job. So far I've had one class that actually demonstrated this principle, and I'm pretty much finished all my CS courses. I know the college has to do this so they can somehow grade 'my' code and assess my performance. Isn't there a better way? A way that students can be taught to work as a team yet still be able to tell who is pulling their own weight and who is not?" I always enjoyed working in teams during my college education, yet found that projects, where you were allowed to work with others, were few and far between. Do you all feel that technical courses should show a bit more emphasis on working with others, or is this just one of life's lessons that you pick up as you go along?

Comments

Software teams

[wiredog]

My first job, lasted 5 years, I was the only programmer in the company. At this job I'm on a team, but I'm the C++ Guy. We also have an Oracle Guy, An HTML Guy, etc. Just because you're part of a team doesn't mean that you won't be by yourself much of the time.

Actually, at my first job I was part of a team. A Programmer, an electrician, a machine shop guy, an Autocad/designer guy. That was the main team.

Grading group projects

[DudeTheMath]

As a math instructor at the Univ of Michigan, I assigned all homework in a couple of my classes as group homework; but each individual reported separately on both their own contribution and that of others in the group (just a sentence or two).

In groups of four or so, this self-reporting was almost always an easy way to keep track of who was working and who wasn't. Quizzes and tests also revealed some slackers.

I only had one truly fractured group in those terms, where none of the reports agreed. I broke them up and changed some groups.

I would do it again. Not only did I grade fewer homework papers :), but the students learned to work together, assign responsibilities, and evaluate performance within their group, which are all important workplace skills.

Re:Working as a team

[cavemanf16]

...and to add to your comment:

In the workplace, it takes a LOOONNGGG time to can the slackers. After all, you want to have plenty of evidence against them so that you don't get a messy lawsuit about unfair discrimination of their undiagnosed on-the-job narcolepsy after you fire them. So putting up with the slackers usually doesn't stop after high school and/or college.

However, I do think CS students should be required to take at least one in-depth course on how to work in a team setting (and not just a senior project, I'm talking a course dedicated on how to work in a team). There are plenty of programmers and techies out there that don't work well with others, and that makes it harder to get your own work done much of the time in the corporate world.

It works ok at my school.

[Elwood P Dowd]

Here at UPenn we're sortof balanced. One of the expenses of being balanced is that some cheaters don't get caught and some people get accused of cheating when they haven't. But most classes do allow us to talk to each other about our code. And, we have an elective group project class available after freshman year. Junior year is a required group operating systems project. You write a toy operating system to run on solaris. Senior year you have to do a project that can be group based or not.

It would be very very detrimental to be a CS major here without taking the elective software project during your sophomore year. I'm not sure how anyone can survive junior year without it. In our (small) project, one of our team members basically lied about how much work he had done. We allowed him to procrastinate the integration and we were totally screwed.

We wrote what he should have written in the wee hours, and had learned several valuable lessons. And those lessons certainly saved our asses several times in our next project. Most notably when we picked group members.

Also, for those concerned that their partners' diligence wouldn't match their own, why on earth were they your partners? Did the prof choose for you? The best solution to that issue was what they did in my highschool. All major assignments were group projects. If the assignment was worth 100 points for four people, you would get a grade out of 400, and had to unanimously decide how those points were allocated to individuals. I had an A+ in every class that worked that way. And I cared more about my work then than I have in college.

From the teacher's point of view:

[Brian Hatch]

I taught a number of programming courses at Northwestern University, and have offered group projects as an option for clasess. Those that wanted to do group projects - and I encouraged it - were allowed to do so, and said projects needed to be proportionally more complex than those submitted by individuals.

Part of the writeup for a group project would include a brief (1-2 line) explanation of who did what part. Knowing this was part of the material turned in, it encouraged the loafers to make sure they did enough to claim part of the project. I also stressed that they needed to know how all the pieces fit together, not just understand their standalone part.

The final exam for the class always was in a similar format as the midterms, with sample code to write, comment on, correct, questions about the topics covered, etc. This was worth 50% of the grade. The last 50% of the grade consisted of the following questions:

1. How did your program do what it did, explaining in some detail your sections of it.
2. Describe in detail the problems you had with your part of the project.
3. What do the following snippets of code do, and where are they found in your program.

The snippets would be taken from two sections of the actual project code, one which they (claimed) to have written, and one which they hadn't.

I was extreemly pleased to see that, in fact, most folks had divided up the work evenly, and had a good understanding of the project as a whole. Now this could have been due to other members of the team explaining it to them, rather then them figuring out the other participant's code manually, but isn't that what you'd do in the real world?

Those folks that could explain problems they'd encountered often noted that they asked for help from other members of the team. By this point in the class, I could already recognize the coding style of each student anyway, but I really appreciated the honesty, and how they did work together to produce something.

Yes, there were some (I'd say 5%) that were tricked up on the exam and showed that they didn't actually write much of the code, nor understand it. However overall folks did a good job acting like they would in an ideal group coding environment.

The only problem I had with group projects was with Thurston Howell (or at least that's what I called him in my mind, due to his attitude and voice) who had one of the classic coder failings. He got so caught up with getting the perfect interface -- being able to use emacs-style data entry editing abilities and such -- that he never got any of the backend stuff even started. Those in his group didn't know where to go, since they had nothing to plug their code into. Here's where a normal group may have a manager who could step in and help out, and they didn't quite have the real-world mentality that would have allowed them to come to me and tell me what was holding them up. But other than this one incident, group projects have always been an excellent thing.