Cooperation in CS Education? 412
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?
Depends (Score:3, Insightful)
There should be some of both (Score:2, Insightful)
Working as a team (Score:3, Insightful)
Well... (Score:5, Insightful)
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
Cheating as an idea is not applicable (Score:3, Insightful)
That's why us Math majors always did our homework together. Were we cheating? By definition, probably. But did we help each other to understand the prblems and solutions better than we would have otherwise? Definately.
I understand and support the idea that stealing code should be punished, and straight copying investigated. But if the goal is to develop understanding, give the suspects a chance to solve a similar problem, and see if they really understand what's going on.
Way back when I was in school... (Score:2, Insightful)
Re:Oh yeah (Score:1, Insightful)
Re:Group Projects (Score:1, Insightful)
Re:Group Projects (Score:3, Insightful)
Differences between work and college (Score:5, Insightful)
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
Cheating and its consequences (Score:5, Insightful)
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.
Software Engineering vs. Computer Science (Score:3, Insightful)
A computer science degree gives you the foundation that you need to become a computer scientist. It's the background you need to pursue advanced coursework in computer science, in the same way a degree in physics gives you the background to do advanced work in physics. A degree in physics does not mean that your competent to build bridges, despite all you know about the law of gravity, harmonics, and tensile strengths of materials.
Schools need to have two separate programs -- computer science for budding computer scientists and software engineering for budding software engineers. And I guarantee that the demand is for the latter, but most schools only offer the former.
As a former developer, then later system architect and project manager, I found that my CS education was essentially wasted. It's nice to know how to do matrix multiplication using dynamic programming, but I've never used it. I would have traded in my entire algorithms class for a class on testing software. I'd trade data structures for a class on project lifecycles. I would have traded theory of computation for a good design class.
So, yes, I think schools should teach how to work as a team, and there are already ways to determine who does what -- the same way it's done in the real world. When I was a project manager, I knew who was pulling their weight and who wasn't. Of course, as a professor, I'd be too busy doing research and writing grant proposals to deal with my students, but that's a problem with education in general. But here's an example of a solution -- pick the top scorers on the first exam and make them team leaders for the projects. They have to manage the project (as well as code) and they have to evaluate their fellow students. The other students fill out an evaluation of their team lead.
Incidentally, Steve McConnell (author of Code Complete) has written a brilliant book on the failures of the Software Engineering industry and what needs to be done to fix it in After the Gold Rush: Creating a True Profession of Software Engineering [amazon.com].
From the instructor's point of view... (Score:4, Insightful)
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.
Re:Well... (Score:1, Insightful)
What makes you think the real world differs significantly from this situation? Hint: it doesn't, but you gotta substitute "an acceptable performance evaluation" for "a C" and "getting promoted" for "their grade"
Re:Well... (Score:2, Insightful)
This sounds to me to be about the best solution. Teach the basics and grade on that, and then teach teamwork and grade on that. You can't really do a team project if half the members of the team don't understand how to code in the first place.
Then there is the problem of putting the teams together because you have coders of varying skills. One way to do it is to make the teams even in ability, i.e., group the best coders together and then the medium coders, and then the worst coders, but then the less-enabled coders don't get a chance to learn from the better ones.
On the other hand, you can make teams of mixed skill but then there are egos to deal with. The best coders tend to be very smart introverted people that don't always have the patience to work with someone who is not up to their level. They tend to dominate the design and coding just because they are faster and better. It's easier (and more ego-boosting) for them to do it themselves instead of explaining it. The other coders may not learn that much and just get taken along for the ride. This isn't good since neither learns teamwork.
Re:Working as a team (Score:2, Insightful)
Learning a new computer language, by comparison, easy. Dealing with a protocol, by comparison, easy. Getting 5 or 6 people from different continents to not be completely disfunctional? Damn hard.
One team member always wants to do something "new", no matter what he/she gets assigned they'll use some latest feature of language x. Another is a procrastinator, he/she does everything in back to back all nighters the weekend before. Another is extremely disciplined and wants to kill the procrastinator. Another is very quality oriented and wants to kill the "new" feature team member. And on and on it goes. Welcome to the working world my friend, its a gas gas gas
- Ordinarius
Re:Group Projects (Score:2, Insightful)
The way we get around people just copying is that the exams are individual and in class. Trust me, it is really easy to tell when someone just freeloads off all of the others, they tend to fail exams.
I see no reason why in addition to group projects in CS, that there couldn't be exams to test knowledge; or perhaps the professor could interview each student to test their knowledge?
Just some ideas.
Re:Group Projects (Score:4, Insightful)
The best way to teach responsibility is to give the student responsibility.
CS major at Virginia Tech (Score:3, Insightful)
A corrolary of this is that I only see my own code . I can't see classmate's code because that would be an honor code violationg. And I can't see my professor's solution to the problem because they don't want their code floating around, in case they ever do a similar assignment, or if another professor does a similar assignment.
In my math and physics classes, the most effective way to learn how to work out a problem is to see someone who knows what they're doing do a similar problem. There is nothing analagous in my CS classes.
In my physics class, it's encouraged for us to work in groups on the problem sets--it helps us understand it. When I went for help in my first physics class, the first thing my professor asked was if I was studying in a group.
In my programming intensive CS courses (most of them), we work in a void.
This is in direct opposition to the job experience I have had. I continually was asking questions in order to get a better feel for what I needed to be doing. For one of the bigger projects I worked on, it was an aside comment my boss made one time during lunch that prompted me to realize the best way of implementing the system. Real people do not work in a void.
But CS majors do.
Re:Teamwork is irrelevant (Score:2, Insightful)
I don't think so. The purpose of a team in the Real Word is not just so the project gets done faster, it's because in the Real World, not everyone knows everything. Sure, anyone may be able to get through the whole project by themselves, but that would be after a whole lot or research and learning completely new things.
The teams allow people with different specialties to come together and share their expertise, with each of them working on the part of the project most suited to their area of expertise. There are very few people who are experts in all areas of any decent sized project.
Joe may be great at network code, and even know XML and HTML, but he may not be able to code his way out of a paper bag in Java. Sure, he could learn Java, but that would take time, whereas Sue knows Java, and can also do interface design, but she doesn't really understand TCP. Sure, she could learn TCP, but that's a lot of time when instead we get these two working together along with Bob and Aaron, and soon we've got experts in all sorts of areas and some cross-over expertise and we can get a complex project done.
There are few projects in the real world that can be done by just one person. With source code in the millions of lines, it is not feasible or realistic to expect everyone in the company (or the department) or the team would be an expert or even be familiar with all the code in a complex project.
Re:Well... (Score:4, Insightful)
That sounds exactly like where I work. I don't know where you are employed that you think this
doesn't teach you much about the work force
but I'd be interested in hearing if they're hiring.
Re:Group Projects (Score:4, Insightful)
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.
Absolutely (Score:3, Insightful)
Share the workload if you can. If you can't, you must be able to do it on your own.
Re:Way back when I was in school... (Score:3, Insightful)
For comparison to other policies, the rule of thumb is that when one leaves a meeting with other students, one takes no notes.
So, how does a student develop practical, real-world experience working with others on large projects and demonstrating language fluency? Easy. That student works on Free Software projects.
- Large project. Check. Bigger than any school project.
- Real-world. Check. Software may be in use all over the real world, on thousands of machines.
- Working with others. Check, potentially thousands.
- Language fluency. Check.
It's all there, plus you get to make software that you can use yourself, rather than something that has no other purpose than to demonstrate your knowledge.Sheesh. (Score:1, Insightful)
I understand that collaboration is wonderful and instructive, but you are bound to the rules set by your university/CS department. And I'm sure that those rules seem horribly unfair. But in the true Slashdot fashion, instead of trying to change things at your school, you come here to whine about it! And since slashdot always seems to have a good crop of naive college students who have nothing better to do than post comments, you get plenty of your peers to whine with you.
Kids, pull your own weight, or make waves where it counts. Trust me, your university isn't going to give a shit about 200 slashdot comments backing you up, probably because they know that the people posting on slashdot are at least as lazy as you are.
Or at least find another forum to post this on. Don't worry, Slashdot will still be tiresome and repetitive without the whinings of "I want do do my homework as a joint project with my friends!"
Group Projects Suck (Score:3, Insightful)
These projects pit you with people you don't know, and don't care to know. They don't want to do the work, and they are happy with making a C. However, if I want to make an A, I have to make up the slack. Inevitably, there is always at least one person that just doesn't care. Everyone else suffers.
The real problem with this is that, in the real world, you can fire someone if they don't do their job and replace them. In a group project, you never seem to have that luxury. Instead, you are stuck pulling the weight of the slackers who don't care.
Additionally, group projects seem to waste a lot of time because of the need for consensus. In reality, design by comittee is very problematic. However, you often can't explain that to group members. They see it as one person dictating his or her ideas. Sure, you need other people's input, but the endless back-and-forth trying to agree on something just wastes everyone's time. Additional time is wasted on all the communication, and the need for meetings. In real life, everyone works the same hours (or a reasonable approxiamtion thereof). That way you can just pick meeting times and be confident that its not going to be a problem having everyone attend. In a school project, you have to schedule meetings around everyone's work+home+school schedules. Often it means meeting late at night, or on the weekends. Who wants to waste their weekend time meeting for a stupid school project?
The only real advantage I see to most group projects is the one for the teacher: less grading.
I think a better idea is to encorage pair assignments. It's been my experience that I get a lot more out of a 2 man "group" than I do a 3, 4, or 5 person group. Its easier to communicate, easier to divide responsibilites, and it makes it possible to share information and approaches without losing a lot of time. The project has a much more cohesive feel to it, and the concepts are better represented. However, the pair approach still has the problem of the disinterested party. Encouraging students to choose their own pairs would help to alleviate that, as students often take classes with a friend.
Group assignments do have benefits, but I think the problems that go along with them in a school setting tend to outweigh those benefits.
Group Projects Done Badly (Score:2, Insightful)
In classes that teach basic programming and other CS concepts, I think students are much better off writing their own programs and doing their own work. How else are they going to learn these basic skills?
There are classes where group projects may be appropriate if done right. The classes I'm thinking of are software engineering type classes where much of the subject matter centers around being able to organize projects into modules, code the modules, and integrate these modules together.
However, if a class is going to teach teamwork, it's actually got to teach it. Professors can't just divide up the class in to groups of N, give them a project that is N times a normal, single-person project, and let them go. As others have pointed out, that is a recipe for disaster!
They actually have to instruct them in how to go about dividing up the work, designing interfaces between modules, integrating code, using source control to track changes, etc. Otherwise, they aren't really learning how to program as part of a team.
Some colleges (like mine) are project-oriented (Score:3, Insightful)
Once upon a time this was the only system WPI had -- classes were really only for learning what you needed to know in order to make progress on your project, forget about grades. But toward the end of the 70's they started to get pressured to come up with a system that would more easily allow students to transfer credit when leaving the school. By the time I arrived in 87 they were shifting away from the 2grade (AD/AC) system they had developed into three grade (ABC), but the projects are still central to your grade. If you spend 16 class units on your project and get an A on it, then 16 A credits go onto your final transcript. Not bad. And by the way you don't "fail" courses at WPI, you simply receive "no record" that you ever took the course.
When the teachers and students both agreed to this system, it worked well. Many's the time a student would fail a course because he was working too hard on his project, only to have the teacher let him squeak by because the teachers knew that the class grades were a formality. I deliberately failed one class because the teacher had set it up so that the project work (writing code) was about 40% of the grade, while the two exams were 60%. I aced all the code and failed the exams, on purpose, and told her "I came here to learn how to write code, not how to memorize answers out of a book so you can write an arbitrary letter next to my name in your book." I got a 67 in that class, which is failing at WPI, but she gave me a C anyway.
Did you sometimes hate your partners? Of course. Just like in real life. Did your partners sometimes get credit for work they didn't deserve? Yup. There's no good fix for that problem, that I can see. But whether your project works perfectly or fails miserably, it's all good lessons for the real world. I have many stories from college projects that I still use with my employees today (and none of them start with "This one time, when I was hammered.....")
For the record, my humanities project was an examination of the approach to the tragic hero in Shakespeare (Hamlet), O'Neill (Long Day's Journey), and Miller (Salesman). My major qualifying project was teh development of natural language software for educational purposes, and my interactive project was to gather a day long workshop of teachers and discuss the impact of "highly networked sources of data and information" on how children would use the computer in the classroom, specifically social studies. Did that in 1990. So the projects were no small potatoes.
d
Re:Differences between work and college (Score:2, Insightful)
You also just described research degrees... as far as I can tell so far (6 months into a PhD..). You base your work on other people's previous work... you just acknowledge that previous work. The difference is that when there isn't a book on what you're doing, it's a good thing - you've just found your thesis subject.
And you do have to deal with tech support calls.. from students.
Kind of funny, when academia is the original model of the continual development of a single body of work, and they spend their time trying to stop students doing similar. This gets really tricky with languages like MIRANDA and PROLOG, where there are very few ways of solving simple problems. Hell, half my assignments in these languages were sets of one line programs - how much originality can you show in one line?