Slashdot Mirror
Cooperation in CS Education?
fwitness asks: "The college I currently attend, like most colleges, is on a form of 'Academic Honesty Policy'. It has been explained to me in various ways, but mostly it boils down to: If you catch someone's code out of the corner of you eye, that's cheating, and you need to come up with your own 'original' ideas. I'm a CS major, so I write a lot of code, and I imagine when I get in the work force, I'll be writing a lot more. The difference is, in the workplace, I'll be in a team of people. I won't have control and I'll have personnel and political issues to deal with in addition to my job. So far I've had one class that actually demonstrated this principle, and I'm pretty much finished all my CS courses. I know the college has to do this so they can somehow grade 'my' code and assess my performance. Isn't there a better way? A way that students can be taught to work as a team yet still be able to tell who is pulling their own weight and who is not?" I always enjoyed working in teams during my college education, yet found that projects, where you were allowed to work with others, were few and far between. Do you all feel that technical courses should show a bit more emphasis on working with others, or is this just one of life's lessons that you pick up as you go along?
In college I did group projects where we were required to document our individual contributions. Usually at the head of all of our code was a commented out section marking the dates that the code was modified, who modified it, and what they did.
When I went to University, collaboration was always okay, as long as it was acknowledged. Since 'birds of a feather flock together', this wasn't really a problem (ie: students performing at the same level academically--minus any collaboration--generally collaborated).
"Slashdot is about legos and staplers." -Cmdr. Taco
...can usually tell you who did what and when. We had to use some kind of source code control system for all of our team projects. i don't know if the professor actually went through the check-in histories, but the thought that he could was a nice incentive.
-c
I have discovered a truly remarkable proof which this margin is too small to contain.
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.
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.
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.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
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.
Dozings.com -- Its kinda funny... If you're as crazy as me.
Actually, at my first job I was part of a team. A Programmer, an electrician, a machine shop guy, an Autocad/designer guy. That was the main team.
Best Slashdot Co
Of course there should be team work in college CS and Comp Eng. departments. During my undergrad, we had several group projects, after all, college is suppposed to help prepare you for the real world. There should also be individual projects where you do your own work. That way, when you do get into the real world, you won't be dependent on the rest of your team, and you might be the person the rest of the team comes to for info on certain topics, since you have an expertiese of it from your individual learning. Also, there's a great sense of accomplishment from completing a project that's all your own.
"The best laid plans of mice and men gang oft agley..." - ROBERT BURNS
I remember when I did a programming assignment a few years back in college, where one of the guys in the group and I did most of the work. We had told the professor that the other two were not keeping up their end of the work, but she was stubborn in not repremanding the slackers. The only reason the other guy (who was doing the work) and I continued to do the assignment and carry the other two slacks was to earn a decent grade for the project. My point in this all, it that working as a team can be a great experience if the professor keeps tabs on the situation and ensures that everyone has done their fair share. Thank you.
------
Random, useless fact: I type in startx entirely with my left hand.
Having relatively recently graduated from college, I don't really see a way that this can be done. Most of my group experiences involved maybe half of the group caring about their grade, and the other half being ok with a C. You then end up with an extremely unbalanced work load as the ones who care the most do the most and produce the better product. Then they usually have to go around and fix up the people's work who really didn't care as much. All in all, it rarely leads to a produtive group and doesn't teach you much about the work force.
:)
That being said, I have been involved in good groups, and those have been fun. When the work is divided evenly and everyone wants to do well, you end up with a higher quality product for less work per person. They have lately attempted a rating system of teammates, but I really haven't seen much come out of that. That could work, but unless you see everyone's grades (and since I was a student I didn't) you can't know for sure.
Bottom line is you can't ever differientiate any one person's work in a group effort. In the terms of code, if a module is crap and buggy, I'd rather rewrite it correctly than fix crappy code. That "hides", so to speak, the original authors work. Group work really isn't the way to evaluate individual people.
Personally, I think the beginning years should be individual work as you learn the basics, and the later years group work. You'll have to find a way to account for each person's abliity though, which isn't easy.
Basically, it isn't an easy thing to do.
Khyron
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.
That's why us Math majors always did our homework together. Were we cheating? By definition, probably. But did we help each other to understand the prblems and solutions better than we would have otherwise? Definately.
I understand and support the idea that stealing code should be punished, and straight copying investigated. But if the goal is to develop understanding, give the suspects a chance to solve a similar problem, and see if they really understand what's going on.
Carl G. Jung
--
"With one breath, with one flow, You will know Synchronicity" -La Policia
...like, 3 months ago, I was in a CS curriculum that came down extremely hard on Academic Misconduct (I know from experience). The thing was, when all the employers came to recruit, I was inevitably sat down and asked questions such as "Tell me about a time you worked on a team project," or my favorite "How well do you work with others?" Overlook the fact that everyone works with others all the time (in elementary school we are taught to get along with others), and you see that they are asking how well you work on [technical] projects in a team. So, how does a student achieve that all important piece of paper that jobs are looking for while being threatened with non-paper-receiving-ness if they even think about helping each other out, or working together?
"What we elect to call imagination is mere combination of things not heretofore combined." - Frank Norris
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
...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.
"It's comin' back around again..." -RATM
In groups of four or so, this self-reporting was almost always an easy way to keep track of who was working and who wasn't. Quizzes and tests also revealed some slackers.
I only had one truly fractured group in those terms, where none of the reports agreed. I broke them up and changed some groups.
I would do it again. Not only did I grade fewer homework papers :), but the students learned to work together, assign responsibilities, and evaluate performance within their group, which are all important workplace skills.
You save only 59 seconds over 8 miles by going 75 instead of 65. Do you really have to pass that guy? Do the Math!
I'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.
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.
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba
I was not a CS major, so I can't speak from a pure CS point of view. However, as a Computer Engineering major, I was required and encouraged to take numerous CS courses. One of those courses was a Junior-year software engineering course that required teamwork. While accountability and credit within the group was often a problem, sharing work (including code) was not a problem. Even though that was one of the least technical courses I took as a CMPE major, it did help set the stage for the "real world".
Biodiesel : domestic, renewable, clean, and in the fuel tank of my bone stock 2002 New Beetle TDI
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.
Your right to not believe: Americans United for Separation of Church and
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.
First of all I'd like to bring up an old story by Cliff on academic dishonesty that was posted by a friend of mine in a class I took in my last semester at a certain university. 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.
~ now you know
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.
If God gave us curiosity
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
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.
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*...
If it ain't broke, it doesn't have enough features yet.
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.
What'dya mean there's no BLINK tag!?
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).
- (c) 2018 Hank Zimmerman
I'm taking a course 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).
Towards the end of my undergraduate career here, we had plenty of group-oriented projects. Most notable was our Software Engineering class. The idea behind it was marvelous: The class separates into 4-person groups. Each group is responsible for designing their own project. (Being CS majors, most groups chose games, heh)
... you weren't allowed to code the project you designed! You had to "hire" other people in the class to code for you. (In the meantime, you also looked for jobs as a coder or tester for other groups)
Here's the catch though
It was a wonderful little course that taught us more about communication and design/testing, than merely coding. Also, it's a great class to describe to recruiters who get a kick out of it.
-- jchenx
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.
Consultancy: If you're not part of the solution, there's money to be made in prolonging the problem
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.
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.
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...
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.
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.
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!
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.
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.
Sneakemail is to spam filters what an ounce of prevention is to a pound of cure.
The first example had some differences, such as variable names being slightly changed, comments were changed but all in the exact same place, and the logic was all in the same order. Other than that, just a few if statements were changed but in ways where it meant and did the exact same thing, ie,
or
I asked a former professor what to do and she said that in cases like these she has thrown the book at the students. She said even if there is just a hint or suspicion of cheating, it should be submitted to the Dean, but that I should check with the department head. He went the complete opposite route and said that we didn't really have any evidence that cheating had occurred, and to just talk to them and tell them that they needed to work more independently. I thought I had more than enough evidence since one set had identical code. I confronted the first group (identical code) and they admitted to working together. I told them to meet me after class and they admitted to working together. I told them that this was a bit more than just working together and that it wouldn't happen again or there would be consequences. I then had a meeting with the other two and they explained that they did work heavily together, but would never ever copy, etc. I told them that they just needed to work a little more independently as their code was extremely similar. Consequently, the students that were copying did not do well on the exam last week and I believe it is due to them not knowing how to code on their own. Students need to learn to code on their own since most code in the Real World is not already made for them, and the code that is there is written by someone else, and it will be thier responsibility to know how to maintain it. You can't maintain code if you can't code in the first place.
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.
A Government Is a Body of People, Usually Notably Ungoverned
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".
Karma stuck at 50? Add 2-5 inches.. err.. 2-5x Karmas Count to your pen1es.. err.. Karma all naturally and private
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.
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.
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
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.
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.
The REAL jabber has the user id: 13196
What you do today will cost you a day of your life
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.
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.
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.
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" 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.
-- "I am disrespectful to dirt. Can you not see that I am serious!"
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
"Goodness me, how unlike the FBI to abuse the trust of the American public." -- The Onion
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.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
"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.
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?"
All about me
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
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
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!
Tongue-tied and twisted, just an earth-bound misfit, I
Learning to fly, Pink Floyd.
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.
The best course I took was a senior level class called Software Engineering. I worked with 3 other guys on a project all semester, and we didn't write a line of code. We had to come up with requirements, a schedule, a budget, test plans, designs, etc. But we didn't write any code at all. The goal wasn't to program, it was to design software. There is so much more that goes into software in real world companies.
I don't even know if they still offer that course, it was back in '92. I still have the book from it. I ended up getting into Quality Assurance, which they DEFINITELY don't teach you in school.
When I interviewed at Motorola after I graduated, I brought my project from that class. I was to interview with 5 or 6 people throughout the day. I showed the project to the first person I interviewed with, and she said to make sure I showed every other person I talked to. I later found out that it was a big part in getting me the job.
You can talk all you want about "being able to work in a team" but until you do it, you don't know how tough it can be. Organizing, planning around people's schedules, and yes, dealing with people who aren't as motivated as you are all real world applications.
Maybe things have changed in college since I was there (there was no internet back then - ack!). But knowing that the instructors probably are having a hard enough time keeping up with trends, they probably haven't. I think in addition to programming, they should teach sound software engineering principles as well.
Michael
Fight the monopoly and the evil
More at poundingsand.com
My beliefs do not require that you agree with them.
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...
Share the workload if you can. If you can't, you must be able to do it on your own.
Got Rhinos?
Here at UPenn we're sortof balanced. One of the expenses of being balanced is that some cheaters don't get caught and some people get accused of cheating when they haven't. But most classes do allow us to talk to each other about our code. And, we have an elective group project class available after freshman year. Junior year is a required group operating systems project. You write a toy operating system to run on solaris. Senior year you have to do a project that can be group based or not.
It would be very very detrimental to be a CS major here without taking the elective software project during your sophomore year. I'm not sure how anyone can survive junior year without it. In our (small) project, one of our team members basically lied about how much work he had done. We allowed him to procrastinate the integration and we were totally screwed.
We wrote what he should have written in the wee hours, and had learned several valuable lessons. And those lessons certainly saved our asses several times in our next project. Most notably when we picked group members.
Also, for those concerned that their partners' diligence wouldn't match their own, why on earth were they your partners? Did the prof choose for you? The best solution to that issue was what they did in my highschool. All major assignments were group projects. If the assignment was worth 100 points for four people, you would get a grade out of 400, and had to unanimously decide how those points were allocated to individuals. I had an A+ in every class that worked that way. And I cared more about my work then than I have in college.
There are no trails. There are no trees out here.
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 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 (which, like all of the ADU lectures and course materials, are available freely online, although the lectures are recorded in the unfortunate realvideo format). Here 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
microsoftword.mp3 - it doesn't care that they're not words...
but without cooperation I don't even see how Computer Science can be taught non-cooperatively.
Obviously I meant "taught at all"...
microsoftword.mp3 - it doesn't care that they're not words...
Part of the writeup for a group project would include a brief (1-2 line) explanation of who did what part. Knowing this was part of the material turned in, it encouraged the loafers to make sure they did enough to claim part of the project. I also stressed that they needed to know how all the pieces fit together, not just understand their standalone part.
The final exam for the class always was in a similar format as the midterms, with sample code to write, comment on, correct, questions about the topics covered, etc. This was worth 50% of the grade. The last 50% of the grade consisted of the following questions:
The snippets would be taken from two sections of the actual project code, one which they (claimed) to have written, and one which they hadn't.
I was extreemly pleased to see that, in fact, most folks had divided up the work evenly, and had a good understanding of the project as a whole. Now this could have been due to other members of the team explaining it to them, rather then them figuring out the other participant's code manually, but isn't that what you'd do in the real world?
Those folks that could explain problems they'd encountered often noted that they asked for help from other members of the team. By this point in the class, I could already recognize the coding style of each student anyway, but I really appreciated the honesty, and how they did work together to produce something.
Yes, there were some (I'd say 5%) that were tricked up on the exam and showed that they didn't actually write much of the code, nor understand it. However overall folks did a good job acting like they would in an ideal group coding environment.
The only problem I had with group projects was with Thurston Howell (or at least that's what I called him in my mind, due to his attitude and voice) who had one of the classic coder failings. He got so caught up with getting the perfect interface -- being able to use emacs-style data entry editing abilities and such -- that he never got any of the backend stuff even started. Those in his group didn't know where to go, since they had nothing to plug their code into. Here's where a normal group may have a manager who could step in and help out, and they didn't quite have the real-world mentality that would have allowed them to come to me and tell me what was holding them up. But other than this one incident, group projects have always been an excellent thing.
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.
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:
- You pick your team members. If you know that someone is a slacker, you can try to avoid being on the same team.
- 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.
- 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 :)
- Jonathan
The point is not stealing verses inventing everything from scratch. The point is attribution and the creation and improvement of intellectual property. After all, we are all "standing on the shoulders of giants" when we use things like UNIX, C and day I say Perl.
/. style peer grading within the group. Slackers will get graded poorly by their peers.
In liberal arts "stealing" other peoples work is called plagiarism and there are well established policies for dealing with it. Of course one is allowed and usually encouraged to read other peoples works and even include them in your own WITH PROPER CITATION. The distinction is that you must cite your references.
The same should go for CS. If you cannot solve the assignment go ahead and use someone else's code, but you should cite it as their code and not call it your own. Calling it your own is plagiarism and the same thing as ripping the copyright notices off of BSD kernel code. If you must use others code, you should try and improve it or you should expect a lower grade.
In a group project there seem to be a few possible metrics. These things seem to mirror what happens in a real world development project anyway in my experience.
1) Allow
2) Define good interfaces and use contract style programming to allow individual members to work independently on their own parts (a class, subroutine, etc.). The group gets graded as a whole on the quality of the design which can be seen in the interface definitions (or problem decomposition if you will) and of course the overall quality of the resulting software.
3) Use CVS and track how many lines of code are committed by whom and when they do it. Lines of code isn't the end all of metrics, but it does show people are doing work. If you look at the commit log and see that one student worked steadily thruout the project period and another hacked it all together in one night, you might take that into consideration too.
Just my $.02.
Dennis
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).
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.
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)?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
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).
Hey freaks: now you're ju
I've done both "lone-gun" programming and team programming. I prefer the latter, especially when it's with really bright, motivated people (like my current job), where you learn a lot.
The problem with school is the same problem you have in most companies. You have a few people doing most of the work. It's hard for a teacher to grade an individual's achievement in a group like this, so it's understandable why they hesitate to let people work in teams.
An anonymous team member rating system where team members rate the contributions of their team mates (at several levels: Skill, Effort, Teamwork, etc), may be one way to go. I think encouraging teamwork in software design is important. The day of the lone-gun programmer creating great software is more or less over. I realize there are exceptions to this, but they are few and far between.
Teamwork is an essential part of developing medium and large scale systems. That's the hardest part about hiring people right of school, I find. They don't have the skills for working as members of a team. They tend to try to do everything on their own without asking questions when they should be asking their co-workers for advice and learning from their experience. They tend to be defensive of their work instead of taking constructive criticism and using to write better code.
These are skills you learn as a teammember, and it takes time to learn them, so I think at some point universities should address this and incorporate it, one way or another, into their courses.
It also seems to help to have two parts to the project-- the group collaboration part, and a part that everyone does by themselves beforehand in preparation. It makes it easy for the group to spot slackers and threaten ostracism.
At least, this method's worked well for me so far in combatting slackers.
I Browse at +4 Flamebait
Open Source Sysadmin
I am a student in an Electronic Game Design program at a Canadian College (I myself am American). As a requirement for graduation from the two-year program, a student must be a member of a group that has a final project - referred to as a Product - that is of sufficiant quality to be at the very least an excellent demo in ones resume. Ideally the product should be of sufficient quality to attempt to be published - and at least one product I can think of that has come out of the program has been published as a B title.
In the program, the product development groups form fairly early in Term 2 (the Winter Term) and the rest of the two years in the program is spent, barring breakups and expulsions, working with those same people. The groups spend the first year documenting their product - our detailed design document fills a couple big 5" binders to capacity.
In the second year the product is expected to be coded and built, to the specs laid down in the documentation. There is a prototyping process in place as well that expects a functioning prototype to be ready around the end of the first term of the second year (Term 4).
With all of this time spent working on a major project with a group, with weekly meetings with a faculty mentor and regular design review meetings with a board of instructors, those people who are not doing work are identified fairly quickly. There are procedures in place to remove these people from groups where they are not being productive. In fact, the group I am a member of has such an unproductive person who is skirting right now with removal from our group.
When I came into this program I had only had very negative experiences working in groups at other Universities and in High School. I have learned that group work is very good experience but it must be done over time with a large amount of close interaction with the faculty, so they and the students can constantly keep tabs on the expectations and performance of those on both sides of the classroom.
In July O7, I got a mac pro. There's no punchline. Just endless joy and wonder.
In classes that teach basic programming and other CS concepts, I think students are much better off writing their own programs and doing their own work. How else are they going to learn these basic skills?
There are classes where group projects may be appropriate if done right. The classes I'm thinking of are software engineering type classes where much of the subject matter centers around being able to organize projects into modules, code the modules, and integrate these modules together.
However, if a class is going to teach teamwork, it's actually got to teach it. Professors can't just divide up the class in to groups of N, give them a project that is N times a normal, single-person project, and let them go. As others have pointed out, that is a recipe for disaster!
They actually have to instruct them in how to go about dividing up the work, designing interfaces between modules, integrating code, using source control to track changes, etc. Otherwise, they aren't really learning how to program as part of a team.
------
www.moneybythenumbers.com
Once upon a time this was the only system WPI had -- classes were really only for learning what you needed to know in order to make progress on your project, forget about grades. But toward the end of the 70's they started to get pressured to come up with a system that would more easily allow students to transfer credit when leaving the school. By the time I arrived in 87 they were shifting away from the 2grade (AD/AC) system they had developed into three grade (ABC), but the projects are still central to your grade. If you spend 16 class units on your project and get an A on it, then 16 A credits go onto your final transcript. Not bad. And by the way you don't "fail" courses at WPI, you simply receive "no record" that you ever took the course.
When the teachers and students both agreed to this system, it worked well. Many's the time a student would fail a course because he was working too hard on his project, only to have the teacher let him squeak by because the teachers knew that the class grades were a formality. I deliberately failed one class because the teacher had set it up so that the project work (writing code) was about 40% of the grade, while the two exams were 60%. I aced all the code and failed the exams, on purpose, and told her "I came here to learn how to write code, not how to memorize answers out of a book so you can write an arbitrary letter next to my name in your book." I got a 67 in that class, which is failing at WPI, but she gave me a C anyway.
Did you sometimes hate your partners? Of course. Just like in real life. Did your partners sometimes get credit for work they didn't deserve? Yup. There's no good fix for that problem, that I can see. But whether your project works perfectly or fails miserably, it's all good lessons for the real world. I have many stories from college projects that I still use with my employees today (and none of them start with "This one time, when I was hammered.....")
For the record, my humanities project was an examination of the approach to the tragic hero in Shakespeare (Hamlet), O'Neill (Long Day's Journey), and Miller (Salesman). My major qualifying project was teh development of natural language software for educational purposes, and my interactive project was to gather a day long workshop of teachers and discuss the impact of "highly networked sources of data and information" on how children would use the computer in the classroom, specifically social studies. Did that in 1990. So the projects were no small potatoes.
d
www.HearMySoulSpeak.com
Working in teams is one of the most critical skills that computer programmers need to learn - I hope it's taught more today than it was back when I was in school, though the institutional demand for gradability makes it hard to do. It's more common in graduate school, where research projects often need to be done as a team, but the current market has been for undergrad-producing factories to feed the dot-com boom - perhaps that'll change a bit.
Some of the important skills include how to coordinate work on shared code, how to divide up work when it is more separable, how to tell the difference, how to cooperate on design, how to find out the real requirements (since customers seldom hand you those on a plate, much less do so correctly...), how to tell when there are personality conflicts or ego problems, how to back off when you're the one with the ego problem (:-), how to match up different individuals' skills with the problems to be solved, .... Some of the new "extreme programming" approaches especially have to deal with these problems, but everyday business and amateur programming environments do as well.
Oh, and if by any chance Karl, Setsuko, Renee, or Temporary Emergency Acting Professor Eric are reading this, hi!
A few fnords to distract the form-error trap;...
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I cannot claim to be a CVS guru, but I have been using it for the past several months, and trained many others to use it. I have used it in several projects, and started using it for almost anything I write. Maybe I'm a little extreme, but I found it to be extremely useful.
I have then started using it for my school projects. Not only does it create motivation to be creative and innovative, it motivates to actually do the work. So, in a group project, where you are usually required to submit a group analysis, you instead have a log of changes throughout the course of the project. What change there is, who has submitted, when they did.
I have it setup so it cvs logs are sent to a mailing list, and have the groups join the mailing list. It serves as a driver for doing the work. Each time someone submits a change, you get a message, with a short log telling you what has been changed, and who did it. It is a healthy form of peer pressure.
You don't have to write group analsys reports, sometimes avoiding being brutally honest about some of your teammates performance. It's not your problem, the CVS logs will show everything. A web interface is usually the best way.
CVS is the way.
I teach CS, and I see at least two related but separate things that we usually miss in classes with software projects:
- fitting class work into a larger context of code;
- collaborating on the software.
Each of these can be addressed by assigning work in definite teams, or by other sorts of interaction. There are at least two obstacles that limit the amount of interaction we allow in class:For some sorts of classes, I've found that I can allow unlimited collaboration, and then evaluate each student based on a private interview in which she presents project work. I evaluate the insight shown in the presentation, rather than whether the student presents her own work or others'. This is very effective in cases where the project work leads to a deeper understanding of the material, rather than merely demonstrating understanding derived from books and lectures. It flops miserably with students who are extremely shy, or who cannot express themselves verbally, but I don't get very many of them.
I have never yet specifically assigned students to work as teams on these projects, but I've allowed them to form teams if they like, and to share work as much as they like. I think that the ability to discuss work completely freely, and to share pieces of code, has helped a lot. But to my surprise, in more than 5 years no students have actually formed a team.
Mike O'D.U. Chicago
Mike O'Donnell http://people.cs.uchicago.edu/~odonnell/
The originality in the "Lab" occurs during the report.
;-).
Good point.
In some (probably most) cases, that's how it's done. However, there are cases (see the reply below yours for an independent example) where the person running the lab does enough QA and monitoring to ensure that true deadweights do not get credit.
Maybe a combination of individual reports and monitored collaboration might work--and hey, in the real world, I've had to deal with people who would slough off work and I had to put in the extra time to make the client happy. (What, you mean not only do I have to program these functions but you can't even teach the client how to use our standard back-end CMS???) Life lesson learned early
Hmm. I hate comments. I tend to write one comment for every 2000 lines of code, if that.
Y'know what? My code is clear, readable and maintainable.
Y'know what else? Some code I've taken over recently has one comment for every three lines of code. And it's a nightmare. It's unreadable (the comments break the flow of the code, the variables are named badly, it needs to be run through a beautifier and it follows no known design patterns). 20% of the comments are wrong. 90% of the rest tell me what the next line of code is going to do. I don't need a comment saying
// increment the counter
i++;
I'd far rather have a line of code reading
numSausages++;
Suddenly I know that the number of sausages is being incremented, I haven't had to read a comment that doesn't tell me what the counter does, and I don't have to cope with a variable called 'i'.
If people focussed more on writing code properly and less on commenting it they'd be better developers.
~Cederic
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.
IMHO this is a complete stupid policy. One of the key objectives of any degree is to learn how to research a problem and find the best solutions. This is why traditionally you 'read' for a degree; this maps to CS skill of recognising when & how to avoid constantly re-inventing the wheel. My own 'original' ideas was how to earn a Phd, not a first degree. Providing you properly attribute your sources you should receive extra credit for research not less.
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 agree it's important, however it is fraught with dificulty. My CS degree included a similar final group project, and to be frank it was such a disaster that it was dropped from the grades. There was no proper structure and nearly every group degenerated into chaos. The problem being that some teams had too many cheifs and not enough indians or vica-versa. I think the main problem was that no roles where assigned, a small multi-discipline/role team (drawn from across modules), with assigned roles would be better. A Project Officer (planning), a Project Champion (requirements/domain expert), Analyst, Designer, Chief programmer (standards), Team Leader, Coder(s), Tester(s), Commissioner(s). Depending on the team size some of some people would assume different roles, i.e Domain Expert & Tester could easily be the same person in different roles.
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?"
It sounds like a poorly designed excercise/assignment to me. The key to sucess is about division of labour, so unless they've assigned a Project Manager you need to assign different responsibilities to the members. Play to peoples strengths, a strong personality as the Project Manager, a visionary as the designer, pedant as the tester, etc.
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?
I agree; Team's can be both more fun and more effective, In my 12 years post grad, I've always worked in teams some-times small, some-times large, but always teams. Teamwork is a key skill in developers and in my experience a small well managed team will always produce better results than a lone hacker, even the very best lone hackers.
My little brothers had a program he expanded from free stuff on the net until it was about 90-95% accurate in Identifying the author of source code when compared to know samples. In fact it usualy hit 85% accurate when comparing code written in different languages. This was an excelant tool for detecting plagerism, but guess what they didn't care, because software engineer is more about understanding the implimentation than it's about the actual code. If the instructor grades on how well a student explains why the used algorthm is better than an other one, who cares where the grunt work came from. I guess that's why the client programmer assumes the server programmer checks the message length for buffer overflows and vica versa.
Most Students copy from the textbook examples and add minors differences anyways. We had to write a program in our finals, guess how depressing it is to work for hours on a program that doesn't work for a final grade. Instructor finaly said "I can't find the problem either, must be a compiler bug". Our's was a programming course not a comp sci course
Apocalypse Cancelled, Sorry, No Ticket Refunds
You need to learn how to "work alone together" ;)
You need to know how to partition/factor conceptually distinct parts of a problem, define interfaces/APIs between those parts, and then all go to your own caves and write the implementation. When you come back, you should all be able to work together to fit those pieces together. One strategy is for the professor to have a design in his head, and give certain groups a chunk of the solution. Then the class as a whole should be able to all come together, and form a complete solution.
It's 10 PM. Do you know if you're un-American?
GPA only matters at your first job.
Agreed. But it matters at your first job. It determines whether they're jumping at you, or whether they're considering using you to fill in some holes. It makes a difference whether you're invited to IBM's exclusive job fairs like I was and then given first pick at openings for new grads, or having to go through the cattle line with everyone else.
A good first job can make all the difference in a career. 8*)
Aah, change is good. -- Rafiki
Yeah, but it ain't easy. -- Simba