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?

Group Projects

[NitsujTPU]

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.

Re:Group Projects

[Sir_Real]

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.

Re:Group Projects

[Bastian]

in my school, we did a very similar thing, but all our work is done on a Sun450 that the professor has root access on. All we have to do is use RCS or CVS, inital all our comments, and comment what we did when we check in the code, and the professor has a script set to run at the due time that snapshots all the log files.

Re:Group Projects

[SonCorn]

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.

Re:Group Projects

[scottnews]

From my experience, professors do not look so closely at the individual student.

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 .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.

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.

Re:Group Projects

[stilwebm]

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.

Re:Group Projects

[scott1853]

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.

Doesn't this lock people down to one aspect of development? At the college level, they are most likely better at one specific task because that's all they've learned so far. Isn't the point of college to become well versed in many things, not just one small part of the industry you want to join?

My experience comes from working in a small company, but my tasks include website design, graphics, CGI, admin, application design and coding both new and maintaining others code, all using mathematical, logic and creativity skills. I'm not the best in the world, but all these skill were aquired over a couple years and I'd like to think that while I'm not quite to "guru" status, I'm at least in the "advanced" category. I wouldn't have learned so much from being type-cast as a webmaster or a application programmer. That's not what a programmer is. A programmer knows how and what commands to send to a computer to make it perform a specified task. The actual task is irrelevent. HTML, Perl, C++, they're all just interfaces to commands.

Re:Group Projects

[stilwebm]

I guess I should have phrased it a little differently. While it did leave some people to focus on one skill in all projects, the professors varied the projects enough that it was virtually impossible for a user to only ever focus on one or a few skills. The rule was invoked more to avoid grading less capable people poorly when they contribute more resources (esp. time and effort) to the project. Also, most classes where this rule was used, the groups were assigned at random. It was fun in some classes, like one where about 50% of the class was Japanese nationals. It was great experience, because otherwise people would tend to stick to groups of their own nationality.

If someone did stick to a specific skill and avoided learning how, say, neural nets work, they would likely bomb the next test. Also, few classes consisted solely of group projects.

Just acknowledge collaboration

[Miles]

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).

Re:Just acknowledge collaboration

[karb]

Yeah, at my college too ... since the smarter students were bound to help the smarter (often non-major) students in CS classes, our profs legalized it as long as the assistee mentioned in their prologue the students that had helped 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.

Work Study/Internships

[PinkStainlessTail]

It sucks, but on some level the classroom isn't about cooperation, but about individual achievment (or at least meeting of standards). The best schools to my mind, give course credit for work study programs and internships where you not only get to hone your skills, but might also get some exposure to how you're eventually going to deal with people in the real world.

Source control..

[Smallest]

...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

Depends

[jiheison]

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.

See Your Local Hard Sciences Prof (or grad ass't)

[Zoop]

The hard sciences do this all the time, because that's how hard science is generally done--in a team setting.

My dad teaches occasionally at local community colleges (physics) and has labs. Sometimes he counts on the students to police one another (political but doable) and sometimes he has a monitored lab where they do something at the bench and he can observe who is just hanging back or simply copying results into the journal, etc.

So, not being in the position myself, I'd suggest bringing up the idea with some physics or chem prof who does this sort of thing who you may have run across. If they're at all clueful about computers, they might have some interesting ideas, or at least tell you enough for you to bring up a concrete idea to a CS prof you know and have a good rapport with.

Re:See Your Local Hard Sciences Prof (or grad ass'

[ClarkEvans]

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.

Work vs. School

[FortKnox]

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?

Bad news for you. There isn't a way to tell who's pulling their own weight out in the workforce.

Sometimes the slackers are "lucky" enough to get on several hard working teams and get promoted.

This is how some managers are just morons.

My perspective as a current student

[dozing]

As a current CS student many of my classes have encouraged working with your fellow students when you get stuck. We've had a few group projects in several classes and I think its very important to have that experience at working in a group. Sometimes you get stuck in a group of people who don't know anything and you end up pulling a lot of the weight, but that just prepares you for working in the real world.

Software teams

[wiredog]

My first job, lasted 5 years, I was the only programmer in the company. At this job I'm on a team, but I'm the C++ Guy. We also have an Oracle Guy, An HTML Guy, etc. Just because you're part of a team doesn't mean that you won't be by yourself much of the time.

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.

There should be some of both

[Ghengis]

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.

Working as a team

[NewbieSpaz]

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.

Re:Working as a team

[cavemanf16]

...and to add to your comment:

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:Working as a team

[ordinarius]

This is _exactly_ the point. I know I used to think that the main challenge of software engineering was technical. Ha. Surprise! It most definitely is not.

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:Working as a team

[nick_danger]

Way back in the days of yore, when I was in college...

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.

Well...

[khyron664]

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

Re:Well...

[Quizme2000]

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.

Re:Well...

[Logic Probe]

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.

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:Well...

[bteeter]

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.

Oh boy can I tell you just graduated from college. What you just described is _exactly_ how it works in the real world.

Very, Very, Very rarely will you be fortunate enough to have an assignment to complete on your own. The vast majority of the time you will be working with a team. A team consisting of:

• 50% Morons
• 30% Unmotivated sloths who surf the web all day
• 10% Motivated, yet incompetent programmers who produce the most buggy, god awful code ever.
• 10% Motivated, Competent programmers

No this is not an exageration. This is how the real world works. The 10% of us who can pull our own weight often times pull the weight of the other 90%.

I've never had the pleasure of being on a team where a majority of the team members were usefull or productive. Perhaps I'm just really unlucky. If that is the case, I hope you end up working with a better calibre of folks than I have!

Take care,

Brian
100% Linux Web Hosting - 0% Windows [assortedinternet.com]

Re:Well...

[Rupert]

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

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:Well...

[dillon_rinker]

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.

You had me up to the bit I've bolded...since you are recently graduated, you clearly haven't yet realized that what you describe is EXACTLY how most teams work. It sounds to me like you have had some EXCELLENT real world experience and have learned a LOT about how the work force works. You labor under the misconception that graduation magically changes all those mediocre people into excellent. If you are extremely lucky, you will land in a team where everyone works their tail off and is dedicated to success rather than adequacy. Should this occur, hold onto the job for dear life.

Meanwhile, reflect on your experiences with teams in college. Learn how to motivate your peers. Let me know if you ever figure out how to turn a lump into a go-getter...

Teamwork is a really big deal

[0xA]

I don't think I've ever been involved in a coding project where I haven't been part of a team. I think it would be really helpful for CS programs to do more team based assignments but it probably goes a little deeper than that.

The more experience you can gain working as part of a team the better. Try spending time in fun projects sponored by you're local LUG, or the chess club or whatever. The other thing that will help a lot with this is sports, I played all kinds of team sports (hockey, football, rugby) when I was a kid and I think the experience really helped me with my proffessional development. The time I spent coaching a bantam (14 and 15 year olds) football team in high school was especially helpful when I became a team leader a few years ago.

In short, it wouldn't hurt to push for more team based assignments but just about any experience you can get working or playing with others can be helpful.

Cheating as an idea is not applicable

[well_jung]

Really, how can cooperation be discouraged the way it is in CS? What it comes down to is problem solving. Small groups are ALWAYS better at problem solving than an individual.

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...

[KaiserSoze]

...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?

Re:Way back when I was in school...

[Xofer D]

This is a constant debate in the School of CS at my university - should schools be doing more practical training? My univeristy provides students with theoretical knowledge, and leaves practical education to the individual. Assignments are "implement this, using these language restrictions", just as in many other programs; learning the language(s) specified is up to the student. Group design work is encouraged, and group coding is discouraged. I agree with this policy - nothing is more frustrating than finally seeing the fruits of your labours, and not getting the credit for it (in a curved classroom, cheaters are stealing marks).

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.

1. Large project. Check. Bigger than any school project.
2. Real-world. Check. Software may be in use all over the real world, on thousands of machines.
3. Working with others. Check, potentially thousands.
4. 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.

My take..

[mgoyer]

I find that for CS assignments where I'm supposed to work in a group I just end up wanting to do the entire assignment myself and not depend on anyone else but for individual assignments I often find myself talking to friends to find ways to reduce the overall assignment time. Kind of weird, but that's how I am.

Though, overall I find that my school is very afraid of 'excessive collaboration' but the only reason that there may be excessive collaboration is because the professors and instructors are out of touch with the students and don't actually understand how difficult the assigments may be.

Just this morning our prof tried to clarify our latest assignment and failed miserably. He then concluded that he thought that it was an easy assignment when I bet you that only 1% of the class would agree with him. So of course there will be excessive collaboration because obviously no one wants to fail.

Matt

In ebgineering...

[Drakula]

...it is already done quite a bit. The system I went through did a poor job of determining who did quality work and/or pulled their own weight. But unfortunately, that is what it is like at a job. You work with a group people, some do their job and others don't. I guess what I'm saying is that school prepared me for working with people, but unintentionally.

I also believe that you can never rely on a university to teach you anything about working a real job. Just talk to employers, they are always complaining about how students are underskilled. That is why they don't expect anything from you for the first year or so.

The only naswer I have seen that worked well was the co-op program. If you are at a school that has strong industrial ties then yo uare all set. Otherwise, you have to learn as you go when you get out.

Grading group projects

[DudeTheMath]

As a math instructor at the Univ of Michigan, I assigned all homework in a couple of my classes as group homework; but each individual reported separately on both their own contribution and that of others in the group (just a sentence or two).

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.

Think about it like math...

[Gogl]

I'm a freshman comp sci major, taking both a comp sci and calculus class. The reason I mention the calc class is because it's upper level and basically entirely proofs, which are surprisingly like computer programs. Both of these classes take essentially the same attitude towards cheating: if the person grading your code/proof sees that it looks suspiciously like somebody elses then you might get talked to.

However, the two are different in this aspect. Comp sci basically says "don't work together". Math, however, encourages teamwork. Here's what they suggest. Get together with other people. Get a bunch of scratch paper, or even better, a blackboard. Solve a bunch of the problems together, but then break up, go home, and do your final draft alone. This means it will be your work. It will look like you, and be slightly different from everybody else, especially if you did most of the group work on a blackboard and therefore don't have it to copy straight.

So when in doubt, don't copy word-for-word other peoples code or proofs or homework in general. However, working together in the name of generating ideas that nobody individually can get is a good thing, at least in my book.

The problem

[Shotgun]

With team projects that I have experienced, the professors always expect to step back and give one final grade across the group. I usually ended up just doing the damn project, because that was a lot easier than trying to teach the lamers I was stuck with how to code. The lamers didn't mind, 'cause it was an easy A for them (I graduated with a 3.89 GPA). The situation always pissed me off. I paid to be taught, not to babysit lamers. But I wasn't about to let my GPA suffer out of spite.

The way it should have gone was that the professor should break the project down into parts, and each student would be primarily responsible for his/her own part, with some portion of the grade coming from the overall completeness/quality of the end project. Lamers would then be responsible for themselves, and some actual communication would have to occur, because the lamers would have to ask more than, "Is it working yet?" Of course, this would require the professor to accept the role of a manager, and would require at least a cursory participation in each group. Which is why this doesn't happen.

Software Engineering course taught teamwork

[DaveWhite99]

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".

but make it a useful focus on teamwork, please

[ethereal]

I had a number of team projects in school, but unfortunately most of them did not teach the team skills that I now use at work. Most projects were small (2-3 person) teams, fairly limited in scope, with a clearly-defined direction from the course instructors. These projects were easy to resurrect if one person didn't pull their weight, and usually became mostly the work of the person with the strongest personality on the team.

In contrast, most "real world" teams that I work on are large (up to 10 people), require the direction and many of the major decisions to be decided by the members of the team rather than imposed from outside, and require a lot of finesse to reconcile the opposing viewpoints of the many opinionated people on the team. A lot more of the work goes into deciding how to decide what things will get done, because once you're out of school, the question of how to do things is mostly a known factor (based on corporate-provided development process and the abilities of the developers). The workload of this larger team is enough that one person couldn't carry it alone (well, without putting in 100-hour weeks, which was fun when you were 20 but maybe not now) and even if one person had the ability to do so, the rest of the team wouldn't take kindly to being left out of the loop.

I did have one class that focused on large-team development and real-world problems like this, and I probably learned the most from it as I did from any course (thanks Prof. Mowle!). But looking back, we probably should have had several courses like that, and in fact most of the last year of school should have been focused on team-driven development projects like that. Colleges are kidding themselves if they think they can grade students on their separate work, when in real life they'll spend the majority of their time building on the work of others. Grading on team projects can be done reliably - for example, we had weekly status reports for each developer to make sure that you were keeping involved, part of your grade was based on your peers' estimation of how useful you were to the team, and the remainder of your grade came from the "management" (instructor's) view of how much you had contributed. Which seems to mirror my real world job pretty reliably, come to think of it.

no group work

[wishus]

At my school we didn't do any group projects, and they made sure you knew what you were doing by making you hand-assemble self-modifying code on the final.

So I didn't have any "team" coding experience until I got my job. I don't think I missed out on anything though - if you can debug code on the final, you can debug code a teammember wrote.

When it comes to designinging a product, things are a little different. You sit around and argue high-level implementation for a few weeks, but when you go to code it, it's still just like coding in college.

Except that you are making something cool and not just another program that prints out fake bank recipts.

This DEFINITELY needs to change

[Uttles]

First of all I'd like to bring up an old story by Cliff on academic dishonesty [slashdot.org] that was posted by a friend of mine in a class I took in my last semester at a certain university. [clemson.edu] In this class, students were all given an assignment where they had to work seperately but could share ideas, just not code. However, when the students actually did this, they were punished (the article goes into greater detail.) The very principle of that punishment is directly contradictory to the real world, where people discuss ideas all of the time, constantly, in order to work effectively.

On a more positive note, I have to say that in my last 3 semesters of college (computer engineering curriculum) I had some rather enjoyable project classes where I worked on teams of 2 to 4 people and the experience was moderately similar to actual real world working practice. I think teamwork in education is essential and should be 50% of the curriculum. In most of my classes while in school we had labs where we worked with others, yet those projects were rather small and insignificant. I think schools should focus more on semester long or even year long projects for their computer engineers and scientists as there's only so much about those subjects you can learn from a book, the rest is really just hands on.

Our group projects

[Telek]

We chose our own groups (which usually helps to cut out the crappy people), and then the *group* was assigned a grade. We multiplied that grade by the number of people and then we each assigned every member in our group a grade. The grades per person were averaged and that was the grade that you got. This was done anonymously, so if someone didn't pull as much weight as you thought that you did, then give them less and that's more for the rest of you. I think that this idea worked out pretty well, too bad it wasn't used more often.

Differences between work and college

[bhurt]

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

Re:Differences between work and college

[mtrupe]

How about this:

Programming is a lot like sex. I tend to get very confused and make many mistakes in the process.

Re:Differences between work and college

[ivan256]

#6 is missing an part... They give you a stack of books with the WRONG information in it!

That sucks.

Re:Differences between work and college

[DeadMeat (TM)]

7) College students don't have to deal with tech support calls. On either end.

Hmm, apparently you haven't been around my dorm room lately.

Peer assessment

[Malc]

My very first year of Uni. for BSc. (Hons) Comp. Sci. involved a group software engineering project. One of the big factors towards our marks was peer assessment. We had to individually assess each member of the team and discuss this the professors running the course. I think this was fair, effective, educational, gave the lazy bastards in the team a wake-up call, and ultimately has turned out to be representative of how every company that I've worked for operates.

Slackers!

[sid_vicious]

Maybe it was just my personal experience, but *almost* every group project I was on had at least one or more absolute slackers.

It's very frustrating to have to pull these peoples' weight. To be honest, I would rather just be graded on my own ability to perform - when you have four people, profs tend to expect 4x the quality of work they would get from one person. You get one slacker, and now four people have only produced 3x the work, and everyone pays for it.

Don't even get me started on having to deal with group dynamics when you end up assigned to a project with a complete jackass -- but then, that did help me prepare for a Dilbertian experience in America's workforce.. *sigh*...

It depends...

[mmaddox]

It depends primarily on the focus of the course itself, and the role of the university in teaching teamwork and social skills. For instance, the University of Phoenix considers the team an integral part of its learning experience, so their classes focus on the team project (including programming courses), with a part of the final grade being a grade based on your teammates' perception of you. Thus, the university really attempts to integrate the technical material with a team-based environment. Granted, the individual grades are more difficult to arrive at, but what's really the goal here? To receive a grade that is appropriately scaled within your class, or to receive a GOOD grade and learn something?

Other colleges, of course, don't follow such paths. Ga Tech and UGa both follow a more traditional course structure, where the technical material is excellent, but making use of that material in a team environment is not stressed. Only certain graduate-level courses really use teams, generally in circumstances where a professor's research project is involved. Here, of course, the technical material is MUCH, MUCH better than the UoP, but it's rarely presented in a real-world environment. Again, you just try to get something out of the course, and receive an appropriate grade.

Make up your mind that college is NOT about preparing you for reality, and it's CERTAINLY NOT about competing for silly kudos against your classmates. Pick up whatever useful you can find, then run like hell. Or, of course, just run like hell (like I did). Experience in the real world is a much better teacher than college.

Not unique to CS...

[singularity]

It should be pointed out that this is not unique to CS. As someone else pointed out, most of the hard sciences are the same way. I think you could go ahead and argue that most any field is the same way.

I was a CS major for three semesters and while there was some colaberation, there was not a lot. Of course, that may have been unique to the school. Later on, as a math major at a different school, there was a lot more. Homework was worked on in groups, or at least compared. I think this happens quite a bit.

I think you could easily write an Honor Code that covers this sort of situation. I know that when I helped people with their work, and when they helped me on mine, I made sure that there was not just rote copying, but actual understanding of the underlying concepts.

So you just have to make sure that Honor Code assures that you are helping students out as peers, and not just letting someone copy. Defining what that means could be up to the Judicial Administrator and the school.

One real test (no pun intended) is the exam. One of the many reasons that my classmates made sure we understood certain problems was that we might see it later on the exam. It does you no good to get that 1 point on a problem set by copying if it them means that you lose 10 points on an exam because you did not know how to do that type of problem/proof.

Work in groups, but be ready for individual exams (although written exams were always so strange in a CS class).

Assessing performance in teams

[CrosseyedPainless]

I'm taking a course [nau.edu] at Northern Arizona University, which focuses on team design and implementation skills. For evaluation, we use peer reviews. Team members contribute to an average factor which is multiplied by the team grade. The faculty member supervising that team gets an offset he can add (or subtract) from the raw score. Seems to work, assuming you don't piss off your team or teacher (which seems pretty much like RL).

Software Engineering at Virginia Tech

[jchenx]

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)

Here's the catch though ... 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)

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.

59.311 - Software Engineering

[Chris Brewer]

Down here in New Zealand, a paper I did in 3rd year had it's main assessment from a team based project. We joined into groups of about 8, elected team leaders, and organised everything from defining the requirements to giving a 'sales-pitch' presentation at the end of the year.

Part of the assessment of this project was from us as individuals assessing our team members, and their contribution. Another part of the assessment was from the presentation where the other teams gave us marks.

As an aside, the top 3 teams (my team was one) redid their presentations in front of the Chief of Sun Microsystems NZ, but while his assessments weren't towards our final marks, it did help one of the guys in our class to score a job with Sun and become the first Java programmer in NZ.

There is no I in team... blahblahblah

[Rackemup]

Every time I ended up in a group project I had to do most of the work. It didnt matter how much planning we did, no one pulled their weight. Maybe that's why I hate programming so much now.

In first and second year CS classes I can understand why a prof would want people to work on their own projects. It's an easy way to see who's learning the basics and who doesn't have a clue.

By the time you hit third and fourth year there should be lots of group projects and collaborative efforts to get people used to working in the real world.

Sadly my college viewed CS as "part of the math dept" and put most of their money into the arts programs (this was only back in 95-99). Had they put more effort into developing the CS program, hiring more profs and developing the curriculum they could have had a nice program. Maybe things are different now, but I doubt it.

Cheating and its consequences

[Phaid]

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.

Absolutely

[zpengo]

Coders that learn to depend on other people will find themselves struggling in a world where their coworkers will range anywhere from heros to zeros.

Share the workload if you can. If you can't, you must be able to do it on your own.

Good ole' fashioned tests?

[ClarkEvans]

This is *exactly* the reason why I have a B.S. in Mathematics instead of computers. In my opinion, students should be allowed to chat and share ideas on their programming assignments -- even copying is good, as long as the student learns the subject matter. Here are some ideas...

1. Give frequent quizes, mid-terms, and final exams. Construct these tests so that it covers ideas which one would have to struggle with when solving the programming assignments.

2. Give an incomplete program (their own?) and have them complete one of the classes or functions. If they really wrote it (or understand the concepts), this won't take long at all.

3. Focus on "ideas" and "history". These are very testable, and probably a better yardstick. Use in-class essays; hire grad students to help grade them.

4. Have group projects to *encourage* knowledge sharing. Have each person write an essay about what they learned from the group project. Grade the essay, not the program that resulted.

5. Focus more on requirement gathering and other "fuzzy" stuff as well as the concrete programming. Give room for the those with good communication skills to shine and partner with those with good technical skills.

Just thoughts...

Individual work is too important

[bartle]

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?

Just like in the real world, a team is a haven for slackers. Far too many people got through my CS classes simply because of who they knew. Insofar as college is designed to accredit individuals, it is necessary for nearly all of the work to be done as an individual.

Now most of the problem is that when students divide into teams, the instructors have the tendancy to view the team as a single entity. College professors are an unsympathetic lot and the easiest thing for them to do is judge the team with an external eye. Once the team members' fates are linked, it is often times easiest for the most industrious students to simply take on the burden of the work. It is rare that I see a team in which the doesn't occur, in both academia and the real world.

I understand where the author is coming from, I learned a great deal during the little time I was forced to work in a team in college. But my lessons were in politics and sociology, relatively little computer knowledge was involved. Students should spend some time in groups, but not too much. It is nice in some ways for college to be more idealistic than the real world.

My experience

[Dop]

I had one course on software development processes. Where the group had to design what they were going to do, write the code, and run tests on the code to make sure it works. The problem with this kind of work is people like me. I hate groups. I knew I was the strongest coder too.

I wrote all of the code one morning before ever having the first group meeting. I didn't want to deal with having them argue about how to do it and having it take several days. Then I told them to do the testing without me.

I realize this doesn't work in a large corporate environment, but when it's a small project for a class when you've got other classes and work, there will be students that do the work on their own faster and don't care if the other students take credit for it or not.. just as long as yours truly gets a decent grade. The rest of the group is likely to go along with it because it's less work for them.

So basically, I think it's very difficult to pretend that people will react the same way in a classroom as they would in a corporation. The fact of the matter is, a lot of students initially show up at college to learn, but in the end they just want to get the hell out of class so they can play on their own.

Technical University of British Columbia

[talonyx]

I attend the Technical University of British Columbia, and almost all of our IT work is done in teams. We have to write up our contribution and grade others on the amount they have done for projects.

Coding styles can be hard to combine, so often we each write routines with standardized ways of having them talk to each other instead of directly working on the same code. Probably when we get better at it, we'll be able to adobt a GPL style development system, with everybody checking each other's code and being able to figure out what the heck it's supposed to do! :-)

Software Engineering vs. Computer Science

[ctrimble]

By and large, if you're getting a degree in CS from an American university, you're not learning how to write software applications that will be deployed in the Real World. You're learning about things like algorithmic complexity, data structures, NP completeness, and other theoretical issues. Now, these things are nice, but I've never been on a project that's failed because someone used a linked list (O(n)) instead of a hash table (O(1)).

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].

Does good SE come from good CS?

[Anonymous Brave Guy]

By and large, if you're getting a degree in CS from an American university, you're not learning how to write software applications that will be deployed in the Real World. You're learning about things like algorithmic complexity, data structures, NP completeness, and other theoretical issues.

Would that that were true. From what I've read on-line and the people I've met, what many US universities are teaching in "computer science" courses has precious little to do with CS. Witness the number of courses teaching "Windows programming", or the slavish following of the language of the day (currently Java).

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.

I respectfully disagree. Most of the good software engineers I know are also good with computer science. They understand the significance of data structures and algorithms, in particular, when it's important to use a highly efficient one, and when a simple solution will do. They understand the underlying principles of OO design or functional programming, not just the syntax of Eiffel or ML, and they design and code much better as a result. Most important of all, they know when to look things up, and where to look, because they have a broad exposure to the field.

Now, don't get me wrong. Software engineering as a discipline does not come for free with CS knowledge, and I do agree that universities teaching CS should consider teaching basic SE skills as well (e.g., project lifecycles, why we have different types of testing, the pros and cons of different development models). However, from personal experience, the average CS prof is woefully unqualified to teach these things. This knowledge isn't theory, it's practical, and such knowledge comes from time in the industry, not time as an academic. Much of the SE taught during my CS course was 20 years out of date, and quickly unlearned when I started as a professional developer. Actually, one of the smartest things they did on my course was get a few successful alumni in to give single-lecture presentations on their experience. That was in Business Studies (aka "The basics of running your own company") but it would be just as applicable to Software Engineering, IMHO.

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.

I could have done without the massively theoretical subjects, such as Computation Theory. But give up the basic stuff? No thanks. I've used the basics of Numerical Analysis (aka "How floating point works"), Data Structures and Algorithms, my Graphics and Databases courses, and more, not to mention investigating the ideas I first encountered in the various language courses, which I'd probably never have seen without doing the CS.

So, while I appreciate your point that Software Engineering is not Computer Science, I ask you: does good SE rely on good CS as a basis? Can someone possibly be a good software engineer without a basic knowledge of CS (whether or not they learned it on a CS course)?

what do you expect

[KevinMS]

School evaluation often involves completely artificial situations that have nothing to do with real worl application of the knowledge you are learning. Flame on please.

It's the assignments that suck

[gelfling]

Back in the Middle Ages when I went to school, the assignments were boring and rote and professors and GA's would mandate that there was ONE solution. Feel free to think freely as long as you do exactly and only what I'm thinking of right now. So of course all the assignments, if they were right at all, looked nearly identical.

The problem is that in the workplace this is a GOOD thing. It's called good change management and version control. You want a consistant repeatable way to do something even where, especially where it is not optimal. In the workplace there are rarely if ever purely isolated competing teams trying to solve the same problem. Maybe that's a luxury in some specialized arena like embedded systems defence avionics or strategic weapons systems but in the commercial world that never happens. At least not to me in 20 years.

From the instructor's point of view...

[blazin]

I teach a data structures course at a Colorado university (not CU). Two weeks ago, I had two students turn in nearly identical code, and two others turn in completely identical code, down to the exact same spacing and comments. There was no difference in the second.

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,

if (a) b(); else c();

or

if (!a) c(); else b();

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:From the instructor's point of view...

[pi_rules]

I was in a CS program for a few years, and I agree that during the very early courses students should be watched carefully for blatant copying. However, as others have noted here, hard scienes are usually something people work on in groups. It was never uncommon for the CS students around me, myself included, to ask questions of other programmers. When dealing with a new language and unsure of the syntax you'd ask the guy next to you what in the world was breaking the compiler. He'd point it out, you learned, life was good.

Quick and easy way to tell if a student was cheating... when they hand it in, look at the code and ask them a few simple questions about it. Even if you "cheated" by copying another student's code as a template, re-worked it line by line until you "got it" so long as you can actually explain what the code is doing, and why, what's the harm in that? Granted, I'm assuming that the person you're learning from -knew- you were using their code. Poking around on the network and grabbing some other student's work behind their back is just plain wrong.

One of my favorite programming assignments was in a data structures for C++ class, where we had to make a simple program to create a histogram showing how often a word of length X was appearing in a document. I had so much fun because another programmer and I had the exact same ideas for how to implement it. A group of us were working, and the two of us discovered we were taking the problem on in the same way. So what'd we do? We raced our prgrams. Sat there for hours trying to optimize tight loops, runniing the thing on 20MB of the Bible, eeking out a few cycles here and there.

We were the only two who took this approach to the problem (inherit off the std::string, re-work it to act like Perl's definition of a 'word'). Smallest code base out of anybody else in the class we saw, very proper OO design IMHO, and excellent re-use of existing objects. Well, we got either a D or an F, I forget. Prof wasn't too happy with us, because there weren't enough classes in it, and we had used what I consider the real definition of "word". The literal string "The" was a word of length 3 to us, not 5. ?????dog?,.; would also be a word of length 3. The string Don't was of length 5, etc. Apparently ???dog:, is actually a -word- of length 8. I beleive there was also a note on our papers about our methods being too close together. I was irked, but I didn't do anything about it. I was even more irked when I found out that other students who had wrapped a class around "float" to meet the minimum requred 3 classes were given full credit for the assignment. To the prof I'm sure it looked like one of us got this zany idea and the other one copied it. Far from the case, here's why we came up with same design:

• We read the same books. Bjarne's The C++ Programming Langauage was a staple for us. I would wager tha nobody else in the class knew who Bjarne was
• We both knew Perl, and liked it, hence our definition of 'word' was different than most people's.
• Both Unix/Linux nuts. We'd code projects in the Linux lab, then "port" them to the DOS compiler before handing them in.
• Heck, we both used -Emacs- ... The only code we copied verbatim from eachother were .emacs files

Academic Honesty

[Arandir]

The purpose of education is to learn. When you are attempting to learn programming, it does absolutely no good if you don't do it yourself. Or to put it another way, you will learn a LOT more if you try to figure out how to create your first linked list by yourself, rather than having your buddy tell you how to do it. Problems the professors give you are meant to make you think. It does you no good if someone else does the thinking for you.

You will learn more about "off by one" errors if you spend hours trying to figure out what's wrong with your code, than if your buddy says "hey, don't forget to count to foo-1 instead of foo".

This is for lower division courses. For upper division, when you have already demonstrated you know the languages and basic constructs, then working in groups should be standard.

2+ heads are better than one

[garoush]

I believe the title said it all to give you my view on working as a group.

Now on getting work experience, those schools that offer "co-op" are best when you want to get a feel to how it is "outside" the school system before joining the workforce.

As for the "zero" tolerance for cheating, schools put such policy in place to protect their bottom line: "preserving their name". Schools are there to prepare you for the future (and "life" if that's how you want to see it.) So, if you can "cheat" without "cheating" yourself out, I say do it for which "cheating" is a necessary evil just like being "honest".

Incoerence

[Karpe]

The same people who teach you how its dishonest to steal other peoples code, teach you how it is important "code reuse".

Most of the time, you will not have to come up with a very beautiful solution to a problem already solved, you will only have to find out which is the existent solution that best fits the problem. Thats what I use as a guide to my education, I try to learn the basic about a lot of things, so I know what to use when I have a problem. After all, one of the reasons of calling it computer *science* is because we stand on the shoulders of all who came before (most mathematicians, physicists, engineers) and improve the stuff they built.

My politics on "lending" code for classmates to use on university is as follows. I can give my code for you to take a look, as long as you will hear for me what I was thinking while I wrote it, and understand what I think is nice and what I think are hacks, and try to correct the hacks. Sometimes I check tasks based on code form me that are really nice some semesters later. It usually works, in that at least the person learns/knows how the code works. It is often said that the only way to learn a computer language is to write programs with it, but if you dont have good algorithms to implement in this language, your programs will suck. So I add that it is also important to check out other peoples code to see how they implemented theyr solutions. That is one of the most important aspects of free software, that is many times overlooked: education.

Azusa Pacific University...

[antdude]

When I took computer science classes (CS major) at Azusa Pacific University (class of 1998), we had projects that required group work especially with two required Software Engineering courses. Each of us did different tasks. I did the software quality assurance and graphics. Everyone had to do documentation (e.g. business and technical requirements) which is always important in software engineering.

The few beginning courses' projects were not group work. In other higher level courses, we had smaller projects that did require group work. I am surprised to see your university doesn't require group work in some classes.

Teamwork is irrelevant

[scott1853]

There is nothing you will learn by working in a CS team in college. The whole point of college is to learn as much as possible and hopefully learn information relevant to your major. Working in teams means not everybody has to work as hard or learn as much.

In the real world, teams are used to decrease the amount of time it will take to complete a project. That is all. Any one person in the team should be able to complete the project on their own, given enough time to do so. The goal of teamwork in real life is to get a product to market as fast as possible. The goal in college is to learn as much as possible. The relationship between time and number of people do not work the same for both scenarios.

While we're on the topic, I'd just like to send a big F.U. out to all the college students that post messages in newgroups, asking the intelligent people to do their homework for them.

Re:Teamwork is irrelevant

[blazin]

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.

Re:Teamwork is irrelevant

[scott1853]

I agree completely. Teams are used in the real world to complete projects faster. Bringing people that are specialized in one type of development is a natural aspect of this. However, at the college level, Johnny Network should not already have been type-cast as a network programmer.

Colleges exist to provide education, not restrict it, because when Johnny Network gets out into the real world, he's going to find that his job options are going to be more limited if he's already accepted that he is just a networking guru and is apprehensive about other computer jobs. Colleges aren't about tunnel vision.

Re:Teamwork is irrelevant

[scott1853]

"Teams in college are used to teach people what teams in the real world will be like, and that is a very valuable lesson."

Good point. It does have merit, although I still tend to disagree. Working in a team is the same whether its in software, marketing, medicine or sports. It's just communication with the rest of the team, which is better left to other general courses to teach.

Hopefully the colleges are telling the CS students that TALKING to people will be a requirement of their future jobs. Programmers don't just get locked up in the basement anymore.

Great programmers steal code

[jabber01]

There is an old addage in CS.. Good programmers write lots of code, and great programmers steal lots of code.

(Of course the distinction needs to be drawn between programming and 'true' CS/Information Theory etc, but you get the point)

The thing is, CS education treats programming too much like English - code may be 'speach', but it is not an essay. Yes, outright copying of code is still plagiarism, since you did not do your own work, but...

In the 'real world' you rarely find a situation when people solve the same problem in parallel.. So comparing implementations for 'originality' is not an issue. 'Parallel' problem solving should only be used in introductory courses. After you know the language/concept (around the upper 200 level classes) you should not have many 'solo' projects.

Instead, most projects should be solved by the group, and should be large enough to include a 'project management' component as part of the assignment. The problem should be too large for an individual to address in the time given - barring brilliance. Forced decomposition of the problem, division of the work into separate tasks, accountability on how well each part is done.. These are the things that will make for a successful team project.

Should cooperation be restricted? Not at all, but everyone should have their own area of responsibility.. You can have teams that compete, but better yet, involve the whole class and rotate responsibility.. Allow students to assign roles to themselves, and watch top coders, and star organizers emerge..

Idealistic? Sure.. Will some lazy bums slip through the cracks by riding on the coat-tails of their more talented and industrious peers? Of course.. All systems can be circumvented unless you want a full-time TA watching each student.

So what? These people will only do themselves a disservice in the 'real world' by demonstrating incompetence if they choose the wrong field - or, well, hey, what's wrong with coordinating and pilfering the efforts of others, as long as the job gets done?

If the coders can't make the pieces fit, but someone else can, that someone is a valuable asset to a company.

How many of the Linux developers out there have rewritten the kernel from scratch, just to add a feature? Everyone stands on the shoulders of those who came before.

Attributing shared ideas

[staplin]

When I was in school, most of the projects were individual as well. But the CS department also realized the disadvantages to working in a void.

Therefore, it was not considered cheating to work out algorithms, etc, in a group provided that that group was attributed in the source code. For example, if I ask Joe Coder for help with a method, my comments had better give him some credit. And if I work out an algorithm as part of a group, I'd better have a big comment at the top of the file listing the members of the group.

It's hard to enforce the attribution of help from individuals, but if it's a group attribution, you can just cross-reference the members' credits. And if someone has the same code that isn't listed in the group, you have a list of people to check with (it's not impossible a name got left out by accident).

Of course, this doesn't mean that all the code will be verbatim. You still want students to avoid wholesale copying, but sharing in ideas is fostered. And it becomes fairly obvious if a student has a bunch of group attributions to all of his code, and very little code written on his own.

Class = solo, resarch project = team

[leperjuice]

My experience in getting my CS degree was thus:

The work that you do in class should be a solo effort. It's job is not so much to teach you how to be a good coder, but to teach you the fundamentals. It goes without saying that while a good coder can write code to solve a problem, a great coder knows how to reuse other good code and save time and effort. But, of course, you have to pass through the initial stage of becoming a good coder. So classes are better for you to develop your internal skills.

Conversely, joining a (slightly large) research team (for credit) is the opposite of being in a class in that you are taught to borrow and reuse what you can and to work and learn from others. Whereas a professor and a few TAs in a large class may only have a cursory time to go over your work, if you're in a research project you can bet that all involved will see (and critique) on what you've done.

I did that and one of the first things I learned is how hard things can really be in the (pseudo)real world of a research project. Though I do reccomend arranging some sort of "Sempai-Kohai" [aibudo.com] relationship between graduate and undergraduate students. Often the Professor is so occupied with teaching and getting funding that they can't spare much time with the student except when things go wrong.

Modular design

[Mike1024]

Hey,

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?

You could put people into groups, and tell them to design code in a modular style.

That is, you could put people into groups of about five people, tell them the task, and get them to divide the task into modules themselves, documenting the modules and to whom they are assigned. You could then mark each module's functionality, and the program's functionality as a single unit.

For example, if you were designing a CGI script from scratch in Pascal, the group would divide the program into units, i.e. Get submitted data and parse into array, Convert hex-coded characters to characters and removing HTML metacharacters, designing output HTML and graphics, etc. etc. etc.

They'd need to work out interface specifications themselves, etc. but if someone didn't pull thier weight / produced bad code / whatever they could be held individually responsible, whilst still working in a team.

Just my $0.02

Michael

Leader two-way rating

[SuperKendall]

I had a team C++ programming class in college that I thought worked well - there were three projects, you worked in teams of three, and you got to be leader once - for each project the leader rating the two workers in various categories and the two workers rated the leader (or at least I remember it working that way). The team members were randomly assigned. I think your grade was weighted more heavily by the project you were team lead of.

I think such classes can be very instructive - one project I was on was great, the team members were all great and the project turned out well. On one of the other projects, one of the team members kept saying he'd have his work done... then the weekend before the project was due we found out he was out of town to attend a programming contest! Just like in a real job, I had to stay up 24x7 to try and carry the load for the slacker and put something together to make things work so the whole project was not a total failure. Even with that experience I thought it was one of my more useful and enjoyable classes.

Recognition

[nick_davison]

"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?"

Unfortunately, in the 'real' world, all too little attention gets paid to who pulls their own weight and who doesn't. Even if you're lucky enough to get a manager who's good at doing it, you've still got the end user who doesn't care who pulled what weight, they just expect a finished product from the whole team.

Arguably, therefore, having even less consideration paid to who does what is the 'better way'. It's certainly the more realistic one.

I keep explaining to friends who are still finishing their degrees that the actual subjects you study at university are probably the least important part of what you are taught. It's the things you learn around the edges that have the real value.

University gives most people their first experience working with uncooperative, unmotivated or outright incompetent team members. It gives you experience of managers (lecturers) who really don't have a clue how to manage, set hugely open specifications and then complain when you don't achieve the one tiny bit they were interested in, yet never spoke about.

Along the way you get to make your first attempts at dealing with these issues and hopefully learn from the experience. At first you try the unproductive methods (yelling, trying to do all the work yourself, complaining to managers [lecturers] that don't care). Then you start to stumble on to the better solutions like understanding why the others are apparently so bad and looking at how you can encourage/help/cajole them. At first you get bad grades because the specifications are so wide, then you start learning to ask more questions, really probing to find out what they're after. You don't get to be great at dealing with these things during your time at university but at least you hopefully get to have made your first truly painful mistakes in a safer environment.

Why doesn't anyone tell you all of this when you're going in? Why do the lecturers pretend it's about learning C++ and converting database designs to BCNF? Partly it's because a lot of the lecturers really, genuinely, don't give a damn about you, they're there for the easy life (as, sadly, are some managers) and partly because you have to learn these things the hard way and you'd only skip the lecturers anyway.

So, to sum it all up: The less fair your team working exercises, the more realistic they'll be and the better preparation for the real world. It may suck but it's better you learn it in the safety of university - it'll be the best education you get there.

These are all hard lessons to learn. After all, we nerds are generally tech focused, taking degrees in comp sci so we can do something fun rather than be politicing HR folk or whatever. The reality is that you'll rely on the teamworking skills about as much as the tech ones (besides, you'll probably be sent on some course to learn entirely new tech skills six months in to your first job) right from the start and will find yourself doing a lot more managing than tech within suprisingly few years.

Re:Recognition

[MikeBabcock]

In sum, you learn how to deal with people.

Unfortunately, the workplace and school both involve other human beings ... these will get in your way some times, but often aren't removable without jail time.

Cross-reference Dilbert.

:-)

Feeding the Cheaters

[ChaoticCoyote]

I get one or two messages a month from professors who've found some of my code in their student's work. I also hear from various students who want to download code from my books -- hoary and ancient as some of my C++ texts may be! ;) You'd think they could at least type in the code from the printed book... ;}

Then there are the obvious students on the newsgroups, who ask questions that obviously came from their homework assignments...

Yup, yup... I figure I've unintentionally helped thousands of students pass their classes in the last decade. I don't see much way to avoid it; given the size of the Open Source / Free Software community, and the number of lines of code available from all sources (freshmeat.net, anyone?) for download, it doesn't surprise me that many college grads can't actually code when they get into the working world.

Many of them grow up to be developers in software companies, where they continue to succeed by "borrowing" or "reworking" publicly-available code. Or do people here really think that commercial companies don't quietly steal Open/Free source? ;)

Frankly, I'd be less concerned about peaks at other student's code than I would about the overall ethical climate. It isn't much of a stretch to go from downloading MP3s to taking Free/Open code for use in schoolwork or workwork... after all, how can it be "stealing" when "information wants to be free?"

Re:Feeding the Cheaters

[MikeBabcock]

That said, part of being a good programmer in the real world is knowing when to take something that's already been done and just improve on it instead of re-inventing the wheel.

One way around this behaviour when its not desired is to force students to use cvs or another versioning system on a regular basis; their code modifications as they go along are saved along with comments. Your ability to comment your code for others' perusal is noted alongside how you went about designing the project.

Just some thoughts ...

Cheaters

[greesil]

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

Group Projects...

[Vuarnet]

Well i've had both good and bad team-work experiences in college. And what I've learned is that choosing the right team-mates has more influence on the outcome than the difficulty of the project.

In one case, I got assigned a team-mate (a friend of mine) who had a programming style just like mine. We both thought of the same things while programming, and we had a lot of fun during the semester. In the end, the project was a complete failure: we didn't complement each other, we were both lacking in the same areas, and therefore the project suffered a lot.

Next semester, while taking the same class (ouch!) I got assigned another teammate (even though my friend from the last semester wanted me to be his teammate again). This time, having learned from my previous experience, we started out dividing and assigning most of the work, depending on our areas of expertise. I was good at coding, he was good at planning, we were both good at database designing.

That was the best project I've done in my life. We were finishing it days in advance of the rest of the class, and although we did spend a lot of sleep-less nights coding (we drank so much coffee it looked like we had a Starbucks franchise in his kitchen), the result was really worth it. We got an A+.

So what did I learn in those cases?

- Don't confuse friendship with teamwork. You can have great friends who make lousy team-mates, and viceversa.

- Always work ahead of the schedule. It doesn't matter if you get zero sleep in the first weeks of the semester, you'll be thankful in the end, when everyone else has a ton of schoolwork to do and can't help you.

- Find team-mates who complement you. You suck at DB design? Get someone who's good at it. You haven't learned to code well? Join someone who can, and make yourself useful drawing diagrams and designing the project. Oh, and learn to code while you're at it.

- Drink lots of coffee and get used to the lack of sleep.

- If you're stuck with a team-mate who's dragging you down, talk to your teachers. You can't always save a big project by yourself, and if you try you could affect your other courses. Sometimes it's better to get a regular score in a project than to waste your time trying to save it. Besides, many of the teacher I had, when confronted with this situation, decided to split the score according to each student's contribution, so you had teams where the good student got an A or B by proving he had worked well in the project, and the other student failed the course.

- What's good for the team is good for both. If you can learn something, anything, from your teammate, try to do so. And viceversa, try to help him (him, her, whatever) in the areas in which he's lacking.

- CYOA. It's your future that's at stake here. If you find your teammate is cheating in the project, try to make him stop. If he doesn't stop, talk to your teacher. It may be true that nobody likes a snitch, but you're risking a LOT by helping him.

I hope all this drivel actually helps any CS students out there. Good luck!

CS major at Virginia Tech

[Kupek]

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.

They teach programming, not software development

[gosand]

I think the biggest problem with college courses, in CS anyway, is that they teach PROGRAMMING, and not SOFTWARE DEVELOPMENT. There is such a huge difference.

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]

Speaking from experience...

[Lostman]

I dislike working (in a class) in a group -- ESPECIALLY in upper level math and computer science classes...

When you get to a certain level, people tend to either "know their stuff" or dont... (no real in between).. in all the groups I have been "placed" in it has always started with me having to first reteach the lesson/example to my group and then walk them through what we have had to do. Havent had to work in these groups any more since I explained this to my Profs (and scored 99-100% on all tests I have had)...

Of course, in a workplace environment we expect to have weeded out all the people who didnt understand it.. you will be working with (more or less) equals... so it is assumed that you can actually HELP each other, rather than just foisting your work on another person in the guise of asking for help...

So (in other words) I am against working (forced working) in groups in a college/educational setting...

It works ok at my school.

[Elwood P Dowd]

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.

The ArsDigita University experience

[abe ferlman]

The policy at your University sounds very backwards. I can certainly understand the need to occasionally assess your individual skill to make sure they don't dilute the value of their diplomas, but without cooperation I don't even see how Computer Science can be taught non-cooperatively.

I attended ArsDigita University [aduni.org] last year, and it was explicitly the opposite of what you describe. Although there were individual tests and grades, the lab (where pretty much all interaction took place barring lectures) was built with about 40 computer workstations in an open-plan type office, with no walls separating the students from each other or the faculty. Most of the programming projects were collaborative group projects which were broken down into individual chores within the groups, and as a result we were able to do some pretty interesting things in a pretty short period of time, like building a Java-based Gnutella client in our January Java Class [aduni.org] (which, like all of the ADU lectures and course materials [aduni.org], are available freely online, although the lectures are recorded in the unfortunate realvideo format). Here [209.61.216.11] is a picture of some students collaborating intensely (or at least looking at something really interesting on Kevin's monitor :)

Having someone nearby to talk to when you're going crazy trying to find what to someone else will be a really obvious bug, or to bounce your design ideas off of, or to help you recall the syntax for a rarely-used but difficult-to-remember-the-name-of linux command can be absolutely invaluable. This experience is hardly exceptional, as any number of books and websites devoted to Extreme Programming will tell you.

There is a little friction when it comes time to decide who deserves what grade and why, since those within the group know better than the faculty who was really responsible for the work that actually got done, but this pales in comparison to the acceleration in learning that happens when you discuss specific pieces of code with another interested human being.

Hence, I think you are right in thinking that your administration is wrong.

Bryon

redundancy

[abe ferlman]

but without cooperation I don't even see how Computer Science can be taught non-cooperatively.

Obviously I meant "taught at all"...

From the teacher's point of view:

[Brian Hatch]

I taught a number of programming courses at Northwestern University, and have offered group projects as an option for clasess. Those that wanted to do group projects - and I encouraged it - were allowed to do so, and said projects needed to be proportionally more complex than those submitted by individuals.

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:

1. How did your program do what it did, explaining in some detail your sections of it.
2. Describe in detail the problems you had with your part of the project.
3. What do the following snippets of code do, and where are they found in your program.

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.

Group Projects Suck

[EvlG]

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.

A couple methods I've experienced

[brink]

The way the CS program at Indiana University, South Bend has it set up (for the most part) is as follows:
For small projects, if you talk with anyone or get ideas from websites, etc, you have to cite your sources/collaborators. This doesn't mean wholesale copying of code from sourceforge or friends (as more than one student has discovered), but it at least lets the prof know if you had outside input.

For the team projects I've been on, there were a few methods used to get around some of the problems like slackers and code accountability:

1. You pick your team members. If you know that someone is a slacker, you can try to avoid being on the same team.
2. Projects involve numerous separate tasks. This helps in terms of delegating code to ALL the team members, so one or two people aren't stuck with all the programming.
3. Team member evaluations. At the end of the project each team mate gives a grade to every other team mate (anonymously) for their code quality and project involvement. Each individual's grade is then composited from the Project Grade and each member grade. The assignment can get an A, but if you slack off, you can get a D or even F because your team mates graded you poorly.

Additionally, big projects are broken up into different stages, so you end up having a grade for each stage of the assignment, which is coupled with number 3 (above) to give an accurate reflection of the student's abilities.

All in all, the system seems to work pretty well. The nice thing is, if it's a REALLY big project and your team has no hope of completing all the functionality, the prof can still evaluate your abilities based on what has been done.

Maybe not the best, but it worked for me :)

Plagiarism, citation and intellectual property

[sneakerfish]

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.

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 /. style peer grading within the group. Slackers will get graded poorly by their peers.

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

CS: Groupware for Slackers

[dasmegabyte]

At my university, you are pretty much expected to work in groups, to the point that some professors assign them at the beginning of the semester and all of them warn you of the dangers of stealing. They do this because CS CAN BE TOUGH, especially for some of the non-techs that were in my CS department. We got a lot of students who were aiming for careers in consulting, IT or MIS and needed a degree but not necessarily the knowledge. Knowing this, most professors expect you to work in groups, where you can design alogirthms and modules together but present different finished projects. After all, five students debugging a stack is a lot more efficient than each doing it alone. Furthurmore, since our school gets mainly foreign graduate students as TAs, who are often hard to understand or who don't have any formal teaching instruction, we often get together in groups where students help each other understand difficult concepts -- the notes from these sessions generates code that may seem stolen.

However, I hated working in groups, mostly because I ended up doing all the work. It seems to me that this sort of groupwork encourages slacking -- certainly, I had a number of logic design labs where I did all the work while my partner tried to score with the engineering babes. As a defence mechanism, I developed a series of coding styles that mildly obfuscated my code in such a way that cheaters who didn't really reengineer it before submission would be handily caught...namely, I began developing a style which involved a lot of recursion, some unusual object style modularity (a lot of inlining, a trick most students don't use for clarity's sake) and so forth. I also made sure to hand in all the labs slightly ahead of anybody who i was "helping." My professors (I have one in mind, an adjunct who worked at IBM during the day) usually caught on pretty quick that I knew what I was doing and that if other people submitted code that looked similar to mine it was probably a result of group debugging and not copying or cheating. In any event, the key is to DO your own work even when working in a group...to understand modules you use even if they're written by other people. Otherwise, you'll not have the knowledge necesary to transcend the next level -- which is why so many people who pass our CS 240 (data structures) fail out when they hit CS 340 (OOP -- built on the concepts of 240).

Some colleges (like mine) are project-oriented

[dmorin]

Worcester Polytech (WPI) in Massachusetts used to be entirely about projects. You have a series of multi-year projects that take up a number of class units toward your final grade. Toward the "well rounded education" approach there is a sufficiency project (humanities), interactive (social sciences), and your major qualifying project which is of course in your major. You choose an MQP usually by the beginning of your second year, if you're lucky, and find an advisor who'll accept the project as valid. He then would often assign you your project partners, and you had up to the next 3 years to make it work.

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

How to make collaboration work at the university

[ODBOL]

I teach CS, and I see at least two related but separate things that we usually miss in classes with software projects:

1. fitting class work into a larger context of code;
2. 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:

1. many instructors don't have much experience with useful interaction on software;
2. a lot of extra work is required to define and supervise interaction, and universities almost never reward that extra work.

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

Re:Doesn't group work happen automatically anyway?

[scott1853]

my CS Theory professor says we can only meet in groups but "cannot walk away with anything written on paper." That's like telling a 2 year old "Be sure not to play with that fun-looking toy!" - it'll never fly.

So maybe it won't fly with everybody. Some students will copy others work. Maybe the prof. won't find out and they'll get a good grade. They'll graduate and go on to their first job.

Then the interesting things start to happen. Such as they'll have to start explaining why they can't learn basic skills associated with the companies software. They'll have to explain why they can't get any projects completed on time. This is actually a good thing, because it makes the job market that much better for me :)