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?
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.
Best Slashdot Co
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
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.
You save only 59 seconds over 8 miles by going 75 instead of 65. Do you really have to pass that guy? Do the Math!
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.
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.
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.
There is an old addage in CS.. Good programmers write lots of code, and great programmers steal lots of code.
(Of course the distinction needs to be drawn between programming and 'true' CS/Information Theory etc, but you get the point)
The thing is, CS education treats programming too much like English - code may be 'speach', but it is not an essay. Yes, outright copying of code is still plagiarism, since you did not do your own work, but...
In the 'real world' you rarely find a situation when people solve the same problem in parallel.. So comparing implementations for 'originality' is not an issue. 'Parallel' problem solving should only be used in introductory courses. After you know the language/concept (around the upper 200 level classes) you should not have many 'solo' projects.
Instead, most projects should be solved by the group, and should be large enough to include a 'project management' component as part of the assignment. The problem should be too large for an individual to address in the time given - barring brilliance. Forced decomposition of the problem, division of the work into separate tasks, accountability on how well each part is done.. These are the things that will make for a successful team project.
Should cooperation be restricted? Not at all, but everyone should have their own area of responsibility.. You can have teams that compete, but better yet, involve the whole class and rotate responsibility.. Allow students to assign roles to themselves, and watch top coders, and star organizers emerge..
Idealistic? Sure.. Will some lazy bums slip through the cracks by riding on the coat-tails of their more talented and industrious peers? Of course.. All systems can be circumvented unless you want a full-time TA watching each student.
So what? These people will only do themselves a disservice in the 'real world' by demonstrating incompetence if they choose the wrong field - or, well, hey, what's wrong with coordinating and pilfering the efforts of others, as long as the job gets done?
If the coders can't make the pieces fit, but someone else can, that someone is a valuable asset to a company.
How many of the Linux developers out there have rewritten the kernel from scratch, just to add a feature? Everyone stands on the shoulders of those who came before.
The REAL jabber has the user id: 13196
What you do today will cost you a day of your life
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.
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.
There are no trails. There are no trees out here.
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:
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.
For small projects, if you talk with anyone or get ideas from websites, etc, you have to cite your sources/collaborators. This doesn't mean wholesale copying of code from sourceforge or friends (as more than one student has discovered), but it at least lets the prof know if you had outside input.
For the team projects I've been on, there were a few methods used to get around some of the problems like slackers and code accountability:
- You pick your team members. If you know that someone is a slacker, you can try to avoid being on the same team.
- Projects involve numerous separate tasks. This helps in terms of delegating code to ALL the team members, so one or two people aren't stuck with all the programming.
- Team member evaluations. At the end of the project each team mate gives a grade to every other team mate (anonymously) for their code quality and project involvement. Each individual's grade is then composited from the Project Grade and each member grade. The assignment can get an A, but if you slack off, you can get a D or even F because your team mates graded you poorly.
Additionally, big projects are broken up into different stages, so you end up having a grade for each stage of the assignment, which is coupled with number 3 (above) to give an accurate reflection of the student's abilities.All in all, the system seems to work pretty well. The nice thing is, if it's a REALLY big project and your team has no hope of completing all the functionality, the prof can still evaluate your abilities based on what has been done.
Maybe not the best, but it worked for me :)
- Jonathan