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.
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?
Of course it has to be taught, CS students are antisocial by nature.
daed si luap
This would be an example of what you learn at school being inconsistent with what you need to do when you are out of school. It seems to directly contradict the existence of group projects.
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.
Maybe having the project under a CVS repository could allow for inspecting of individuals contributions?
Plus it'd be good to become familiar with CVS and group coding efforts... for the 'real world'
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!
How many of you ever had a job interviewer look at the college on your resume and say, "Oh, I don't think we want someone from your college; they don't teach you how to work in a team."? What makes us think a student knows more about what employers need than the employers?
Secession is the right of all sentient beings.
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 attend University of Phoenix. ALL of our projects are team Based. We are required to spend at least five hours a week working with each other to occmplish a task. I was very leary of the Idea (I am very independant) But I have finnally learned How to work in a team. I suggest the school to anyone who is trying to further themselves.
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.
At the college I attended, when we had to do individual programming projects, it was pretty much ok to discuss things with classmates as long as you gave proper credit within the code for algorithms or other ideas that weren't yours. Perhaps your school/professors would consider that as an option.
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
One of the strong points of DeVry is that they give you a lot of group projects. Even writing assignments are sometimes a group project, though these usually similarly involve a group presentation. The senior project is almost always a group effort. Almost makes up for all the COBOL they teach.
Coding projects are usually done on an individual basis, but design projects are not.
...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
There was a colloquium here at Indiana University (Bloomington) given by Gregory Wilson (a contributing author to Doctor Dobb's Journel) entitled Open Source, Open Science which touched upon this question. He suggested using CVS to submit assignments (I think this was meant for upper-level projects, not for little six-line Scheme programs). He said, "if you have seven people submit code at about the same time five minutes after the first person does, you have a pretty good idea of whose cheating."
...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
My senior year, the CISE dept. at UF switched to more team-oriented assignments at the request of the Industry folks who said that our graduates didn't know how to work in teams. Thus, every class I had my senior year had some sort of group project requirement. One class even allowed us to use unlicensed Internet code and other resources which are usually forbidden. I thought it worked well, and now that I have my first job in the "real world," I find that things work a lot more like those team projects. I found more satisfaction as the team leader of a project that actually did something, than being the sole coder on a little toy program that everyone else wrote too. The team approach also allowed our professors to make individual assignments for each team, so cheating was drastically reduced. Of course, these were all advanced classes, and everyone in them already had solid programming skills. I'm not sure if team-based projects would be good for the intro course. Far too easy for someone who doesn't know what they're doing to just slide through and and up dead-weight on an team at a later stage.
Shockwave Flash movies are the greatest thing to happen to non-sequitur humor since Japan.
Working as a team in college was always the best and the worst of times. Sure, you meet new people and get exposed to new ways of doing things, and that's great. But you are limited by the underachievers and slackers in your class (if your school is like mine was, that is a lot of people). Kind of think of it like the limiting reactant in a chemical equation; that reactant determines the time to complete the reaction.
That being said, it might be the most important skill you learn. Dealing with confilicting opinions and slackers are an everyday struggle of mine (web developer). It is good to pick up these skills early.
I actually had a very forward-thinking poly-sci professor in college that made group projects the focus of all his classes; his reasoning was that the experience of forced teamwork was more important than any specific knowledge
hawaiianshirt
I was an art major in college and one of the ways that group projects would be graded was based on participation in critiques. In this way is was more a reflection on direct participation in events that would move the project forward / as opposed to who actually did the work. We then did write-ups on team members and that's where the 'honesty' issue came into play.
It gets very tough to not be critical of your team members if you've put a ton of time into a project. Dishonest people usually show up as being dishonest, so you don't have to worry about them. Write-ups were always a smaller percentage of the grade than participation in critique.
Anyhow, wouldn't CVS also give teachers a great way to measure team participation in work related issues? Sure this wouldn't give a meaningful representation of design time, but in actual coding it would work pretty well.
anyhow, just an outsiders perspective.
-mh
Microsoft's version of sprituality:
"Double-click the lifestone to attune your spirit to the lifestone"
When I was in school we had a few group projects. What worked the best was they would group however many the decided was needed. Then we did the work. To be able to grade how each person did with in the group we each graded everyone else in the group on how we felt they contributed.
In my alma mater all coding assignments were done in teams (mostly because I'm old and way back then in the early 80's there weren't enough PDP11s to go around). Teams had 2-5 people depending on platform. I think teamwork makes coding more fun and is good at preparing you for work IF you are conscientious (sp?) about it. I did have a few teams where there were slackers that didn't do anything. I think those people missed out because of the lack of resources and had they had to work on their own they would have learned more (even by copying the printout into your program, which one team did as I recall :-). I think this is a valid reason for a prof to make at least some projects individual projects.
BTW, if I look at where the slackers are now only some of them dropped out of the CS workforce, most are chugging along just fine.
I had at least three classes where we worked in teams of 3 or 4 people (Software engineering, Graphics, and Compilers). The TA / professor would determine the grade for the team, and also solicit the team members' input on all the other team members. If there was a disparity, you all sat down together and worked it out. Sadly, that happened in 2 of the 3 cases for me, where our group had a true stand-out zero contributor.
It would have been useful if they'd provided some rudimentary project planning and management instruction also.
At Duke, almost all of the really important CS courses- software design and implementation, operating systems- are almost entirely team based. The most important thing in doing well in those classes is putting together the right team of people.
This has upsides and downsides, of course. Upside: being forced to trust people to do good work, because your grade depends on it. Downside: being forced to trust people to do good work, because your grade depends on it. It's a double-edged sword to be sure, but as you pointed out, that's what it's like in the real world, except you replace your grade with your job.
Fortunately, as it is in the real world, the TAs and professors make an effort to figure out who really did what on the project, and that affects the grades accordingly.
Personally, I think teamwork is something that you learn in any number of different ways, through sports or activities or whatever. The skills involved transcend disciplines. I think you would gain just as much benefit from learning how to code well in your classes, and learning how to be part of a team with the other parts of your life.
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
I've had many friends who had to leave the major because they couldn't cope with the coding demands. Now imagine if they were allowed to work in a team- a lot of them surely would have still been in the major, perhaps damaging their entire lives.
We do have a few labs that are meant to be done with partners and it is my opinion that they are quite adequate as teach you team-work and more importantly, how to factor in complete idiots in your team. :-)
Posting messages for the betterment of humanity..
I just graduated with CS degree from American University and I have worked on projects in groups and by myself. From experience, I can say that there is a time for both team and solo work, but sadly, many times the wrong methods are chosen.
When you should work by yourself:
Whenever you are learning something very new, which should be about 75% - 85% of your classes. If students work in groups, it is far too easy for some students to get by without learning a thing. I have seen groups of three where one student did everything, and the other two merely wrote in extra documentation! This cheats your best students and wastes time/money on your poor students.
When you should work in a group:
Whenever you are applying the knowledge you have gained toward a large project that would be too difficult for one student to complete in one semester. This would be typical of your later CS classes where you aren't learning how to program, but rather, higher level concepts such as operating systems, games, etc. Good students will have much less tolerance for slackers when developing a system of 30,000 lines than they will for your standard 'implement data structure X' project.
OddManIn: A Game of guns and game theory.
I think that once the required skills are taught, and this will take place [at first anyway] largely by individually playing with logic and syntax etc., there should definitely be emphasis group efforts. This is the way it is in the workplace, so that it is good training to start in school. It also makes each individual programmer reconsider the code in light of how other people's minds view it, thus expanding the breadth of understanding and improving the programmer's own skills. And it's fun.
Wakka Smakka!!!
I graduated with a BS in Information Systems (yes, CS-lite) from CU Boulder, and the only classes where team work was not involved were the programming classes I took from the engineering school. Database, OO/SmallTalk, Systems Analysis and Design, VB, etc, were all based on team efforts, usually 4 people per team. One professor had a system where each member evaluated how the others worked, and then the final grade for a project was divided accordingly. Some people occasionally got screwed (me included) but it's no different than how inter-office politics work.
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.
im a CS major at the university of dortmund, germany. Here just about every course encourages teamwork, even in the teoretical classes we are allowed to work in 3 man teams. The software labs in 3 and 8 semester have team sizes of 8-16 ppl. The coding assignments in the practical courses are often designed in such a way that you need at least 3 pople to complete them on time.
This rocks is all i can say to that. In My experience when working in teams students get stuck and frustrated far less than when having to work on their own. Talking though problems with others often significantly increases understanding the problems at hand.
By making us work in teams the problems we are tasked to solve can be far more complex and thgus more interesting.
Of course in the larger labs teamwork can suck, when some people refuse to do their share or simply are not up to speed, but thats life. This will happen IRL too, so it helps you build experience in dealing with this
-- never underestimate someone who overestimates himself
At University of South Florida, teamwork is encouraged and actually our programs are handed in as one program with multiple names. The way that they assess the achievement of the individual is by giving an oral exam for each person after the assignment is turned in to make sure that no one is just riding along without understanding. It is actually 100% legal to copy code from other programs in our class, because in real life, you use and expound on other people's ideas quite frequently. I think this is a very effective setup for this type of course. You might want to mention it to your college. A contact name you can give them at USF is Grandon Gill, he designed the course for our university as well as a couple of others and it seems to work very effectively and creates a nice balance.
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!?
At my University, all comp sci students are required to print out and sign the following form for every assignment we do, except a few classes that do require teams. It's been in effect for the 3rd year now:
On a note regarding school work in groups, we have 3 classes that allow teamwork in our comp sci dept:
Software Engineering I (3rd yr)
Software Engineering II (4th yr)
Database Implementation II (4th yr)
My plan was to take all 3, but S.E. I was such a horrible experience for me I declined to take the others. Our team bickered and had disagreements right until the end, and we weren't the only group. It would've been nice to have a course earlier in the curriculum that taught us how to work as a team. It may sound stupid to some of you, but I can tell you that my group sure could've used it.
When I was working on my Comp Eng degree, there was ample opportunity in our last year to work in teams. In fact, all my major assignments were done with a team. it fell to the group itself to dictate who was responsible for what, and regular reports indicated this. Add to that the fact that if one person didn't complete their section, the whole project was delayed, and it was rare that anybody slacked.
Along with this, it was generally accepted that with the heavy workload we all had in 4th year that there would be collaboration. As long as you referenced anybody you borrowed from or shared with, all was well. There were a few "individual" assignments that I worked on with friends and we all had answers that had the disclaimer "this question was worked on with [student name]", and it was always accepted. Generally, it's better to have a student learn how to solve a problem from a friend than be afraid of asking because their answers may be too similar.
This seemed to be better preparation for the real world than slaving away at 3am trying to debug an assignment that you aren't even sure you interpreted correctly. If I have a problem, I turn to a co-worker and ask if they know how to solve it, or go searching for the answer online. It's no different than the arguement of "Why should I have to memorize this formula? In the real world, I'd have the book on hand if I didn't know it."
- In hell, treason is the work of angels.
In the real workforce (and I've been in it for over 12 years) things don't work the way you might think. You need to learn the basic skills that will be required of you in order to contribute to the team once you are in the real world, and that is what the school is teaching you now.
As a junior engineer you will be tasked with small projects (bug fixes, etc) until you prove your abilities, and then be allowed to contribute to the larger picture (design and such). Until that time, you are effectively a non-voting partner in the team relationship.
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).
I recently graduated from a Information Systems track which was located in the business department. We had a number of development projects, and a fair portion of them required working in groups. In fact, that was the number one complaint about our coursework -- not enough solo projects. Anyway, each member of the project was required to thoroughly document the work not only done by themselves but also done by every other member of the group. It was a pretty effective way of keeping people honest. That, and in many projects there were status updates during the project that required the same level of reporting, so the instructors found out early on in projects who wasn't performing.
I found over the years of both in school and out that something came to light.
You can work in groups all you want. Heck you can have the entire class as a group BUT you all get marked together. Some teachers allowed for peer review but most didn't. I can see their reasons why.
If you are doing in a group when you are in a work enviornment you don't assess the success of the project to any individual over another. Either the project works or doesn't. If you find that someone in the group isn't pulling his/her weight then you can get rid of them. Assign them to a different group or in the real world...."Fire them".
You can't have group work and not mark heavily on the individual because it is group work. Otherwise you might as well assign individual projects.
There are times for both it is just tricky finding out when it is good to do each.
The only way to truly get the type of experience you are looking for is to take summer or (even better) a part time job in the CS area. I recently graduated and am now working for IBM. The thing the helped me stick out from the crowd was my work experience in IT for 1 and 1/2 years while attending school and a 3 month co-op in Germany. Job experience is the most effective learning tool any school can provide, and most schools do have programs to help interested students find jobs in their area of study. Classroom learning is a totally different type of learning and, while it has its place, is not nor will it ever be as effective at teaching practical skills as is the work place.
If you would like to be a leader with a large following...drive slowly down a windy two-lane road
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.
Group projects are fun, exciting, and provide education outside of just the regular academic assignment. I feel that they're extremely useful for people to begin to understand group dynamics. They also provide the opportunity to assign harder than average work because a group works "smarter" than a single person in that you get to bounce ideas off of one another.
What about freeloaders? Well, what about them? In case you didn't notice, they exist in the "real world" also. But if a person (or their parents) is going to be spending thousands of dollars for an education and then cheat themselves out of it, who's really losing here? Are people really considered that immature that they won't learn the material? If you "cheat" and don't benefit yourself, will I, as an instructor, really care? You're only hurting yourself.
As an instructor, there is also the safeguard in that people get to choose who they'll be working with. By the end of the semester, the freeloaders will probably have loafed themselves out of any of the elite groups. People will still tend to be loyal to their friends, but being able to forge friendships is also a valuable lesson, don't you think?
Where the wind blows, the tumbleweed goes.
I took a bunch of cs classes (CS undergrad, Masters in Software Engineering, Completed all CS Ph.D. coursework).
What I really saw was that - besides the odd course here and there, e.g. a networking class, where groups within the class might design a network (each using different requirements/models), group projects were pretty much limited (by definition) to being held within the Software Engineering courses or curriculum, where the focus is on methods and techniques for completing technical work in a group environment with limited resources. Unfortunately, if someone doesn't hold their own, it can also damage (F*ck up) the group.
Another issue is that unless the problems are original (they usually aren't), there is a limited number of ranges of possible solutions and implementations that are truly viable. Hmmmm how many different programs are there to do a quicksort of n integers with a given partitioning algorithm? Not that many that are really very different... The biggest problem for submitted projects that the University likely faces is probably people just submitting solutions that are letter-identical to previous submissions. Some professors have developed programs to identify how similiarly programs reflect previous submissions.
-- Sam Nitzberg
sam@iamsam.com
http//www.iamsam.com
while i was at university, i found myself embroiled in a lot of competition with other students, but i was the biggest source of it. i personally find it rather difficult to trust someone else's code, especially when we're graded on style, when my marks are on the line and my name goes in on the project. of course, most software is written in a team, so i'll have to learn somewhere.
this problem of mine eventually led to a burnout and i'm currently "between schools" ... what was offered at my old university is a course in software design where you were forced to work on a project as a team, and it was much more involved than most group projects. i was waiting to take it in my fourth year (which never came) and i certainly regret it. it would have helped a great deal.
i think courses like this are being offered at more schools each year if they're not already common. people like me are all too common in this field ...
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...
What a coincidence, I am sitting in the computer lab right now TA'ing a software design class where the students are working in teams. The way that we try to reduce the "slackers" is by allowing everyone to change teams after every lab. Groups can also to refuse to let someone in their group if they are a known slacker (or actually for any reason).
:wq
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 guess I have the opposite tack to the original contributor. Having worked in industry for 11 years and slowly gaining on the completion of my PhD which I have recently gone back for, I find this argument to be disappointing. Almost every computer class I have taken has insisted on team projects, inevitably you always get a slacker and your project suffers as a whole. Additionally, it's very easy to get pigeon holed into working in a specialized area and not getting exposure to the other components of the project.
I would strongly argue for projects that can be performed by one person. No more than one class in your educational curriculum, like a Software Development Practicum should involve team work.
Sure in the business world teamwork is necessary, but typically businesses will completely retrain a college new hire anyway. We're looking to see that you are well balanced, intelligent and that you're a fast learner. If you've been working as a team member for all of your college years, I believe you'll be lacking in certain areas of your development.
...if this article discussed "Conception in CS Education"
Just how many ways are there to write "hello world".
I have been programming since the late 80's and every language I learned formally, at a school/uni, they taught the same programs just a different language. (SOSDL)
I would like to see programs that make the student's think not just learn how to do a bubble sort then apply it to a standard data set, the same as the 200 students before you and the same as the 30 students in your class. Of course there will be similarities
-- Tim
TKrabec Pahh
I'm taking CE at University of Toronto, and all our fourth (final) year work is team work. There used to be a 'thesis' which could be done alone or in teams, but now it's a 'design project', and it has to be done in teams. Also, a lot of my lab work in the past years was done in teams of 2-3 people. This year, the teams are 4+ people.
The thing is though, that team work in school is not like team work at work; I've worked for a year on a co-op placement and the teamwork was very different because everyone was always around... we didn't all have different classes to go to or things like that. We were all basically full-time team-mates, where in school we are only part-time team-mates.
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.
Currently I am attending college for a degree in 3D animation, and almost all emphasis is being placed on the individual effort. I have not had a single project so far that involved a group. Maybe this is because of the singular nature of art in general, but once you leave the classroom and goto the 3D studio environment, you're always working in a group. No one person models, textures, lights, animates, etc an entire scene in a movie; thats done by a group of people, varying in numbers. Most of the emphasis is placed upon your personal abilities with the software (in this case Maya), so its unfortunate we will not have a group project where we can see what its like to work with a group, and the advantages and disadvantages of each system. I guess they expect us just to learn on our own once we get into the field on our own.
"What can a thoughtful man hope for mankind on Earth, given the experience of the past million years? Nothing." -Bokonon
University education does not reflect reality. At my workplace you're encouraged to share code and ideas, because through this process everybody excelerates quickly. You can't code in a vaccum, and this kind of thing shows why some are doing, and others are just teaching..
Luck favors the prepared, darling.
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!
I am a software engineering student at MSOE. Our program is extensively team based. We do get graded quite well because we provide feedback on our peers and because our class size is really small. (There are only 15 in most of my SE-related classes). When I get out of college, I will have skills that many do not. So, if you like programming and would like to learn how to "engineer" software (not simply write it), check us out.
There was a colloquium given here at Indiana University (Bloomington) by Gregory Wilson (he was a contributing editor to dr. Dobb's Journel) called Open Source, Open Science which touched on this question. He suggested using CVS for class projects, and said "if seven people submit their code at about the same time five minutes after the first person did, you can be pretty sure whose cheating."
sounds like you're ready for the real world
s/professor/manager/ and this could be any real world situation.
-- www.globaltics.net
Political discussion for a new world
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.
I was in a team in an intermediate C class. A teammate had trouble getting her code to work so she did a global search and replace on everyone else's code, eliminating all those asterisks because "they don't seem to work"
Oddly enough, ampersands didn't work much better.
Do not make test scores part of the grade for a programming class.
Working as a group is a skill that should be learned long before college. There will always be people that milk the group. If you need to learn to play well with others at the age of 19....yer screwed.
If it ain't a Model M, it's a piece of crap.
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.
In an advanced course, I could see team projects. But I would also expect the project to be much, much longer than 1000 LOC projects you see in intro classes.
"Hardly used" will not fetch you a better price for your brain.
Don't worry about grades and just worry about
learning, then your lame partners won't matter.
...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?"
From the CS code of ethics:
1.1.2 Camping.
The fragged players has to keep watching the game and scream "NO CAMPING LAMER" really really loud til the camping players keep moving!
geesh i thought someone with a major in CS would know!
get xited
Studies have shown that most students actually do best with a mix of group work and individual work.
The issue is that good group work contains within the implementation individual accountability (Johnson, Johnson, Smith). The group task should also be a task where it isn't EASIER for one person just to do it all, it should contain within it some room for controversy and debate (Brufee) or just the need for more than two hands or one brain.
One way I have been successful in fostering individual accountabilty for projects is this: Each student, at the end of the project, gets to assign 100 points to him/herself and the group members, based on what percentage of the work was done. Each turns their assessment in to me privately. If they all are roughly pulling their weight, then that is fine.
Another thing I do if there are several projects, is I put the slackers in one group. After the intitial "Duuuude! This isn't going to write itself" moment, the slacker groups often wind up doing VERY well together.
If you have had bad experiences with group work in college, think: Is it the concept of group work itself that was the problem, or was it the implementation?
God is real unless declared integer
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've worked in many CS course team projects, and they tend to end up in one of three situations:
1) One person does most the work.
2) The professor forces accountability and each person has to do their share.
3) The group splits up the task logically and has clear leadership and delegation.
1 & 2 are most likely, 3 is *rare*.
Btw, many big companies are spending lots of money on software engineering productivity. They've found that high-level languages like Java, VB, etc. are the cheapest to produce and maintain apps. They've also done a ton of work on "Team Coding," that's where two or three people take turns coding per machine (two+ minds are better than one). In school, there is rarely a requirement for reusability across different courses, though there should be a strong urging, if not mandate that code should be reused from course-to-course.
Are there any indications that a curriculum could be formed, whereby code and extending projects flow from one course to the next?
SkewlD00d
The biggest trick the devil pulled was letting lawyers become politicians so they can write the laws.
In physics, we were encouraged to work through problem sheets in a group whenever we wanted; it was just the Way Things Worked. We didn't have to acknowledge it or anything. I actually got the distinct impression that the tutors didn't think we did enough of it.
In compsci, for all of our work except one piece we had to sign a "this is all our own work" disclaimer, and cheats who got caught were treated pretty harshly. Although there was, of course, some informal discussion it was pretty frowned upon.
The exception was the specific group project which we did in the second year, which which nominally of eighty hours length; we were divided up into groups of six or so, given a fairly meaty project, and we had to organise ourselves and work through it.
Personally, I thought the group project was very worthwhile. It was designed to be a mirror of conditions in industry (right down to slackers in the group!) and it was a fair stab at that (I've also worked out in the Real World), although of course it wasn't perfect.
This group project system is pretty common in the UK, IBM run a nationwide inter-University competition around it. The best group from each University gets an all-expenses-paid trip on behalf of IBM to a two- or three- (I forget) day competition. The winners get to take brand new Thinkpads home, so it's pretty decent. My team didn't get in though
You win again, gravity!
I took a 'Programming in C' course at the University of Minnesota a couple of years ago. The way they handled it was by having us work in teams for our labs (if we wanted; we could work individually if we preferred), and then on the written tests during the lecture, we had to work on our own. Since all of our projects could be done outside of the lab environment, they really wouldn't have been able to control who we worked with, but on the tests they could make sure we were doing our share.
I'm generally a 'go it alone' sort when it comes to coding, but now that I'm actually writing code for a living, I'm finding that being able to read other people's code and collaborate with them is quite useful. Without some collaboration skills, projects with multiple people will take longer or even fall apart. I've even found it easier to learn APIs, because it gives you some better insight into what another coder was thinking if you're used to working with someone.
The Evergreen State College in Olympia, WA, USA doesn't use a typical grading scheme. Instead of grades, you receive an "evaluation", which is a written summary of your accomplishments and how well you performed. It works very well, and for those slackers that think they can get away without grades, it's not as easy as you think. If you really aren't doing the work, you'll just lose credit and won't get anywhere. I went there for a while, and I think it's a really great system. They stress teamwork and cooperation. They have computer science-y stuff too! The Evergreen State College
Speaking personally, I've always hated group projects and collaborative efforts in education. All through high school I grimaced anytime a teacher gave a group assignment. In my experience, the group or team members were always a hindrance to my own progress. Schedule conflicts, the inevitable group member(s) who just wanted to fuck around instead of doing any work, etc.
:)
I've found this to be especially true when it comes to programming. Like a lot of coders, I do it best when I'm in my "zone." For me, the zone is sitting in a room with some white noise (machines whirring), with a cold drink on the desk and a pack of cigarettes in reach. In this environment I'm comfortable, and I can relax and focus on doing what needs to be done. The problem is that everyone's zone is different. Some people work best with loud music going, some people have to have a very bright room, etc. Try to get 4 or 5 people with different comfort zones working together, and you're going to have productivity problems.
Given just about any task, I can get it done much faster if I'm working on it by myself, in my own comfort zone. I realize that at many places this isn't an option, but I'm far more productive working on my own. Fortunately I haven't been given any group assignments to do in college
Shaun
Thanks to the War on Drugs, it's easier to buy meth than it is to buy cold medicine!
In work settings, that would be nuts - typically you will be given something to work on, one sub-goal of a team goal, while others are working on a different sub-goal. So cross-pollination is fine then; it's not stealing others' work, but contributing to the final product. In school, you and you alone are being evaluated by your work; so using someone else's work gives inaccurate and wrong results, hence it is punished. At work, you're all going to be looking for jobs if the company fails, and you'll all be better off if it's successful (ignoring union complications, idiotic companies/PHB's, etc.).
In short, the real world (tm) is not like school. Don't get hung up on expecting it to be the same.
John 17:20
As far as fairly evaluating contributions goes, it was rather hit and miss. Usually we were told to grade each of our teammates. Sometimes those grades were open to those same teammates scrutiny, other times they weren't. This worked in varying degrees. The most interesting system I saw was used in a business psych class where the prof was using the class as a test bed. He actively put people together so they would be most likely to have problems in their groups! Anyway, we were given a grade in points and had to choose how to divide the points among ourselves. The result had to be unanimous and you weren't alowed to give everyone the same number of points. Fortunately my group was fairly reasonable, but other groups came to screaming matches and occassional blows (catfights). It was something to remember. After the project was complete, we had to write a paper on the experience, of course applying the principles of the class.
In another group, I was not there the day that groups were selected and ended up getting placed with a group of friends, who were mostly interested in non-acedemic interests (read - partying all night and sleeping all day). I ended up doing all the work and then they all banded against me and said that if I didn't say they deserved an A, they would all say that I didn't do a thing. So, I said we all did equal work, and the prof didn't believe it! He asked them a few questions and marked them all down signifigantly! Just goes to show, that no matter what system you use, you have to have an impartial judge.
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
I've been on both side of the equation as both a teacher of CS and a student, I can say that this is one of the most difficult problems both teachers and students face besides the homework :) On the student's side is the age old question "Whats considered cheating?". Is it ok to copy a printf or cout so that you can use some cool formatting or just get an idea of how those funtions work? In other words, where is the line between original thought and reference material, how much help is too much. As a teacher, my reservation about assigning group work was determining who did what. Did one person work tirelessly on this for a week or was there equal contribution. Then there is the additional burdon/art of balancing the groups so that everyone has a chance to complete the project and the quicker students don't take the attitude "I would have gotten an A if it wasn't for my groupmates". Often you have to sacrifice the interesting projects to become somthing easier because at this stage of the game its as important to work well with others as it is be be knowledgable in CS. All in all its an art, and it depends on what the teacher is trying to teach. I know its a cop out but its true, the value of doing a group assignment is taken on a class by class basis usually. The teacher has to trust the students to "play nice" so they get somthing out of it because in the end, and this is the scary part, there is no real way to tell who did what when the instructor is so far removed from the teams interactions and creative process.
BOFH, My model for being a sysadmin :)
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
This student's complaint highlights two problems with current educational practices:
Teamwork is important in the real world. It's not all there is to work, but it is a significant factor. Even "lone geniuses" such as Einstein used other people's ideas and discoveries in their work. By treating students only as autonomous units, schools are significantly failing in their work.
And what about the "slacker" on a team? Yes, slackers are everywhere -- and sometimes they're hard to spot. Who's the slacker? The person who writes a 100 lines a day but whose code breaks 6 weeks after they leave or the person who writes 10 lines a day but whose program still works 5 years later (and can be modified by successors to keep working)?
A faculty member who knows the students in a class will be far better able to spot those same students' problems (whether "slacking" or rushing too quickly through work) than the faculty member who wants to "teach" 600 people and use traps to find "cheaters."
"Beer is proof God loves us and wants us to be happy." -- B. Franklin
Once some pupils, in pairs, at a school
Had a project (display text was the tool)
The first one a jerk
Number two did the work
Said the program: "My partner's a fool!"
Here's my take as software developer who got a BS in CS in '99.
Groups in school are hit and miss, and the students are learning how to handle it. You don't have a good idea how to divvy up the work, working with various schedules suck, and everybody is pretty much inexperienced software engineering wise. So you're going to get various amounts of effort - some because you weren't able to plan well and some because you have slacker teammates.
In the real world, tasks are usually individually defined. Even though you're in a group, you are given individual tasks which are the bulk of your work. These individual works are then integrated by a subset of the group working together. There are still important group activities - during the design phase and to keep everybody on the same page. But the majority of development work is done individually.
Groups in school try to get you a taste of what software engineering is about, but in my experience schools do a good job with the theories and the basics, but don't have the time, resource, or experience to really prepare you to working in a large group.
So yeah, I think your school is doing the right thing on testing you indivually on a large part of your work. Small group project (2-4 people, 5 weeks, 3 or 4 credit hour course) don't do much to teach you real world skills or experiences (though group interaction often aids in the learning experience of the topic at hand - just not in regards to software engineering).
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.
Wow, there are some real telling sentences here:
1) I hate groups.
2) I knew I was the strongest coder too.
3) I wrote all of the code one morning before ever having the first group meeting.
4) I didn't want to deal with having them argue about how to do it and having it take several days.
5) Then I told them to do the testing without me.
Where do I start?
First, you hate groups. So you are basically a non-gregarious person when it comes to the workplace. Big minus.
Second, you have a tall self image. You think you are the best coder, but coding is really only half of the battle when developing software. Big ego.
Third, you went and did all the work by yourself without consulting your team. Self indulgent.
Fourth, you didn't want the team to participate in any discussions about your project. Basically, you wanted all the glory for yourself, and didn't want to be bothered with their input. Selfish and uncaring what others think.
Fifth, after you single-handedly went out on your little coding expedition, you then play dictator and tell them all to do the testing. Seeya later.
No offense, guy, but you are my worst nightmare. I have fired probably five or six guys just like you over the last few years. You need to get lessons on how to really develop software. Why people skills are important. Why complete team input is important. Why you don't know half of what you think you do.
Like the title says, be humble. You have a lot to learn. Even though you may not think so.
Excellent idea. Back in the day I was a bio major and biochem grad student/TA. We would get group projects in two situations - lab work and presentations. For in-lab stuff in the lower level classes it was pretty much "Find a partner, cut this up and answer these questions." while in the higher classes (like Gross Anatomy, which I TA'd for a semester) the group work was more involved, but the TA's were around enough to tell who earned the lab participation points and who didn't. The students often made that pretty easy - "Hey, does anybody remember so-and-so even touching a cadaver? No? OK, adios to you, buddy", but these options aren't very applicable to any decent size CS project. For the group presentations that we did, we were assigned a grade based on the whole presentation that everyone shared. Theoretically, this forced everyone to work together so we would all reap the benefits of our labor, but some groups had people who slacked off knowing that the grad student and/or pre-med major would cover the work to save the grade. This never bothered me much since I figured that the slackers would only contribute poorly anyway, but YMMV. If you combined the shared grade approach with a way to reliably track what each group member did (CVS? code commenting?), you could weight the individual students grade relative to their contribution. A way to reliably do this is left as an exercise for the reader:)
"Bugger this, I want a better world." - Jenny Sparks
There were also separate team projects, which seems like a pretty realistic scenario - most times, you'll be given a small part of a project and told to just go do it. Later you'll integrate it with others' parts, but for the most part they're independent if well-designed enough. You can get ideas and help from others but you can't rely on coworkers to do all your work for you. Pretty close on parallel in my experience. Maybe the real problem is the "academic honesty" policy. Code sharing is not necessarily cheating.
I'm a CS major at a University, and, in a lot of classes, coding is supposed to be done alone. However, a lot of groups form naturally to help each other, no matter how illegal this all is - it's a matter of friendship and survival. If mandatory groups were assigned, friends would still get together, but that whole group would benefit. Is this wrong and immoral? Quite possibly, but so is downloading MP3s.
As a sidenote, my Computer Architecture professor says "Feel free to work in groups of 2 or 3, but if you can't do the work on your own, you're screwed for the exam."
And 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.
I am currently attending StonyBrook University in New York and am forced to work in a group for one of my CS classes. There are numerous ways in which you can potential take advantage of the situation, so that other members do more work than you. However, the few checks that are down, is on top of the work required for class (as a group) we must provide a list of what we have done over the course of the week, as an individual, which is a powerful check, when checked against current project performance, as well as what other people have submitted. So cheating is not a huge issue.
I believe that there is a huge need for this type of work, because without it we would all be ill prepared for the real world, and even with such projects we will still be ill prepared.
When you work on projects in groups (greater than 2) you become aware of different personal expertices, and how to best use those to achomplish your goals as fast as possible.
It is hard at first, but it is a great way to learn. Group work allows you to persue larger projects than you could persue on your own, which helps to improve the class enviorment.
Overall group work is good. There is a time and a place for it. In some classes you do need to learn all of the basics, such as in your intro level classes, however once you have the basics down there is no reason to continue to work on your own when productivity and real world teaching would be better served by group work.
links of interest: http://www.cs.sunysb.edu/~cse308 - course web page
http://virtucom.codearama.org - group project page
-mage-
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.
I am currently a junior at a fairly well respected school with a great CS department. My experience has been one of dread concerning group projects. It usually boils down to the professor picking the groups, and then one or two people end up doing the entire project either because the others don't care or because they can't coordinate properly and fall behind. The worst are the "Business Systems" classes that combine us CS majors with Business majors. That is a complete nightmare as the BS people can't even do an html page properly, and the CS people end up doing everything, even the writeup because the BS people can't understand what they're writing up. The end result of all of this though is that this is probably close to how it's done in the "real world" and therefore this is good experience.
$45 per U Colocation Special
At my school most of the later classes focussed on team developed projects. OS and compiler classes were pretty straightforward big group efforts, but the real interesting one was my Software Engineering class. The project, which spanned the entire semester, involved three interworking modules, with each person in the class working on an individual implementation of one of the three. After an initial design and preliminary developement period everyone reviewed a certain number of other people's work, and "bought" the two other modules they needed ("bought" modules gained significant grade points). As the project progressed and support for different things for different "customers" was called for, modules could be returned and new ones "bought" with "economic" (read grade) penalties for both dropped vendor and customer, though the newly "bought" module gained points. At the end of the semester the overall projects were graded on a speed test given a specific large input set (i.e. the fastest one got the highest grade).
Generally, once you had proved you have basic coding skills (as in you're in upper level CS classes), the teachers would encourage working together, pretty much most stuff short of cutting and pasting code was cool most of the time. There was an official "intellectual honesty" policy, but really it was just there for the teachers to use in the case of blatantly lazy students. Pretty much it was just an extension fo the study group idea...
I'm a CS major at Carnegie Mellon. I've had only a few group programming projects. In particular, there's an operating systems course here which is a big deal, with lots of big projects (a shell, a terminal driver, a kernel, and a filesystem). I felt that I really got a lot out of working with a partner on these projects. The most useful bit was discussing the entire design together. When we both agreed that a design was workable, we split up the coding and went at it. We each saw a lot of things that the other didn't see (design considerations, bugs, etc.).
I do wish I had an opportunity to work on more small-group projects like that. However, there are some considerations:
That said, even though I've only had a few group programming projects here at CMU, I think that my education -- combined with experience in internships -- has prepared me well.
I can't really speak for other colleges, but here at CMU much of the work for our "core" programming courses is done in teams of up to 2. However, the vast majority of the students here are motivated enough to actually do work on the projects. I like working in small groups such as that because you have the opportunity to tackle problems that, although still small, are actually interesting and non-trivial. One example is creating a decent Othello player and entering it into a competition at the end of the project :-). If we were forced to work alone, one of two things would have happened; 1. The quality of the players would have been extremely low, or 2. This interesting (to most) project would have been replaced by something annoyingly simple.
---- Yay! I have a sig!
In college it is far better to focus on academic learning and also how to get along with different types of people. Leave learning the real teamwork stuff to your apprenticeship as an intern and first few jobs. You'll quickly discover that "teamwork" in the workaday world has many different meanings - few of which you'd ever learn in a classroom.
Many people feel a college education is structured with a focus placed on getting the student a job. This is how many students take it, in reality colleges and universities want to enrich the student as a whole. This is how most of the people in academia would like it to be. Of course starting salaries and big corporate sponsors are good for the bottom line. Working in groups may be a good skill for a programming job, but only through individuals practicing and working with pieces of code can they become enriched. Being enriched students they can then apply those skills learned through individual study to a "job skill". Just a view from a student AND a member of the work force.
Get a bunch of people working on the same project, and keep track of who did what, and when? That's pretty close to the project goal of CVS. Just have each class member log into a CVS repository to make their code changes and commits. Then, an audit of the history would show who did what, and who didn't.
:)
I use it here at work to see which of our production artists screws up my ASP/PHP code with their WYSIWYG HTML editor the most often, and then, of course, fix it.
-e
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!"
The course is *killer* and if you want to do well you *must* have a good group. The individual rating helps, but if the group does poorly, 75% of 0 is still 0.
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
...is the best way to learn.
Stealing your coworkers work (or shoddy code from the net) and passing it off as your own comes later. When you are a PROFESSIONAL. We call this "reuse."
Now, get back to drinking beer... er, I mean doing your assignments.
I am very small, utmostly microscopic.
If you think that, once you get into the work force, everyone is going to pull their own weight, then you're in for a serious reality check. In school, it may not be fair when one person slacks and gets a good grade based on the rest of the group's work, but the exact same thing happens in the "Real World(tm)." Unless you're in a very small company (or division, perhaps) where everyone can tell how much each person is doing, you're going to have the same situation where the whole team is recognized for the work that maybe only some did.
I guess in that way, school really is preparing you for your career.
Apparently, of the rich, by the rich, for the rich.
At Georgia Tech, I write assignments for the first team course (cs2335). Its pretty easy to force the type of teamwork that you want to demonstrate if you word the project correctly. If you give a project that has clearly conceptually diffrent parts, you will often find teams split the assignment and each do a part, then integrate their parts together.
Another consideration is that coding ability is NOT all that is necessary to make teams work well. I personally am weakest at banging out code, however my design awareness, and ability to communicate and realistic scheduling make teams that I am a part of do extremely well.
The "group as a whole" philosophy is shown in the grading of most assignments in group classes. Who cares if X did 38% of the work and Y did 62%. Y learned that much more. The important thing is for them to do this intentionally, and to both gain from the experience.
Want to see every step I took to start my company? http://www.rowdylabs.com/blogs/pitchtothegods
My experience has been that it is best to have individual coding assignments. I was in a group coding project at college and one of my partners was so bad that I flat out told my professor that if he was in the work force any manager would have fired him by now. I am a huge advocate of individual work and not group projects. I hate to have to bust my butt even harder because someone slacks off, then the slacker is rewarded with a good grade. CS courses should instead focus on an individual's ability to grasp and implement coding priciples. Whereas you can save group projects for more abstract software engineering courses that focus mainly on the analysis an designing stages of large computer programs.
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
Perhaps the instructor could find a variety of different open source projects with individual bugs that need to be repaired, and assign these bugs to the students to resolve.
In this way, the student learns to work within the context of a team (the open source project in question), the instructor gets to see how well the student works, and cheating becomes difficult because each student has different problems.
Admittedly, the instructor would have a lot of work cut out for him to assess the difficulty of each assigned bug. The students should receive bugs that aren't so impossible as to make the student feel a failure, yet not so easy as to be ignorable.
However, such work would be about as realistic as you can get in a scholastic setting. You're dealing with real problems that exist in the real world. You'd be working with real people on real projects. And bug-fixing constitutes the majority of what entry-level programmers find themselves doing anyway; it's a great way to learn common coding problems, and by constantly examining other people's code, you may learn their idioms and tricks.
And so it goes.
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.
There are certain issues in having people work in a group on an assignment.
1. First of all, as you rightly point out, how would you measure each one's capability? The issue isn't to find out who is actually pulling his weight around. That would be unfair to the others and also tough for the graders to figure out. The issue is to define problems in such a way that they can be divisible and each person can be assigned one segment that he can finish, and then when everyone is done, work in a group to co-ordinate the segments into building the whole. The problem with this is not all problems can be divisible into equal effort sub-problems.
2. There is also the issue of what teams one would form. Again, there tends to be unfairness in this. If given the freedom to form a team, the real good coders will group up, and beat the shit out of the weak coders in terms of how much they can do.
3. Thirdly, in one of the courses I am taking, the assignments were originally expected to be done in teams of three. But then, there were some off-campus students who were also taking the course, and they felt they would get a raw deal out of this. With more and more courses going online, I am not sure if teachers will look at teamwork as a viable alternative.
In my senior year, I took a class which focused on the process of software engineering, and less about the code itself (though a useable program needed to come out of it). The mechanism that help in the evaluations were regular reports to the professor from the individual groups on where the schedule stood and who was assigned, which task. Actual coding was fairly collabrative. The class mostly graded our understanding of group design and project management, so we had to produce reports and specifications on our own.
;-)
More importantly, a project lead was chosen out of the group who had a limited amount of influence on the final grade for each team member. So in theory, good work and effort was rewarded, and slackers were punished. Of course, you had to have a fair-minded project lead, but you need to have that in the real world as well.
======
In X-Windows the client serves YOU!
This is going to sound like a troll, but I'm really not trying to stir up a fight; this is my honest opinion and the product of a lot of deliberation. This question seems to apply directly to Software Engineering courses... I took a couple of different Software Engineering courses in college, and they only taught me one directly applicable principle of the real world:
When working in a team, the slacker who's just trying to get by recieves the promotions, and the talented individual who cares about his work gets to stay exactly where he is (until he gets fed up and goes for the bare minimum like everyone else).
In my case, I carried my SE team by single handedly finishing the project. The other members passed while I was flunked, even after I complained to the instructor. I think what actually happened was the manefestation of the instructor's "Engineering Ideals". He believed that teamwork was vital to a successful project, so he made sure that teamwork was the only way to pass.
In a broader sense, I think that engineering's typical "teamwork mindset" is far too conventional. You never hear about truly revolutionary advances coming from large group efforts- people like Einstein, Feynman, and Newton worked alone. Genius is never attributed to a team. I'm not trying to cut down great team projects like the Apollo program, or large construction projects; I'm saying that they always take conventional ideas to a grand scale. Even the revolutionary elements of their design can be trace to an individual.
--WH--
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.
Perhaps something like this would work:
I once worked for a company that had customized an editor (this was on a VMS system and I can't remember the name of the editor). The editor was tied into a source control system which required a username and password. So when you fire up the editor it prompts for the uname/password and logs you into the cvs-like system. You put in the source file you wanted to work on and the editor checks it out. Then as you make changes (in what looks like the original file) you actually make changes in a tmp buffer. When you write the changes so you can compile and run them, it takes the tmp buffer and makes special comment tags showing the user and date/time stamp for the change. It also was setup to make a special comment tag around any code that was directly changed or removed (as opposed to new code added). This way there's a history of the code's evolution...not only the who/when aspect, but the what aspect as well.
Personally, as a college intern who hadn't programmed the language before, I thought this was awesome. I mostly worked bug fixes so it was great to be able to see what the original coder had done and to know who he was, or what he might have changed that created the bug.
The University I go to teaches several classes at the senior level aimed at narrowing the gap between real world and academic programming environments. One class is a semester long group design project. The project is for a real world customer (one group coded a web front end for the schools class registration DB). This class is a taste of the coding industry. You use a file version management tool (like Clear Case) you develop time lines, goals, everything. The other class, which is taught before the group design class, is a SW Engineering class taught by a SW group manager at HP. Everything involving the control and flow of a SW project is covered extensively.
Both of these classes give a very good taste of the jobs in store for the CS grads.
robi
I actually do not like this 'practical' stuff. I feel that computer science studies are far far too much just pereparing for the real world get a job type plan. IT annoys me to no avail, as most computer science students know nothing about computers, and only want to leran to get a job. I think this is a poor reason to learn. I wish that computer science classes were far more filled with theory and much less practical stuff. northeastern university for example, even has co-op, and forces you to go on 3 co-ops, which does not really help you if you just want to go on to graduate school, and then gasp, onto research and not become one of those business office working droids who sole purpse in life is to get more money.
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.
For my last senior year class, the entire class (about 20 people) had to program a real-world program that would be used by the university to track housing assignments. We split the program into logical sections and 2 people worked on each part. The professor basically did nothing during this period, so we had to take complete responsibility for it. It turned out fine and I think we all learned something. I think the key is to wait until senior year or so as the early classes have a lot of people who are not serious about their degree or college.
//m
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...
I got a CS degree not too long ago and I remember all too well this policy of cheating. I think that the code you write in college has no place in the real world other than to judge your own abilities. By copying someones answers you will have just defeated the purpose of the assignment. All I know is that because of having to do all my assignments myself, I feel confident in my own abilities which in turn will greater benefit a team. On another related topic is group projects. When I was in college (all but 2 years ago) I had a handful of courses that emphasized group work. Some courses suffered from having assignments done as group work and some couldn't have been done without it. One class the professor decided that it was time students learned to work in groups, so we were divided into groups of 4 to tackle a project that was meant to be done individually. His motives were good except he also forgot to teach us the essentials of working in a group as opposed to on our own. This led to 1 student doing and 3 students watching - a very poor idea. On another front I had great group assignment in a later class where we had to write compression / decompression utilities from scratch. It taught us a lot about planning and dividing work up since the professor went through how we could tackle this assignment efficiently. One final thought to all this is that if you are in college you must remember that all the lessons you learn there are not the final solutions. Wherever you go after leaving will decide exactly how you will work.
Team work in college is great if you empower the team like they would be elsewhere.
I had a team I was involved with in college where we had one individual who didn't pull his own weight whatsoever. This was even ok to a point since the rest of use could pick up the slack.
However, this same student was responsible for keeping track of all our project materials and presentation slides. On the day of our presentation, he neglected to show up at all, so in effect, if he'd been doing nothing we would have been better off than what happened.
We talked to the instructor and found we were allowed to fire the student. This responsibility fell on my shoulders and I had to take him aside and tell him that he was no longer in the group and would no longer be part of our project. Since it was near the end of the semester at this point, he wasn't able to find another group that would accept him and he ended up having to repeat the course.
Tough, I know, but fair, and he saw it that way as well in the end.
I don't see what the big deal is, having students use a properly set up CVS system will show exactly who made what changes when, and in what order. Of course you do have the issue of students writing code that never gets committed to the repository because it is bad, wrong, or ugly. This to wouldn't be a bad thing because even if it does get committed and then rolled back, rewritten and recommitted it shows that the students saw something that could be better and fixed it. That would be tangible proof that the student actually learned something. What CVS isn't part of the course? Personally version control is something any CS major should understand, and qualified CS teacher (Prof. or T.A.) should be able to teach.
Slashdot is an anagram for Has Dolts, and I am Dolt number 468543
In the SE class, we broke ourselves into teams of 4, and managed the best we could. I don't remember how exactly this was done, but I do remember that we were told that if we didn't get a finished product produced, we should have a test harness to show that our part works. I think this is a good step useful for begining classes.
In the OS class, we had to work as a team to produce a real OS. Typically the only people who took this class really CARED about OSen and so would put in heroic effort to get the thing working. The grading was done in several parts, one being a final presentation, and another being a form used to grade yourself and your peers.
If you thought you did a lot of work, but the others weren't pull their weight, you could say so, and presumably once the prof looked at all the reviews, he could figure out sorta what was what and who was doing good work or not...
Incidently, I did something a little, perhaps, controversial (although I didn't really think too much about it at the time). One of the tasks I had taken on was to create an ethernet driver for our OS, based on some code we got from Sun (these were 3/20s I think). Myself and another guy within a different group got access to this code, and we were the first to attempt to get it working. I never did, but he did. I therefor attempted briefly to take a copy of his working code and use it within our OS.... in this I was also unsuccessful.
Well, during the presentation, I was going through the list of things I had worked on, including the enet and the fact that I had taken his code and attempted to use it... I'm suprised I didn't get talked to or repremanded about that, but I had two things going in my favor. 1. I didn't attempt to deceive anyone about the origin of the code, 2. I didn't actually get anything to work.... I hope the honesty was the real key. It shouldn't be a big deal that I took some of someone elses code, but that I give proper attribution. In lower level classes, the doing is the important part, whereas in the higher level ones, the understanding is presumably more important...
So, to summarize, I think it would be good to have team projects like this, where you can do several things:
These two questions seem to be recurring. "How can college mimic real life better?" "What are college courses really trying to teach?"
These are certainly difficult questions, ones which need continual reevaluation, as society/industry changes and evolves...
Hope some of this helps, even though it is real late in the discussion...
"Why should I be content to simply live in this world, when I, as a human being, can CREATE it?" - Oertel
Yeah yeah, lets have one of those reality college's with the weakest link theme's. That would totally work out like you want :-D
- You can work with other people while thinking out your solution, even to the point of working out some very high level pseudo-code together.
- When it comes time to write the code (or other solution), it better be your own.
When I was a TA for an introductory class, we used a program out of Berkeley called MOSS (Measure Of Software Similarity) to check for cheaters.It made it very easy to check for people who had copied and modified code, or worked from the same printout. If you feed it examples in the book or from the lectures along with the submitted solutions, you can also find out who worked independently from a common starting point.
After completing the program there, I can say that it definitely did create an environment where students could learn from each other without having to worry about being accused of cheating. We frequently left our collaborative discussions with a much greater understanding that if we would have simply done the assignment alone, and that type of learning is something a school should allow, foster, and encourage.
Does the name Pavlov ring a bell?
The moral of this story: the battle for successful teams can be won and lost in the initial selection of the team members. If you can't find good colleagues, you are better off working alone. If you can find good colleagues, you're a fool if you don't collaborate with them.
Measure your wealth in hours, not just dollars.
True, working in a team is a useful skill. It is something you may need to learn (though most people already have that skill by the time they leave high-school and polish it on their first job), and maybe even practice.
But if a typical CS student (say) 40 classes, isn't it enough to practice teamwork in, say, 4 of those classes? If all those classes, or even half of those classes, emphesized teamwork, you'll end up generating graduates who are great at team work (this includes professional slackers, who have perfected the ability to cause others to work for them), rather than people who actually know the material.
If you want to be a "programming drone", then by all means, perfect your skills of choosing and working in teams that will make you look good (regardless or not if you actually did good). But if you want to be a really good programmer, worthy of your CS degree, you'll need to always be tell yourself the following: I *can* do this all on my own. I *am* good enough. The reason I am cooperating with others now is to finish the job more quickly. However, If you are cooperating because others know more than you, especially when you're in a stage where you're supposed to be learning (i.e., during your CS studies), you're just hurting yourself.
The problem I find with "group projects" is that a lot of times they are a cop-out because the teacher is too busy to actually teach. Plenty of people DON'T pull their weight when in a group project. (although maybe less so in the software related courses) And it often can be a joke and waste of time to the smarter students.
I went to Earlham college, where one of the main overall ideas for the campus was community. Most of our classes expressed this idea by doing things in small groups. In the CS Dept. We usually had groups of no more than 3 people. The professors usually tried to make very balanced groups of skills and personalities. They evaluated both how the group did as a whole in meetings with each group. during those meetings they also got a feel for how each member was contributing to the group. Politics were part of the whole process, and you just had to deal with them. That was one of the things they were trying to teach. However, our class size was very small.
I think at a larger university, you could also do this, but you would have to have a very good GA pool. And professors who would let the GA be a little more autonomous.
In Acadimia, if you work with others it's called "cheating"
In the workforce, when you work with others it's called "cooperation"
*shrugs*
You should first make sure you have a good definition of what working in a team means in the workforce. YES, you have people around you who are all working on the same project you are, but in reality, you have your own code that you're in charge of and your own timeline that you have to keep. So, it's not like you don't have to pull your own weight in the "real" world.
Having individual projects in college really helps you find your own strengths and weaknesses and helps you develop good work habits that are yours and yours alone. This should be what the majority of work you do at college is about.
But, you should also have the chance to work in a team in 2 or 3 classes so that you can get a feel for how your individual talents will play out in a team environment. Perhaps your school needed to add a few more classes like these, or they did have them and you just needed to sign up for the specific classes that offered this type of work environment.
There needs to be a good balance, but having gone to a large University where we had both team and individual projects, I would say that your college experience should stress the individual part first and foremost and then add in team-based development every so often.
If you need extra work on your teamwork skills, join some student groups and work on them that way. That will also get you interfacing with people outside the CS department, which will also come in handy in the work world as well.
Good luck!
+1 Insightful, -1 Troll. What can I say, I'm an Insightful Troll.
I am a community college instructor who teaches a second Java programming class. I used to use the traditional technique of marking individual assignments but found that students used a lot of each other's material, particularly when they became very busy.
I mark a majority of my student labs now by asking the students to demonstrate them. Beforehand, I tell the students that
1) The can use any learning style they want, including copying the work of others.
2) I am most interested in their understanding of the material.
3) I caution them that people who go through the pain of learning through practice are usually more successful than those who look at other's solutions.
4) I encourage the students to work cooperatively, but not just pass on solutions.
5) I tell the students that if they don't know/understand the material they are demonstrating, it will be a very uncomfortable time for them.
During the demonstration I ask the student to
1) Give me an overview of the code.
2) Show me some of the important bits.
3) Describe the flow of the program.
4) Tell me how they would perform a simple modification (I usually have a number of them up my sleeve). This is often the best indicator of their knowledge since making a simple change often means changing code in several places.
In general, I find that asking the students to demonstrate their programs works very well. It allows for immediate feedback and often some extra education, tailored to them. On the drawback side, it can be intimidating for the student, particularly the first few labs, and it is a bit harder to ensure that the marking objective.
To handle the "who did what" scenario, you send in a weekly report to the teacher and you have regular group meetings with him. The end result is generally more fair than most group projects I've experienced.
Looking for a computer support specialist for your small business? Check out
In one of the courses I had, we were always allowed to collaborate, except on one assignment where we were told explicitly not to do so. I think this mode of working is fine every once in a while, because in the real world, you are occasionally asked to get something done, and everybody else will be too busy to help you.
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...
I actually did much more group programming in college than I have ever done in the real world. In my CS and EE classes, it was common to assign group programming projects. After some planning, we'd usually pick the fastest typist to enter the code, and the other(s) would stand over his shoulder and make suggestions/corrections.
When I got out and started my new job, I did this exactly once; and that was my first project, done with a 'mentor' type (ie. somebody bucking for a promotion to management). After that, it was solo work in the ol' cube farm; even when working closely with someone, we hardly ever looked directly at each others' code as we wrote it.
When I read my first article on eXtreme Programming methods (with pair programming), I thought back wistfully to those college days of yore. . .
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...
Well guys, you might want to mod the right post next time. The next post about the 'recruiter' was the 'funny' one.
Part of the writeup for a group project would include a brief (1-2 line) explanation of who did what part. Knowing this was part of the material turned in, it encouraged the loafers to make sure they did enough to claim part of the project. I also stressed that they needed to know how all the pieces fit together, not just understand their standalone part.
The final exam for the class always was in a similar format as the midterms, with sample code to write, comment on, correct, questions about the topics covered, etc. This was worth 50% of the grade. The last 50% of the grade consisted of the following questions:
The snippets would be taken from two sections of the actual project code, one which they (claimed) to have written, and one which they hadn't.
I was extreemly pleased to see that, in fact, most folks had divided up the work evenly, and had a good understanding of the project as a whole. Now this could have been due to other members of the team explaining it to them, rather then them figuring out the other participant's code manually, but isn't that what you'd do in the real world?
Those folks that could explain problems they'd encountered often noted that they asked for help from other members of the team. By this point in the class, I could already recognize the coding style of each student anyway, but I really appreciated the honesty, and how they did work together to produce something.
Yes, there were some (I'd say 5%) that were tricked up on the exam and showed that they didn't actually write much of the code, nor understand it. However overall folks did a good job acting like they would in an ideal group coding environment.
The only problem I had with group projects was with Thurston Howell (or at least that's what I called him in my mind, due to his attitude and voice) who had one of the classic coder failings. He got so caught up with getting the perfect interface -- being able to use emacs-style data entry editing abilities and such -- that he never got any of the backend stuff even started. Those in his group didn't know where to go, since they had nothing to plug their code into. Here's where a normal group may have a manager who could step in and help out, and they didn't quite have the real-world mentality that would have allowed them to come to me and tell me what was holding them up. But other than this one incident, group projects have always been an excellent thing.
I am currently attending a state university in Minnesota and we have several classes that focus on group work in the computer science major. The class I am in this semester is called Systems Analysis and Design. One of the main goals is to work together with a small group (4-5). We take an actual database design problem from local companies and try and work trough them. Our professor allows us to "vote" students out of a group (sorta like survivor). If a student is voted out they get all group work up to that point then work the rest of it on their own. I am glad that we have the faculty that we do, because with out them I do not think we could have these types of courses.
Personally, I feel that work done in introductory classes should be done individually, with group projects in upper-level classes. There's a few reasons for this.
One, in intro classes, the purpose is to teach basic skills/concepts that everyone needs to know. If you work in a group, you miss out on some part of the project, and don't necessarily pick it up on your own. Working solo is the only way to guarantee that everyone learned what was needed.
Two, lower-level classes are often where students figure out that a major is not for them. I've been in the unenviable position of having a group member drop the class halfway through a major project: it's not a good situation. This is more likely to happen earlier in a degree program, as people switch majors.
Three, students at introductory level are often at very different skill levels. One freshman in CS might have been coding in C since age 14; another might never have coded before. Putting these two people in the same group at this point is unfair to both. Once the intro classes are finished everyone (supposedly) has the same base level of knowledge, so nobody is as significantly dragging the group down.
Lastly, upper-level class projects tend to be more complex and lend themselves better to dividing among multiple people than simpler intro-level projects. By that point the basic skills are down and you are learning to apply them to real problems; part of that is figuring out how to plan and subdivide problems into smaller, manageable pieces. You're problem-solving, not just learning how to code. Larger projects make more sense to divide up.
This is all just my opinion, of course, based on my experience. YMMV.
"This message is composed of 100% recycled electrons."
There are a lot of opinions out there thats for sure! I havent seen too many from the people who make hiring decisions though. I have made hiring decisions for hundreds of programmers, so maybe you should listen up.
While working in a team is a great skill and every manager wants that, rarely can they test that ability before the hiring decision. What they can test is your technical knowledge and interpersonal skills. Sadly, especially of late, the vast majority of applicants are failing the technical knowledge portion; the number one reason programmers fail to get hired is lack of skill. The reason for this is that the schools are teaching crap these days, and giving degrees out to people who can't "program their way out of a paper bag".
Thus, my advice to you is, hunker down on the technical skills. Teamwork you can learn on the job. [or for those lucky enough, in internships and co-ops. the best way to learn]
the other day on slashdot someone asked why you have to take all these other bs classes when you just want to learn how to be a computer programmer and today someone is asking why you don't learn anything else except how to program. maybe these two slashdot posters should get together and talk. :P
I understand that collaboration is wonderful and instructive, but you are bound to the rules set by your university/CS department. And I'm sure that those rules seem horribly unfair. But in the true Slashdot fashion, instead of trying to change things at your school, you come here to whine about it! And since slashdot always seems to have a good crop of naive college students who have nothing better to do than post comments, you get plenty of your peers to whine with you.
Kids, pull your own weight, or make waves where it counts. Trust me, your university isn't going to give a shit about 200 slashdot comments backing you up, probably because they know that the people posting on slashdot are at least as lazy as you are.
Or at least find another forum to post this on. Don't worry, Slashdot will still be tiresome and repetitive without the whinings of "I want do do my homework as a joint project with my friends!"
CVS
-- botsex is {grep;touch;strip;unzip;head;mount}
I am also a CS major and i hear what you are saying about working together as a team.. Although, I think the skills being presented in my courses are focused more on how well you, as an individual, can contribute original ideas to the team.. How well you can form your own solutions and analyze logic from your point of view.. Once you have developed that skill, then you may bring it to the table where other developers may then apply their analytical skills to your ideas.. this will allow many indivduals to bring their own ideas to the table and combine the best ideas of the individuals to create the best product from the team...
e0-
I found that in my higher level classes, slackers, idiots, and free riders were less of a problem than they were in lower division classes. That's because it was a small enough department that by then we all knew each other. Once we could pick our own groups, all the smart, hard workers would gravitate together. The slackers would end up in groups with other slackers, and turn in crap.
If the Pointy-Haired Bosses of the world can't tell that thier "team" consists of two guys doing the work and 5 leeches, what makes you think the pointy-haired college professor can? I mean really!
-- I Am Not A Terrorist.
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.
At Aalborg University which i attend everything is teamwork.. about 2/3 of your semester grade us evaluated on the basis of a Problem oriented group project.
This means that you have to work together with 6 or 7 people on a projekt. You have to "agree" on everything, cause we are all equally responsible for the outcome.
After the paper has been turned in app. 100-120 pages + product, there is a 5 hour exam.
At this exam you present your project and your project-counsler and a sensor asks questions. After the exam each student is individually graded.
Ofcourse there are upsides and downsides to this approach, but as a whole you learn a lot because you are forced in to discussing almost every decision. OTOH some students can get by pretty easely and lets his group do the work. (It is possible to kick someone out of your group if the don't take their part of the work, or always comes in late. etc.)
Anyways, if you like working in groups come to Aalborg University, Denmark.
The most extreme example involved a class of twenty doing an engineering project senior year in college. When the rubber met the road, only five of us truly cared enough to finish the project. We received A's for our efforts and the rest of the class received B's and C's. Who's smarter?
On the positive side, working in pairs or groups of three (maximum) seemed to work out. It's not easy to be a free rider when there's only one or two other people to leech!
Helevius
I also bent the truth a little bit to prove a point. So I guess I'm a liar too. Settle down.
The point is that people do this which makes it very difficult for small group projects to work.
Forcing a group to work together for an entire semester (like many senior design classes do) tends to be a little better of a scenerio.
As a Mechanical Engineer, our curriculum had alot of group design projects in your junior and senior years. Every major class had at least one group project, sometimes more. It was always frustrating to get put on teams with slackers. Some people were slackers on the team because they were dumb, others slacked because they had an insane course load, or they worked many hours so they just didn't have time. The result was the same either way.
Some professors had students rate each other, but most didn't. Groups were usually picked at random.
I hated the group projects because of the slackers, trying to coordinate schedules to work together, and because you usually were working with strangers.
Group work at work is better because people aren't strangers, scheduling problems aren't as big of a deal, and so far, I haven't found any big time slackers around here.
In school, the best group size seemed to be 3 people. It minimized scheduling conflicts and gave you some help if one other person was a serious slacker.
If you got an uber-slacker on your team, then people would usually go to the professor about it. Some group projects had group reports, others had individual reports.
Your password has expired, please login to change it.
You'll have to find a way to account for each person's abliity though, which isn't easy.
This does happen in the Real World. Where I work (state government), we have some very talented folks, some that work hard but are less talented, and others who are very motivated, but inexperienced. We do have a few (very few) that seem to be warming seats, but they mostly work on the legacy systems, not the web apps.
A good project manager tries to match the skills available in the team with the work that needs to be accomplished. No, it is not easy, but it can be done.
I had the GPA and those friggin slackers knew it. Every group project I've done (save one where I happened upon extremely exceptional teammates) has ended similarly: the slackers slack while I pull the whole darn project together. At least the problem with group consensus was not present because the prevailing attitude from my team was 'yeah, whatever.' They knew I wanted the "A," so they left me out to dry.
Screw 'em.
It's different out here but in the college setting it's a lousy thing to do to the summa cum laude student who has enough load to tow without that kind of added grief.
--
Is madness a syptom of genius or vice-versa?
... exists between collaboration and excessive collaboration. There's absolutely nothing wrong with seeking help from your peers - but it's important to know what standards are being used to determine academic dishonesty. But then again, there's that saying in academia: "Copying the work of one is plagiarism. Copying the work of many is research"
I know of many friends who would not be in CS if it weren't for their friends. But there's only so many ways to get a program to print out "Hello, world"
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
I'm in the Informatics program at the University of Washington and we do almost 100% of our assignments in groups. The method of making sure everyone pulls their own weight is simple: group evaluations. Everyone in the group evaulates the others and themselves.
The one way I've seen this work is through well defined seperation of work. In other words, the instructor should provide each group with a well-defined project definition, and describe the work that each student needs to do for their part of their group's project.
For example, we wrote a simple web server in my CS class, and each member of the group had a different responsibility - I was responsible for writing most of the network code, and another student had to write the parsing of the HTML, etc. Each student works on their section individually, but you must work as a group to define APIs, and to integrate each disparate module of code. This doesn't *truly* mimic the real world, but it comes close.
Slightly off-topic, but most CS departments look at group projects with a certain amount of scorn - in their opinion, it's not the job of the CS department to teach software enginnering (which is what a group project proports to do); they'd rather teach fundamentals of CS (algorithms, data structures, etc), and leave the theories of software engineering to the workplace.
The pomposity of the professor is inversely proportional to the difficulty and importance of the subject being taught.
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
Hi -
my bachelor's degree in CS essentially followed the following pattern:
Start off working on small, toy problems - how to sort things, how to read mouse input - basic low-level stuff. This was done individually, and each student submitted their homework and lab work seperately. Discussion wasn't forbidden - but you were expected to try to solve these problems on your own. In classes of no more than 20 students the professor had a good handle on things.
Later, you worked up to larger projects - still working largely singly - but learning to work with existing code libraries. Some computer related classes started to involve some team work in terms of doing studies and presentations.
In your last 3 semesters teamwork was more stressed, with 3 large, group projects, one per semester. Teams of 4 to 5 students working on a software system each.
I think that this pattern worked pretty well. You do sort of have to get the cheesy basics down first, as it will accelerate your pace of work when you team up.
My $0.02
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.
I'm actually in the CS Lab at RIT right now, posting this comment on an Ultra 10. We do group projects here in CS at RIT as well, and we also have a very strict academic honesty policy. Recently I did the first part of my project with another student, as was directed in the project description. We only had to submit one program design, but we each had to submit a partner evaluation. (All our stuff is submitted electronically using a UNIX program called try). Basically you wrote a few lines about how you felt about your partner's work. If you did the whole project and they slept, you said so. And vice versa. The professors alter grades accordingly. Very rarely is someone so immature as to be disonhest on the evaluation.
The GeekNights podcast is going strong. Listen!
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 groan when someone says, "Couldn't we do this in a group?"
would be a really practical way of handling this, especially since your using CVS anyway, right?
If there is hope, it lies in the trolls.
I'm currently in my second year as a CS major and my University has the same academic policy but pair programming is not only encouraged it's needed given the scope of many of the projects. First year we all worked alone but the projects were a joke, second year everything a good deal harder and a partner is a must. All the upper classment have partners for all their classes and assignemnts. Hell on our quizes we're allowed to use any resource save another person to answer the questions {http://www.google.com here I come}. The point that my prof has been attempting to make is that it is important to learn how to research things and to work with other people.
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.
I've always thought that there should two types of technical classes. Using CS as an example, there would be classes on algorithms, structures, etc.; and then there would be classes in the implementation of these concepts.
Most classes try to combine these, but I believe the conceptual part of the class need to be separate from the implementation part of the class, i.e. a lecture/recitation/lab separation.
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 go to VT, and while we don't drive our honor code up the wall like some other school, our CS dept very much discourages any group work whatsoever. Basically, if you haven't holed yourself up in complete isolation till the program is due, you've probably violated the honor code somewhere along the line. They're so fervent about it they have a program running(i forget what's it's called, moss something or other) that will look for similarities between everyone's code. I'm not sure how well it works, but i know a few friends of mine who were caught cheating on a program their freshman year(though they submitted identicle code, so as far as i can tell they deserved it).
Got Freedom?
Thinking?
I am a student in an Electronic Game Design program at a Canadian College (I myself am American). As a requirement for graduation from the two-year program, a student must be a member of a group that has a final project - referred to as a Product - that is of sufficiant quality to be at the very least an excellent demo in ones resume. Ideally the product should be of sufficient quality to attempt to be published - and at least one product I can think of that has come out of the program has been published as a B title.
In the program, the product development groups form fairly early in Term 2 (the Winter Term) and the rest of the two years in the program is spent, barring breakups and expulsions, working with those same people. The groups spend the first year documenting their product - our detailed design document fills a couple big 5" binders to capacity.
In the second year the product is expected to be coded and built, to the specs laid down in the documentation. There is a prototyping process in place as well that expects a functioning prototype to be ready around the end of the first term of the second year (Term 4).
With all of this time spent working on a major project with a group, with weekly meetings with a faculty mentor and regular design review meetings with a board of instructors, those people who are not doing work are identified fairly quickly. There are procedures in place to remove these people from groups where they are not being productive. In fact, the group I am a member of has such an unproductive person who is skirting right now with removal from our group.
When I came into this program I had only had very negative experiences working in groups at other Universities and in High School. I have learned that group work is very good experience but it must be done over time with a large amount of close interaction with the faculty, so they and the students can constantly keep tabs on the expectations and performance of those on both sides of the classroom.
In July O7, I got a mac pro. There's no punchline. Just endless joy and wonder.
I agree that you should be able to cooperate with other people without it being cheating. At the moment several of my lecturers will let us discuss problems and look at each others code/assignments as long as we don't copy and your work is unique enough. Others just ignore the fact that people are copying (two individuals got caught copying verbatim in 3 papers last semester and weren't kicked out).
I hate formalised group work.. last group assignment I had to do was in a group of 6, 3 dropped out quickly, 1 stuffed us around before dropping out the day before due date and another guy who was willing to work but not too bright.
I had this technique used in my graduate CS courses as well.. the projects were all too huge to be completed by a single person in a reasonable time.. we always grouped up.. typically 3-4 students.. it was very productive and since we graded each other for contribution, we kept ourselves honest.. not did we "downgrade" slackers, we also "downgraded" over-contributors who wanted to do it all themselves..
but on the other hand.. i think not allowing code re-use was a BIG minus.. in the real world i find that being able to reuse code and WRITE reusable code is what its all about.. u HAVE to teach CS grads how not to go about reinventing the wheel EVERY time they need a database connection class (for example) thats just a waste..
I'm doing a course at Monash Uni in Australia called Business Systems (dept. of IT), and over here the "group assignments" are fundamentally flawed:
1. they are too short to be able to divide it, we're talking...3-4 hours work...3 major sections...amongst 4 people
2. the people who do these group assignments lack ability, or drive, or both. Meaning that in the end, one person does the work and the rest "ride" their way to a pass, while dragging down the guy who worked his arse off.
In the real world, inadequate people get the sack, and arn't a problem anymore. In uni, they get a free ride.
To top it off, the people who run these subjects "encourage you to figure it out" - read: don't care
Scrap the group assignments...all they do is drag down the people who care about getting more than a pass.
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
I go to uni at UQ (brisbane australia) and have team projects coming out of my ears! 2nd and 3rd year we have 1 whole subject a team project with elec, comp sys and software engineering students working in teams together on a product. "Software testing" I'm doing all the assignments are in teams. Each team has to split the marks between each other and each member has to sign their approval. In some cases we give marks to the other members of the group. In one subject that has only group assignments and a final exam, if you don't go as well on the final the assignments don't bump your mark up. In robotics all our labs were group work. There's a whole year group IT compulsory subject. In fact everyone get's rather sick of group work - you always end up putting in more effort cause other members slack off.
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
This is what he always said.
If you talked to someone about an assignment in detail or saw a code fragment (say helping them debug something), anything you can still remember after an hour or two of going off and doing something else (ie. another homework, read a book, watch tv, or whatever) is fair game.
I'm a CS student at Syracuse University, and my data structures course is set up as follows: all homeworks and labs can be done in collaboration with 1 or 2 other people. One copy is submitted, with names attached. The exams are still solo, so your individual ability is reflected in your final grade. I think this arrangement is an extremely effective one.
________________ James McCollough
i am in a programming class this semester where our professor encourages us to collaborate. he's told us that we'll get better code in the same time or faster working with a partner. if you work with a partner (of your choosing), you both get the same grade. we aren't required to work together, however, and can switch partners with each homework,so those who don't want to carry someone's else weight don't have to. the result is, i understand the homework better than just muddling through on my own, and those who work better alone can.
now if we can just convince the rest of the professors to do it... =)
No matter how prestigious you think your school is, at *least* half of the students there are complete dumbasses (which, coincidentally enough, mimmicks the real world...). Every single group project I have ever done, from first grade on up through college, is an exercise in taking advantage of the Smart Guy. We all know it's true, and the stupid people pretend to ask for "real world" group experience because they are lazy, plain and simple. Working in groups for school is NOTHING like the real world because in the real world, the people who sit and stare while the rest work get fired.
It is impossible for a professor to really evaluate who did what unless they're sitting there while it's happening, but in the real world, the idiots will eventually be found out.
C++ programmers do it with class.
Perl hackers do it quick and dirty.
I've gotta learn perl.
In the CS class I'm taking right now I have a new group project almost every week. It's a lot of work but the material has been easy so far (for me).
Actually, at the school that I am attending, ALL of the undergrad 4000 series (senior) CSC courses require collaboration. You are required to work in groups of 2-4 and to document your contirbutions to a project. Each member of the team is evaluated both by their peers and by the instructors. It seems to work out fairly well, especially since many of these classes require some particularly hefty programming requirements.
It probably would not be a bad idea for you to talk to the Dean of your college or the Chair; if they have a lick of sense, they will realise that most of the bad programmers became MIS majors about the end of the Sophomore year, and that the remaining students need that sort of collaboration. Point out that more sucessful graduates bring in more DM/$$$/Whatever of contributions than do non-sucessfull graduactes.
-Sysanalyst
Pardon me, but would you care for a jelly baby?
Would you care for a jelly baby?
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
at my college- there isn't enough programming within the curriculum. People who want to program in their lives go through this program, but if they don't want to learn C, java, perl, or anything else- they don't have too. The little bit of programming available/required is not enough for a programmer to know what they are doing once they hit the market. Is this a common thing? Do employers tend to teach programming on the job? seriously, i'd say 75% of the students in my class will graduate without knowing much more than how to define an int.
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
At least at my school(Penn. College of Tech.). I'm enrolled in the Electronic Engineering program and the only group-work we will see is near the ends of our educational career.(like 4 yrs from now!). The labs are excellant, but groupwork should be integrated more than it is.(nill).
Regards,
-Jamie
*-PGP Please!-*
The final exam asked very specific questions about the project that you supposedly wrote. Things like:
Each group had a file that implements frobbing. Your group's file was named:
(a) frob.c
(b) frobulate.c
(c) frobnicate.c
(d) Frob.c
Most groups searched through a graph in some way. Your group implemented this through:
(a) Depth-First Search
(b) Breadth-First Search
(c) Linear pass through all nodes
(d) My group did not search through a graph
Each group had a data structure for storing bars. Your group's data structure was:
(a) A singly-linked list
(b) A doubly-linked list
(c) A simple array
(d) A heap
And then there were a number of questions asking you to identify your group's code from a list of code snippets from each group.
If I were teaching college I probably wouldn't make any special effort to catch cheaters. Somebody who bases thier whole education on cheating will eventually fail. In the long run, it is just easier to learn than to cheat. Especially when you get to upper division courses. If you don't know the material from the lower division courses you won't even know where to begin to cheat.
My Weblog
Well, I had a long winded argument that got erased after I previewed it, so here's the short version. People will never contribute equally to a project unless they are adequately motivated to do so. Some people don't care if they get an A or a C so why should they spend all that extra effort on something to get an A. From their perspective it just doesn't make sense.
Here is the problem. Too many people take a class because it is required to graduate, they attend, do homework, and code projects to get a grade (A,B,C, or D). The real motivation ought to be aquisition of knowledge and practice in your field, however somewhere in the world of academia the primary goal for many became a grade/diploma. What's the best way to make people do work because they want to? Remove the grades. Make the work more interesting/applicable.
In the ACMs, you get three people, four problems, four hours, and one computer.
I haven't done it yet (I'm a sophomore; its pretty difficult to get very far), but I know I will at least be going to prelims this year.
Maybe this is something profs should recommend for students that have a hard time integrating themselves. Don't force it like torture, but the competition aspect can make it pretty fun, and so non-team-oriented students might find it interesting and challenging.
Students in their first year CS take part in the programming team, in their second year do a bit of project management, etc. And, BTW, these are full, real-life projects that have to be delivered and meet a deadline. No simulations what so ever.
Even in Holland I believe, this is a rather unique concept that seems to work quite well (although I've never done the course myself; I didn't do CS).
I can't find links for all the parts of the course but a description can be found here (Dutch, Babelfish probably needed; look for a link "colleges", upperleft grey box, then in the small print column on the left look for GIP4)
As for group work, there are ways to get around the "free rider" problem. I have experimented with peer review: Each student in the group gets 100 points per other member, and have to distribute those points among the other members, but cannot let two students have the same number of points. Works well when I spring it on the students after the fact (it is a fairly new method) but could be tricky if the students get wise and start gaming the system. Peer review is uncomfortable for the students, but they are much harder graders than any teacher I know...
Espen
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
If you are using large groups then there is a lot of opportunity for people to do nothing. In groups of two or three there is no way you can hide the fact that you have done nothing (or at least it is very difficult).
During my undergrad education we did all our practicals in groups of two people and you got to choose your partner. Choosing your partner was also great because it meant that you could pick someone who you knew you could work with. The slackers got known very early on and people who wanted to do good work avoided them.
Lastly, working together should not be completely removed even if students have to hand in their own work. I would rather have a student be able to do the work after asking a friend, than not be able to do the work at all. Of course, each student still has to do their own work, so work that is nearly identical is still unacceptable.
There is no perfect solution to group work, but these ideas might help.
The university I go to had a reasonably good solution.
Some projects would be solitary, and you wouldn't be allowed to cooperate. Some of the projects (often the more theoretical ones) would be solitary, but cooperation would be allowed, and some of the projects would be group assignments.
The group assignments often worked the same way, where during the project you had to regularly come tell what everybody did. The C++ programming project was very good in the way that every week every teammember had to put on the site what they did. If someone coasted by it was very obvious from what they typed on the site. If someone lied about what they did there would either be work not in the result (coming down back on them), or dual entries in different logbooks, which also was obvious very quickly.
Eventually we got one person who didn't cooperate (there's _always_ somebody in the team not cooperating), and we had to bring it up to the higher management (the team coordinator). They guy got a zero for his group assignment, while the rest of us got high marks.
You don't have to take it if someone doesn't add to the result. What is crucial though in a team is well defined leadership. somebody (or sometimes two people) needs to be in charge and his or her decisions are final. Otherwise you lose half your time in discussions.
There's a lot to computing! I think I will discuss the field as split into two distinct parts: achedemic studies that further the field and create new and exciting directions; and engineering where building for robustness and predictability are paramount.
In achedemia, the individual does a lot alone. New depths are probed and exciting issues are researched. There is rarely the scope for putting several people together to work on one research point. The preparation for this is the achedemic study you do alone at university. Learning the basics of search/sort algorithms, data structures, language constructs, IO and communications, image or sound processing, etc. These things are best done alone and can be tested individually to give results. No matter where you go with computing, you'll need these basics.
In engineering, you work in a large team to create a robust and predictable system. Each member brings something to the team, even if it's "just" key-tapping programming. Essentially, nothing is particularly new and everything ought to be tried and at the very least tested. Time is important too, so using well known techniques is mandatory and research almost out of the question. If a University is preparing someone for 'real' work the group projects are the order of the day. Assessment becomes more like a workplace review, peer-reviews are useful too.
In my experience, these two distinct items are often mixed up and learning/research tasks are hindered by group politics. Groupwork tasks are blown out of the water because the research aspects overrun. Perhaps I'm saying that my experience is that I was often taught by stealth, not really knowing what I was supposed to be learning in a particular excersise/module/etc.
Mebbe the system needs to change, mebbe I should have taken more notice of what was going on.. but I hope Uni-starters get something from these ramblings to help deal with the apparent mixup I felt :)
Courses which teach basic skills like programming Java or assembly should be done by a single person. The university has to be certain that the groundwork is laid for future courses. This is similar to exams which are per person (math exams for example). You need to prove individual prowess.
;) ). But I also got sick of assisting a friend of mine who tries hard, but just isn't that good a writer. The problems caused by the size of the group just took so much of my time that I was unable to assist/steer him properly.
Courses which teach concepts are often best done in groups. Students can assist each other in the understanding of these concepts. Examples include courses on graphics programming, network programming or neural networks. This is similar to papers written by a group of students on advanced concepts. The understanding of the concepts is more important in these cases than the assurance that you can program a particular problem.
You need not be able to program a neural network yourself, but you have to understand the concepts so you can learn it quickly when necessary, communicate with a neural programmer and understand the limitations/possibilities of the technology. That is the difference between a college and a University, the first mostly teaches skills, the second mostly teaches concepts. The University will allow you to become a broadly educated person. They expect you to mostly build up your own applied skills with this knowledge.
I think that a self-selected group of 2 people is usually best. They are compatible and will assist each other in understanding the more challenging concepts. Leaving the entire exercise to the partner feels wrong and might mean that the partner won't be your partner in future courses.
In larger groups there is a strong tendency for weaker team-members to leave the work for the others. The smarter team-members will also find it too much work too spend effort on spurring/assisting all the less intelligent and/or lazy team-members. I have had this problem a few times, writing something myself was less work than first having to whine for a lazy bum (who was assigned to my group) to do something and then correcting the work to be A material. And even then the writing wasn't that good (don't judge me on my spelling in this post, I'm Dutch
Groups > 4 are usually a drama. We had a course with 20 students, to learn how to cope with this. Very educational and extremely frustrating. The larger the group, the more uneven the contributions of team-members will become. I know of no good solution except to limit the size of the group and/or prevent weak students from being part of the group. Once you're in a large, uneven group you're fscked.
I have also become more and more self-reliant during my study. If somebody wants to get by on by back, I don't care anymore (although I won't invite them to do so). Studying isn't about getting a BSc or MSc, but about learning and improving yourself. The people who lean too much on others will get hurt at the final assignment (we have a 5 year program, with a 1 year individual project at the end to show your prowess) or when working at a company.
Besides, I also had to lean on people on a few occasions, sometimes an assignment just is too complicated for you or you can't keep up with your partner. Helping each other isn't wrong, up to a point.
PS. The University has to assume you have a basic level of computer expertise. We are expected to know Word, while students of Chemistry get a course. It would be a waste of time on 99.5% of us, so it's a good decision. The 0.5% needs to pick it up themselves. The gal who didn't know zip should partner with a few others of the less informed and assist each other in these things. They shouldn't hamper you with it. Unfortunately some professors like to randomly assign groups. I've never seen much good in this, having little choice in selecting your own group is frustrating enough.
The Drowned and the Saved - Primo Levi
I also did a CS course at university and in fact designed and wrote my university's automatic anti-plagiarism system as my final year project. So I know how strict they are on copying.
However, I now teach my company's Structured Programming course to new graduates starting here, and the first thing I try to hammer into them is that there is absolutely no point whatsoever in trying to do something yourself first - it's quicker, easier, and will probably be more reliable if you copy some existing work.
Obviously, this is entirely at odds with the University system, but re-use and sharing of code is an incredibly important issue in the "real world". In my opinion there's no room for code and knowledge hoarders in a large organisation (such as mine, with thousands of people employed in IT).
Paul
pcardno@mmm.com
--- Band: Joey Ultra
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.
Well I'm glad they didn't,
the pedagogic misery of using the best programming language for each academic viewpoint made me learn:
Simula, Smalltalk, Modula-2, Pascal...
I teach computer science course and programming courses in particular (www.uml.edu). I DO encourage students to work together and to add to a project on sourceforge or freshmeat but find they are hesitant to do so because they are all so competitive. Even on the groups I force to exist, the students tend to work on their own and from scratch with little real cooperation like I've experienced in the workplace. I'd be interested in suggestions (which have worked) on how to get past this barrier and encourage them to form teams that work together.
That's six minutes during which it will not be possible for me to cause an accident!
The moral: if everyone speeds, you won't be driving as long, and cause fewer accidents!
I never thought of it that way before! Thanks!
I'm a leaf on the wind. Watch how I soar.
I occasionally do interviewing of college hires. I like to ask questions like "Tell me about a project where you worked with other people." and "What was your role in the project?" If it sounds like the candidate has never worked in a group or doesn't get along with others, I will usually take a pass. In our workplace, the ability to work in a group is crucial. I think that colleges should insist that at least some projects are done in a group.
At the school I'm currently attending, our upper level CS\IT classes are lock-step (you're with the same classmates in the same classes through the whole curriculum) and our teams carry over through the whole program. This has it's ups and downs.
For one, the fact that you're in the same team through the whole program brings a new level of accountability into play, because if you let your teammates down, you WILL hear about it (and yes, you CAN get kicked off the team, it's equivalent to failing). This also tends to model workplace teamwork fairly well because of the timescale.
Basically, every class has a team project, whether it's a programming class, networking, databases, etc. and your team gets a grade on the project that is then weighted based on a peer review at the end of each class.
This also has the side effect of forcing the quicker learners in each team to tutor the rest of their team.
The only problems with this system I've encountered so far (I'm about 9 months into the program) is that some people learn alot faster than others and tend to carry more of the workload simply because they catch on quicker.
After all it's a highly accelerated program and deadlines are deadlines.
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
If you stop and look at it, your average group project is kind of teaching the lessons of the work place. I know where I went to school we usually had a group project in each class. You learned over time who you'd like to work with and who you wouldn't. Some people were satisfied with a C... just like in the workplace (you know the guys.. the ones that *aren't* reading slashdot with their morning coffee but salon.com/sex instead). There are people who want to do well but are just dumbasses (like the girl in my third year project who was not aware that you had to "unzip" some files and had no grasp of an "object" despite three years of java homework) and you hope these guys aren't hired in the first place. Then there are the guys I usually never see in the workplace: the guy who knows nothing and is convinced it will be easier to spend his career getting the work from someone else rather then actually doing it. (One guy we worked with once insisted he did not know how set two columns in a MS Word document).
So group work kind of prepares you for all the loonies in the end. Depending on how much drive you have you can still do well with a team of dolts.. or you can do just enough to get by.. or if the team really clicks you can excel. Just like the workplace.
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