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?
In college I did group projects where we were required to document our individual contributions. Usually at the head of all of our code was a commented out section marking the dates that the code was modified, who modified it, and what they did.
When I went to University, collaboration was always okay, as long as it was acknowledged. Since 'birds of a feather flock together', this wasn't really a problem (ie: students performing at the same level academically--minus any collaboration--generally collaborated).
"Slashdot is about legos and staplers." -Cmdr. Taco
...can usually tell you who did what and when. We had to use some kind of source code control system for all of our team projects. i don't know if the professor actually went through the check-in histories, but the thought that he could was a nice incentive.
-c
I have discovered a truly remarkable proof which this margin is too small to contain.
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
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!
I was not a CS major, so I can't speak from a pure CS point of view. However, as a Computer Engineering major, I was required and encouraged to take numerous CS courses. One of those courses was a Junior-year software engineering course that required teamwork. While accountability and credit within the group was often a problem, sharing work (including code) was not a problem. Even though that was one of the least technical courses I took as a CMPE major, it did help set the stage for the "real world".
Biodiesel : domestic, renewable, clean, and in the fuel tank of my bone stock 2002 New Beetle TDI
Towards the end of my undergraduate career here, we had plenty of group-oriented projects. Most notable was our Software Engineering class. The idea behind it was marvelous: The class separates into 4-person groups. Each group is responsible for designing their own project. (Being CS majors, most groups chose games, heh)
... you weren't allowed to code the project you designed! You had to "hire" other people in the class to code for you. (In the meantime, you also looked for jobs as a coder or tester for other groups)
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.
-- jchenx
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.
In school I always was put with the lack luster group of students. I later discovered my (good)teachers in HS and college would do this to their smart students. To truly perform, you need to be put in a losing situation and see what you can really achive. As far as real life goes, its always a losing sitution. It can be a lack of resources, mangement (too little or too much), or an impossible deadline. With hindsight, I think it is a great way to learn, if you mess up or get delayed etc. in school, you will not get fired. If you work for a company that knows its ass from its elbow about programming you'll never be left unsupervised. For real projects, you'll have 2+ team members, a team leader and a project manger. School is a place to learn from your mistakes without a pently for making them. Thats why A+ students will always have a manager, and C+ students will always be your boss.
"Get them before they get....
The hard sciences do this all the time, because that's how hard science is generally done--in a team setting.
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.
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.
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
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 and the evil
More at poundingsand.com
My beliefs do not require that you agree with them.
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.
The point is not stealing verses inventing everything from scratch. The point is attribution and the creation and improvement of intellectual property. After all, we are all "standing on the shoulders of giants" when we use things like UNIX, C and day I say Perl.
/. style peer grading within the group. Slackers will get graded poorly by their peers.
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
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.
I Browse at +4 Flamebait
Open Source Sysadmin
I am a student in an Electronic Game Design program at a Canadian College (I myself am American). As a requirement for graduation from the two-year program, a student must be a member of a group that has a final project - referred to as a Product - that is of sufficiant quality to be at the very least an excellent demo in ones resume. Ideally the product should be of sufficient quality to attempt to be published - and at least one product I can think of that has come out of the program has been published as a B title.
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.
In July O7, I got a mac pro. There's no punchline. Just endless joy and wonder.
I cannot claim to be a CVS guru, but I have been using it for the past several months, and trained many others to use it. I have used it in several projects, and started using it for almost anything I write. Maybe I'm a little extreme, but I found it to be extremely useful.
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.
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
Mike O'Donnell http://people.cs.uchicago.edu/~odonnell/
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.