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?
While working in teams is gong to be essential to just about any kind of job, people learn at different paces and in different ways. Working in a team is quite different to learning in a team. It seems to me that teamwork is almost a discipline in and of itself.
Of course there should be team work in college CS and Comp Eng. departments. During my undergrad, we had several group projects, after all, college is suppposed to help prepare you for the real world. There should also be individual projects where you do your own work. That way, when you do get into the real world, you won't be dependent on the rest of your team, and you might be the person the rest of the team comes to for info on certain topics, since you have an expertiese of it from your individual learning. Also, there's a great sense of accomplishment from completing a project that's all your own.
"The best laid plans of mice and men gang oft agley..." - ROBERT BURNS
I remember when I did a programming assignment a few years back in college, where one of the guys in the group and I did most of the work. We had told the professor that the other two were not keeping up their end of the work, but she was stubborn in not repremanding the slackers. The only reason the other guy (who was doing the work) and I continued to do the assignment and carry the other two slacks was to earn a decent grade for the project. My point in this all, it that working as a team can be a great experience if the professor keeps tabs on the situation and ensures that everyone has done their fair share. Thank you.
------
Random, useless fact: I type in startx entirely with my left hand.
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
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.
Carl G. Jung
--
"With one breath, with one flow, You will know Synchronicity" -La Policia
...like, 3 months ago, I was in a CS curriculum that came down extremely hard on Academic Misconduct (I know from experience). The thing was, when all the employers came to recruit, I was inevitably sat down and asked questions such as "Tell me about a time you worked on a team project," or my favorite "How well do you work with others?" Overlook the fact that everyone works with others all the time (in elementary school we are taught to get along with others), and you see that they are asking how well you work on [technical] projects in a team. So, how does a student achieve that all important piece of paper that jobs are looking for while being threatened with non-paper-receiving-ness if they even think about helping each other out, or working together?
"What we elect to call imagination is mere combination of things not heretofore combined." - Frank Norris
When I was in school we had a few group projects. What worked the best was they would group however many the decided was needed. Then we did the work. To be able to grade how each person did with in the group we each graded everyone else in the group on how we felt they contributed.
Nah, my school started us out on hard core documentation by the second computer science course. As soon as we learned the first language language we learned notation to document our work in.
This is similar to what we did. We worked in groups and commented our functions. This taught black box programming, how to work with other peoples code, and how to COMMENT the code. Coders who don't comment their code should be forced to document large, obscure platform, assembly language programs.
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.
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.
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.
In my major, Chemical Engineering, all of the work we do is in groups. They are not formal groups, but we all get together, analyze the problem, then we attack it. Although there is now way to tell exact contributino of each party; it seems to work out pretty well that on each problem someone will come up with that key idea that allows it to be solved. Usually it is a variety of people that come up with these ideas, so no one person feels like they are contributing more than others.
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.
What good is a used up world, and how could it be worth having? --Sting
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.
I'm a junior computer science major at Virgina Tech, and I have noticed this problem myself. I can not work in groups in school, but I will have to when I graduate.
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.
Any one person in the team should be able to complete the project on their own, given enough time to do so.
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.
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.
Share the workload if you can. If you can't, you must be able to do it on your own.
Got Rhinos?
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!"
Evey time one of my teachers gets the bright idea to assign a group project, everyone groans. Why?
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.
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.
------
www.moneybythenumbers.com
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
www.HearMySoulSpeak.com