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.
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!
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.
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.
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.
Jack Valenti and the MPAA are to technology as the Boston strangler is to the woman home alone
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.
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/