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?
Group Projects (Score:3, Interesting)
Just acknowledge collaboration (Score:2, Interesting)
Work Study/Internships (Score:2, Interesting)
Source control.. (Score:2, Interesting)
-c
Software teams (Score:4, Interesting)
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 (Score:4, Interesting)
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.
Software Engineering course taught teamwork (Score:2, Interesting)
Software Engineering at Virginia Tech (Score:2, Interesting)
Here's the catch though
It was a wonderful little course that taught us more about communication and design/testing, than merely coding. Also, it's a great class to describe to recruiters who get a kick out of it.
Re:Working as a team (Score:4, Interesting)
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.
Re:Well... (Score:3, Interesting)
Re:See Your Local Hard Sciences Prof (or grad ass' (Score:3, Interesting)
The originality in the "Lab" occurs during the report. Where one explains what was done, why it was done, and what the results were. Perhaps this can be taken into computer science, where the group works on the "code"; but the reports are turned in individually -- each person explains in their own words how the requirements, the design, how the program is structured, how it operates, what it's limitations are, etc.
Re:Working as a team (Score:3, Interesting)
My most memorable CS class was one on software design. During the first week or so, we were to form 3 member teams. As the semester went on, the three member teams were all supposed to be working on the exact same assignment, applying newly learned knowledge to the project. There was specific deliverable at mid-term. Oh, and at mid-term, the class was then required to form 4 member teams. The prof said something about it representing job hopping in the real world (this was in '83, so it's not a new concept, boys & girls). Some teams were necessarily disbanded in order to meet the 4-member requirement. And then the project continued, with more milestone deliverables throughout the rest of the semester, including some rather off-the-wall stuff. It was supposed to mirror the real world he said. We laughed.
And now that I'm older and far more jaded, I see he was right.
And the dynamics of the team was: one guy took over the design work and just handled it. I and the other member took care of coding. Was it a team effort? Not every step of the way. Did some team members contribute more than the others? You betcha. But then that's the way it really works in the real world.
Re:Group Projects (Score:1, Interesting)
Cheaters (Score:2, Interesting)
This is kind of a side blurb, but I thought it might add to the discussion. At my university, I had the good fortune (it was a requirement :) ) to take a basic programming class where we were taught C. We five homework assignments, each one getting progressively harder. Each assignment was logically a computer program, not yet compiled. All work was turned in electronically via the CS school's server.
Anyway, there is a search algorithm that scans the code you just turned in and looks to see if it is similar to any previous assignments turned in. It doesn't just scan variable names and function names, but it also scans the way your program is set up (logic trees?). If it finds a high probability match, it informs the professor.
Some people were really stupid and just copied their friend's homework line for line... some were more clever and changed the variable names. As it turned out, something like 10% of the class was cheating. They normally don't pursue cheaters--ie. the red tape is impossible to cut through to get someone punished, but in this case they did their damndest. This was last year's freshman/sophomore class...
-greesil
"When in danger or in doubt, run in circles scream and shout" -- Lazarus Long
They teach programming, not software development (Score:3, Interesting)
The best course I took was a senior level class called Software Engineering. I worked with 3 other guys on a project all semester, and we didn't write a line of code. We had to come up with requirements, a schedule, a budget, test plans, designs, etc. But we didn't write any code at all. The goal wasn't to program, it was to design software. There is so much more that goes into software in real world companies.
I don't even know if they still offer that course, it was back in '92. I still have the book from it. I ended up getting into Quality Assurance, which they DEFINITELY don't teach you in school.
When I interviewed at Motorola after I graduated, I brought my project from that class. I was to interview with 5 or 6 people throughout the day. I showed the project to the first person I interviewed with, and she said to make sure I showed every other person I talked to. I later found out that it was a big part in getting me the job.
You can talk all you want about "being able to work in a team" but until you do it, you don't know how tough it can be. Organizing, planning around people's schedules, and yes, dealing with people who aren't as motivated as you are all real world applications.
Maybe things have changed in college since I was there (there was no internet back then - ack!). But knowing that the instructors probably are having a hard enough time keeping up with trends, they probably haven't. I think in addition to programming, they should teach sound software engineering principles as well.
Michael
Fight the monopoly [cafepress.com]and the evil [cafepress.com]
More at poundingsand.com [poundingsand.com]
Re:Just acknowledge collaboration (Score:3, Interesting)
Other than that, I've found profs have a supernatural ability to detect who has written what code. In one case a prof not only determined that I and a (rather intelligent) friend had the same code, but that he had copied off of me rather than vice versa.
Plus, being one of the smarter students helping other people out drastically increases your own abilities. And cheating is rare because wholesale copying will be noticed, while anything less just requires an acknowledgement in the homework.
And, btw, many of the helpees (including myself) are now very adept programmers. At least I keep telling myself I am.
It works ok at my school. (Score:4, Interesting)
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: (Score:4, Interesting)
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.
Plagiarism, citation and intellectual property (Score:2, Interesting)
In liberal arts "stealing" other peoples work is called plagiarism and there are well established policies for dealing with it. Of course one is allowed and usually encouraged to read other peoples works and even include them in your own WITH PROPER CITATION. The distinction is that you must cite your references.
The same should go for CS. If you cannot solve the assignment go ahead and use someone else's code, but you should cite it as their code and not call it your own. Calling it your own is plagiarism and the same thing as ripping the copyright notices off of BSD kernel code. If you must use others code, you should try and improve it or you should expect a lower grade.
In a group project there seem to be a few possible metrics. These things seem to mirror what happens in a real world development project anyway in my experience.
1) Allow
2) Define good interfaces and use contract style programming to allow individual members to work independently on their own parts (a class, subroutine, etc.). The group gets graded as a whole on the quality of the design which can be seen in the interface definitions (or problem decomposition if you will) and of course the overall quality of the resulting software.
3) Use CVS and track how many lines of code are committed by whom and when they do it. Lines of code isn't the end all of metrics, but it does show people are doing work. If you look at the commit log and see that one student worked steadily thruout the project period and another hacked it all together in one night, you might take that into consideration too.
Just my $.02.
Dennis
Handling Group projects responsibly (Score:2, Interesting)
It also seems to help to have two parts to the project-- the group collaboration part, and a part that everyone does by themselves beforehand in preparation. It makes it easy for the group to spot slackers and threaten ostracism.
At least, this method's worked well for me so far in combatting slackers.
Group Work (Score:2, Interesting)
In the program, the product development groups form fairly early in Term 2 (the Winter Term) and the rest of the two years in the program is spent, barring breakups and expulsions, working with those same people. The groups spend the first year documenting their product - our detailed design document fills a couple big 5" binders to capacity.
In the second year the product is expected to be coded and built, to the specs laid down in the documentation. There is a prototyping process in place as well that expects a functioning prototype to be ready around the end of the first term of the second year (Term 4).
With all of this time spent working on a major project with a group, with weekly meetings with a faculty mentor and regular design review meetings with a board of instructors, those people who are not doing work are identified fairly quickly. There are procedures in place to remove these people from groups where they are not being productive. In fact, the group I am a member of has such an unproductive person who is skirting right now with removal from our group.
When I came into this program I had only had very negative experiences working in groups at other Universities and in High School. I have learned that group work is very good experience but it must be done over time with a large amount of close interaction with the faculty, so they and the students can constantly keep tabs on the expectations and performance of those on both sides of the classroom.
CVS is the "way" (Score:2, Interesting)
I have then started using it for my school projects. Not only does it create motivation to be creative and innovative, it motivates to actually do the work. So, in a group project, where you are usually required to submit a group analysis, you instead have a log of changes throughout the course of the project. What change there is, who has submitted, when they did.
I have it setup so it cvs logs are sent to a mailing list, and have the groups join the mailing list. It serves as a driver for doing the work. Each time someone submits a change, you get a message, with a short log telling you what has been changed, and who did it. It is a healthy form of peer pressure.
You don't have to write group analsys reports, sometimes avoiding being brutally honest about some of your teammates performance. It's not your problem, the CVS logs will show everything. A web interface is usually the best way.
CVS is the way.
How to make collaboration work at the university (Score:3, Interesting)
I teach CS, and I see at least two related but separate things that we usually miss in classes with software projects:
- fitting class work into a larger context of code;
- collaborating on the software.
Each of these can be addressed by assigning work in definite teams, or by other sorts of interaction. There are at least two obstacles that limit the amount of interaction we allow in class:For some sorts of classes, I've found that I can allow unlimited collaboration, and then evaluate each student based on a private interview in which she presents project work. I evaluate the insight shown in the presentation, rather than whether the student presents her own work or others'. This is very effective in cases where the project work leads to a deeper understanding of the material, rather than merely demonstrating understanding derived from books and lectures. It flops miserably with students who are extremely shy, or who cannot express themselves verbally, but I don't get very many of them.
I have never yet specifically assigned students to work as teams on these projects, but I've allowed them to form teams if they like, and to share work as much as they like. I think that the ability to discuss work completely freely, and to share pieces of code, has helped a lot. But to my surprise, in more than 5 years no students have actually formed a team.
Mike O'D.U. Chicago
One Solution (Score:1, Interesting)
The final exam asked very specific questions about the project that you supposedly wrote. Things like:
Each group had a file that implements frobbing. Your group's file was named:
(a) frob.c
(b) frobulate.c
(c) frobnicate.c
(d) Frob.c
Most groups searched through a graph in some way. Your group implemented this through:
(a) Depth-First Search
(b) Breadth-First Search
(c) Linear pass through all nodes
(d) My group did not search through a graph
Each group had a data structure for storing bars. Your group's data structure was:
(a) A singly-linked list
(b) A doubly-linked list
(c) A simple array
(d) A heap
And then there were a number of questions asking you to identify your group's code from a list of code snippets from each group.