Slashdot Mirror
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?
Having relatively recently graduated from college, I don't really see a way that this can be done. Most of my group experiences involved maybe half of the group caring about their grade, and the other half being ok with a C. You then end up with an extremely unbalanced work load as the ones who care the most do the most and produce the better product. Then they usually have to go around and fix up the people's work who really didn't care as much. All in all, it rarely leads to a produtive group and doesn't teach you much about the work force.
:)
That being said, I have been involved in good groups, and those have been fun. When the work is divided evenly and everyone wants to do well, you end up with a higher quality product for less work per person. They have lately attempted a rating system of teammates, but I really haven't seen much come out of that. That could work, but unless you see everyone's grades (and since I was a student I didn't) you can't know for sure.
Bottom line is you can't ever differientiate any one person's work in a group effort. In the terms of code, if a module is crap and buggy, I'd rather rewrite it correctly than fix crappy code. That "hides", so to speak, the original authors work. Group work really isn't the way to evaluate individual people.
Personally, I think the beginning years should be individual work as you learn the basics, and the later years group work. You'll have to find a way to account for each person's abliity though, which isn't easy.
Basically, it isn't an easy thing to do.
Khyron
By someone who has been in both:
1) At work, it's OK to say "I don't know the answer to that question- try asking Bob, he may know."
2) Work is an open book test. Sitting at my desk now, I have four different books open, and dozens more closed and stacked close to hand.
3) If you find code lying around that someone you don't even know wrote ten years ago, polish it up a bit and use it, this is called code reuse and is strongly encouraged.
4) At work, code you wrote years ago comes back to haunt you. Programming is like sex- one mistake and you're supporting it forever.
5) At work, code other people wrote years ago comes back to haunt you. "Ted left the company six years ago, but some of his code has a bug. Go forth and fix it."
6) At work, information isn't fed to you in easily digestable chunks. If you're lucky, they drop a pile of books on your desk two feet high, and expect you to get what you need to know out of them (I've had this happen to me). If you're not lucky, you need to find the books yourself (I've had this happen to me too). If you're really not lucky, the books don't exist- have fun! (Yep, that too).
7) College students don't have to deal with tech support calls. On either end.
There are probably more, but I need to go accomplish something.
Brian
Sadly, in the real world most projects are really written largely by one or a small group of "hero" programmers with the rest of the cast and crew along for the ride. My guess is that the people who are the "heroes" were the ones who actually did their assignments, while the idlers are the ones who copied their homework from others.
Realistically, you have to have both: individual projects where sharing is prohibited, so that you can hone and demonstrate your own skills ; and group projects later on, where you can learn to effectively coordinate and work on parts of a larger system. It's no use having group projects in beginning level courses, since really the students don't know enough to accomplish anything and putting them together just increases the confusion. Later on when everyone has mastered basic skills and design concepts, you can benefit a lot from a group project.
The first example had some differences, such as variable names being slightly changed, comments were changed but all in the exact same place, and the logic was all in the same order. Other than that, just a few if statements were changed but in ways where it meant and did the exact same thing, ie,
or
I asked a former professor what to do and she said that in cases like these she has thrown the book at the students. She said even if there is just a hint or suspicion of cheating, it should be submitted to the Dean, but that I should check with the department head. He went the complete opposite route and said that we didn't really have any evidence that cheating had occurred, and to just talk to them and tell them that they needed to work more independently. I thought I had more than enough evidence since one set had identical code. I confronted the first group (identical code) and they admitted to working together. I told them to meet me after class and they admitted to working together. I told them that this was a bit more than just working together and that it wouldn't happen again or there would be consequences. I then had a meeting with the other two and they explained that they did work heavily together, but would never ever copy, etc. I told them that they just needed to work a little more independently as their code was extremely similar. Consequently, the students that were copying did not do well on the exam last week and I believe it is due to them not knowing how to code on their own. Students need to learn to code on their own since most code in the Real World is not already made for them, and the code that is there is written by someone else, and it will be thier responsibility to know how to maintain it. You can't maintain code if you can't code in the first place.
This is similar to what we did at my alma mater. The only addition was that we graded our teammates at the end of the assignment. Usually on a scale of 1 (contributed little) to 5, this was factored in to a portion of the project grade and/or final grade. This was usually sufficient motivation to make everyone do their part and contribute. The professors who used this system let its participants mostly govern themselves. They even suggested working on core competencies, just like a real world situation - if someone better at the input parsing, let him/her do that while another teamate may focus on the mathematics involved.
The best way to teach responsibility is to give the student responsibility.
From my experience, professors do not look so closely at the individual student.
.zip file was. Our project was to make a checkers program in VB. She is not from the USA, so she didn't know how to play checkers. By the end of the semester, she STILL did not know how to play checkers. The exams covered software engineering concepts from the book, not VB code. Its been my experience that the test cover concepts, while leaving the actual code out.
My University does the opposite. With the exception of CS 102 and 103, Java programming 1 and 2, all of our classes are group classes. I almost every case, in a group of 5, 1 or 2 of the 5 would carry the load while 1 or 2 would do virtually nothing.
I had software engineering last spring. Its a senior level class. One of my group members did not know how to send attachments in Hotmail. She didn't know what a
Yes we had a spreadsheet to show our time, we used MS Project. But the problem is the group assignments take up a lot of time while making up only between 10 and 20 percent of our grade. You could get a D in the group, do well on the exams, and receive a B for the course.
My last semester here and I am doing all my work alone. Both my advanced assembler and networking classes use groups. It seems the student learns more when they are by themselves. It is very easy to get by on the back of the group here.