Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Computer Science Students Unite?

By elenchos in Op-Ed
Sun Jan 07, 2001 at 06:33:24 AM EST
Tags: Software (all tags)
Software

The most long-standing dispute between the students in my computer science program at Gonzaga University and our faculty is over the the students not being allowed to collaborate on programming projects until our senior year. Starting in computer science I, we are read the riot act about this policy and while each professor may have personal quirks on everything else, they defend this rule as sacred. I am told by students from the CSE program at the University of Washington that they go so far as to compare the executable times of a classes programs to catch "cheaters."

Is this a local attitude, or do computer science programs in general forbid novice programmers from helping each other? Isn't programming different than writing English papers? Further, does this raise broader questions about how programming should be taught, or if it a can be taught at all?


You might immediately object that I am talking about undergraduate computer science as if it were nothing but a vocational school for writing code. I do realize that CS is a broader field than this, but a vital component of this field is programming, and that is what I am focusing on here.

In any other academic field, this would seem to be a cut-and-dried question. We're talking about plagiarism, aren't we? Who could justify that? My first answer to that would be to compare programming projects to the labs that are done in the sciences: you always want to be working with a lab partner in chemistry or biology. Or do the sciences suffer from plagiarists graduating and going to work without having done their own work? Why isn't copying lab work a problem in these fields? The same is true in engineering; a team approach is seen as being both educational, and a realistic parallel to how professionals work. Objective tests, if nothing else, are sure to weed out students who are truly not pulling their own weight. The benefits of programmers collaborating are covered well in a list posted by jrh. It boils down to the surprising fact that programming well is as much an interpersonal skill as it is a lonely pursuit of obsessive detail freaks. It is not easy for your code to play well with others if you don't.

I also would want to point out that the programs that are written outside of the undergraduate realm are almost always done in teams, usually of two. They call this programming in the `real world,' although I am skeptical of the existence of this `real world' they speak of. If you want to be old skool, you can work for a government agency or defense contractor, or you can pick any other environment that suits you, from financial institutions to Silicon Valley to the paranoid, cult-like atmosphere of Microsoft (shut up, I read all about it in Microserfs). Beyond that, there is the wacky world of dot coms, independent consulting, academia of course, and the whole other culture of open source. Given all this diversity, I hesitate to trust any claim as to how `real' programs are written. I'll leave this aside; you may pick it up as you choose.

So why worry so much about snippets of code being copied? One theory is that good programmers are born, not made. The process of `educating' them is one of culling out the mundanes, the mere mortals, so that only Real Geeks are given CS degrees. So an undergraduate CS coursework is really just a hazing ritual, not a training ground. I often think this, but don't believe it is entirely true. An enormous amount of useful learning can take place in school; it is just that so much learning continues after we leave that the schoolwork seems trivial by comparison.

My own best argument is that my own most vividly remembered learning experiences of programming were when I worked with several others (in spite of the taboo against it). Even after I had finished and perfected my own code and turned it in, heading for the lab and working with others on their programs added enormously to my knowledge. I was always stunned to discover how many different ways there were to solve the same problem; solutions I hadn't dreamed of, and all the different ways there were to write the same algorithm. Helping someone else work through the problem in the context of their solution increased the depth of my own understanding of the questions involved by orders of magnitude.

So what do you think? Is it much different in Computer Engineering or Software Engineering? How about students working together in the liberal arts and the sciences, in mathematics? Do most schools restrict collaboration too much? If so, is there any point in bitching about it? Have you ever been to the `real world?' What was it like? Were the people there like us, and did they fear you?

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Programmers should start working together
o on Day One. 39%
o after one progrmming course. 8%
o after one year. 16%
o in their junior year. 6%
o in their senior year. 6%
o only after they graduate. 0%
o never! 2%
o You mean there are other programmers besides me? 19%

Votes: 119
Results | Other Polls

Related Links
o Kuro5hin
o computer science
o Gonzaga University
o University of Washington
o posted by jrh
o Also by elenchos


Display: Sort:
Computer Science Students Unite? | 84 comments (83 topical, 1 editorial, 0 hidden)
Students (4.00 / 10) (#2)
by Sneakums on Sun Jan 07, 2001 at 12:31:40 AM EST

I know a number of undergrad CS students, and many of them simply will not write their own code unless forced. If you can't program on your own, you sure can't program in a team.

Then how do they pass tests? (2.33 / 3) (#3)
by elenchos on Sun Jan 07, 2001 at 01:09:09 AM EST

[no text]

Adequacy.org
[ Parent ]

Passing tests (3.50 / 2) (#23)
by mahrberg on Sun Jan 07, 2001 at 09:56:11 AM EST

Many CS tests don't require you to write an entire program. I know quite a few folks in my CS department who can't code their way out of a wet paper bag and can still do fairly well on the tests. Part of it is luck part is memorizing the right stuff, or many of them have copies of old tests or friends who have previously taken the class.

[ Parent ]
old tests (3.50 / 2) (#28)
by cryon on Sun Jan 07, 2001 at 12:18:31 PM EST

They get together with their buddies, sometimes a dozen or more, and each one has a copy of an old test or two. All together they have just about all the old tests that particular prof has written for that course. This strategy works well for my school b/c it is small and there are only about 3-4 profs who teach the core CS curriculum, and each one tends to teach the same course semester after semester.

I don't do this, and I don't generally study all that much for tests except for the final. I sometimes get B's on non-final tests, but do very well on the program assignments, so I get A's overall.
HTGS75OBEY21IRTYG54564ACCEPT64AUTHORITY41V KKJWQKHD23CONSUME78GJHGYTMNQYRTY74SLEEP38H TYTR32CONFORM12GNIYIPWG64VOTER4APATHY42JLQ TYFGB64MONEY3IS4YOUR7GOD62MGTSB21CONFORM34 SDF53MARRY6AND2REPRODUCE534TYWHJZKJ34OBEY6

[ Parent ]

My experience at university. (4.55 / 9) (#4)
by hypatia on Sun Jan 07, 2001 at 01:12:43 AM EST

I study Science/Arts at the University of Sydney and have taken courses in Chemistry, Computer Science, Mathematics, Philosophy and Linguistics.

Here is a brief summary of experience in non-CS:

  • Maths: policy explicitly allows you to collaborate with other students, but separate solutions must be submitted.
  • Linguistics: has quite large tute sizes, which meant I didn't get the opportunty to meet many other students, and there was no work that required working together.
  • Philosophy: group discussion takes place, no group work
  • Chemistry: group work is done in laboratories, and sometimes on assignments.

So far science courses are winning on group work :)

Now computer science was redeveloped on a policy of problem based learning some years before I arrived. This apparently is the only university in Australia that uses PBL to teach CS, it's quite the fad in medicine schools though.

Basically it means that your tutors are there to help you find resources, not to teach you to program. When you start out, about three quarters of the classes have little programming experience. You go over code together and try to see what it does, you modify existing code, and then you write small assignments.

All of this is done in groups. You are meant to be able to help each other code, assign coding tasks based on each other strengths, weaknesses and learning needs. It's meant to teach you how to be independent, work in teams, and is explicitly aimed at industry needs. There are bonus marks for code-reuse from other people - if you put the code of someone outside the group in the project, with proper acknowledgement, where it fits, you may get better marks than if you wrote it.

Unfortunately this process often doesn't work. USyd splits CS (and science students in general) into normal and advanced streams, based on previous years results. I have seen the process work quite well in advanced* but have heard terrible reports about it in normal. This is partly due to the increase in students taking CS courses with no real interest in programming, or perhaps computers. Because marks aren't individual either, students in their group have to shoulder the extra workload in order to get the marks they need. I know some people who are bitterly disillusioned about the fact that they're expected to catch the poor programmers, and try to help them and teach them, and at the same time could be learning new and funky techniques.

* except in the cases in first year, where students are assigned to advanced on overall high school aggregate marks, rather than programming ability, since they don't want only existing programmers taking the courses. Some students in first year, with general academic performance, but no specific programming ability, get lost in a group with someone who has been programming for a decade.



This is a good thing. (4.25 / 8) (#5)
by rebelcool on Sun Jan 07, 2001 at 01:33:15 AM EST

I attend the university of texas at austin where im an undergrad in CS, where the same rules apply. I don't really have a problem with them, though from time to time on obscenely difficult LISP projects I would call a friend to see if he has an idea on how to solve a problem.

Anyways, first of all, alot of students in CS programs are there for the money. CS will make one somewhat wealthy. Like being a doctor, only with alot less schooltime. These types of people don't give a whim about the art that is programming. They just want cold, hard cash and are not above cheating to get it. Given the chance i'm sure most of these types would (and probably still do) copy (or even pay) others to write their programs.

They are not good programmers, nor will they ever be. UT's CS dept. has a "pre-CS" selection of courses (java, functional programming, c++, philosophy, calculus I) that one must complete, along with minimum GPA, an essay and then UT will only take the top 300 students into the true CS major. Hard? You bet. I did 5 times more work in that 3-hour functional programming course using Scheme than I did for my 5 hour german class. Why all this work? To weed out those who do not possess the Talent. After the first midterm, about 1/3-1/2 of the students drop.

By the time a CS student is a senior, they're pretty committed. Then you don't have to think so much about whether they're cheating just to pass the class..its fairly unlikely. While it may seem absurd to require undergrads not collaborate, it is indeed a good thing for us in the future, to prevent the market from being flooded with idiots who dont know their ass from an a-list :)

COG. Build your own community. Free, easy, powerful. Demo site

Define your goals first (3.83 / 6) (#6)
by tftp on Sun Jan 07, 2001 at 01:35:47 AM EST

When you code for someone that someone is interested in the final product, so if the collaborative work has benefits (like time to market, maintainability, more eyes etc.) then more people will be involved.

However there is no such goal in schools! Nobody cares if a group or a class as a whole can write a compiler. Nobody needs that compiler! What they need is to value your skills separately from other lab rats^W^Wstudents. Then the rule "keep test subjects apart" makes sense. Very often stronger individual in the group takes the lead, and past that point nobody can figure out who contributed what. Teachers aren't interested in group results, so they delay collaborative work until you are all more or less on the same level and can work really together, without an inevitable danger of being set aside by someone with just slightly better knowledge.

Hell yeah (1.85 / 7) (#7)
by simmons75 on Sun Jan 07, 2001 at 01:43:38 AM EST

That annoyed the piss out of me when I was a CS student. No group work. Then I switched to journalism due to necessity, and nearly everything was a group effort. By design.
poot!
So there.

I hated groupwork (4.46 / 13) (#8)
by jesterzog on Sun Jan 07, 2001 at 01:56:38 AM EST

Actually I hated groupwork in undergraduate courses.

Computer Science is in many respects something that you either get really well, you don't get at all, or you can do sort of average if you put lots and lots of work in. In most undergraduate courses that I went through, the people who didn't get it at all hadn't properly been weeded out.. although in the first year there was about a 50% dropout rate.

The problems I had with groupwork was that it was very easy to end up with someone who didn't understand anything (yet had somehow survived). It's really frustrating when they submit horrible code that'll never work and it drags everything down. Meanwhile someone else who doesn't get it might be teamed up with a coding genius. I know someone who got an A- in a data communications course (with client-server communication), mostly because of a brilliant project that his partner would hardly let him work on at all.

If someone wasn't putting in their fair share of work, we were always allowed to complain and have the situation assessed. The problem was that usually they were trying very hard - they just didn't fundamentally understand most of what they were doing.

I haven't much experienced other courses, but teamwork in computer science can really drag you back if you end up with people who don't know what they're doing. It's possible to say that it's your own responsibility to team up with others of similar ability, but that's being very unfair on anyone who doesn't know other people in the class very well early on when the teams are created.

Having said all of this, it's really good to get experience working with other people. I don't think undergraduate coursework is the best way to do it, though. Unless, of course, it's a course designed to teach teamwork.


jesterzog Fight the light


I hated groupwork (4.20 / 5) (#22)
by mami on Sun Jan 07, 2001 at 09:21:03 AM EST

I agree. Groupwork in undergraduate studies is nothing more than protecting the student who can't fight it on his own. I even dislike any groupwork in science (chemistry/biology etc), coming from a country were even in these fields groupwork was not promoted much at Universities. I can't remember students not working in groups to exchange ideas and problems, but then you went out on your own to actually implement and do the work.

Someone else here mentioned this:

Remember what a university is there for. A university is not there to teach you per se - it is there to teach you to learn of your own volition. One of the most important learning skills anyone can pick up, is that of working in a team - you learn more off your peers than you do out of any textbook.

I disagree with that with regards to undergraduate studies and most of the graduate class work I have witnessed here in the U.S. This argument is often used as an excuse for teachers and professors to justify a badly prepared lecture or lab (or them being forced to squeeze an unrealistic amount of material in a too short semester resulting in a badly designed course).

A University is there to teach in the first place and test in the second place. If the tests are structured right, students would have to learn of their own volition - otherwise they would fail.

How often I have seen classes were the teaching was nothing more than the preparation of the students to pass the finals. Even more ridiculous is the fact that many classes are full of people, who know already the material inside out (and therefore shouldn't need to take the class) and can barely hide their disgust coming to class, but are forced to take the final to get a "certificate" of some sort.

The disparity of prerequisite knowledge of students is enourmous and professors more often than not are forced to make a decision to adjust to either end of the spectrum. That then leads to either undereducating the bottom part of the student body or handing out certificates which don't mean much to the top part of the student body. Both is not what you want to do. You would want to teach the bottom part more appropriately and challenge the top adaequately not caving in to "easy certification".

Of course you have to learn how to work in a team - AFTER you have learned the skills necessary to work at all in your field - on your own.

And finally I think that the disparity in prerequisite knowledge of the U.S. student body is related to the huge body of foreign students and the fact that U.S. highschools produce very different results from school to school and state to state. I have serious doubts about the wisdom of the SAT tests to level out those differences.

[ Parent ]

I also hated groupwork (4.00 / 1) (#63)
by Bisun on Mon Jan 08, 2001 at 12:09:27 PM EST

Actually, I sort of still do. But it can be quite useful. The reason that I hate it is that it takes me a long time to get to know people, I'm quite shy (well, depending on circumstances), and consequently I have no chance to select who I will work with. I actually preferred the times when our partners were per-selected, despite the fact that it was usually logistically more difficult to do the work.

This said, learning to work together is possibly the most important thing that one can learn in second year and higher computer science. I feel that debugging sessions sometimes nearly require a new point of view. This should be taught during the first year, and reinforced in each succeeding year. Not to say that all of the work should be this way. But, e.g., learning to design an API nearly requires a team (or you could think of it as two teams). Otherwise you have no way to judge how good your work is. And consider all of the code that I have "copied" from Knuth. Well, I had to translate it, but I sure didn't do the algorithm design! So I even have trouble thinking of copying as something bad. Or consider GUI design. How can I know if the design is right? Only be asking someone who will be a user! I frequently end up with a massive redesign (Praise be to GUI builders!) two or three times.

[ Parent ]

As much as I love coding... (none / 0) (#71)
by pb on Mon Jan 08, 2001 at 05:43:55 PM EST

Sometimes it isn't all about the coding.

Usually I find myself writing a lot of code for the projects I'm involved with; I like it, and I'm pretty good at what I do.

Some people don't get thrilled over writing code, but still have other skills. If they can understand the code, they can document it. If they can break the program, or use it according to the specs, they can test it, or help track down bugs. Or maybe they can work on design, or help you talk the problem out and analyze the spec; these skills are sometimes just as important as coding.

But if they can't do any of these things, then you should go to your teacher, and try to cut loose, and give them something they can do, if possible. This is where we get statistics about how a good programmer can be orders of magnitude more productive than an indifferent one...
---
"See what the drooling, ravening, flesh-eating hordes^W^W^W^WKuro5hin.org readers have to say."
-- pwhysall
[ Parent ]
+1 because the standard is annoying... (4.44 / 9) (#9)
by cadfael on Sun Jan 07, 2001 at 02:29:00 AM EST

Sorry, this turned out to be quite long...

I have been on both sides of the desk in my comp sci dept (NOTE: I am a grad student who taught for a few years in undergrad and grad studies). I have been the student told its okay/its not okay to work in groups, and have assigned stuff in both modes. I generally worked it this way: people work together in the real world, and people collaborate in school (whether its allowed or not). I "required" (requested is better) students to work alone on small assignments, but on projects or large scale assignments, I required that either they work alone, or work in teams and let me know who they worked with.

People inevitably tried to work in groups and not give credit (usually one person did something and the other copied it, often word for word). I usually invited them into my office to discuss it. I pointed out to them (as well as my classes) that they would be working with people for the rest of their lives, and they might as well get used to different people being at different levels of ability, and that they should choose carefully who they worked with. After a couple of assignments, the students figured out who the dead weight in the class was, and no one worked with them anymore. And others did learn (as the author pointed out) that there are a large number of ways to attack a problem, and to use each others' strengths.

I caught a great deal of flak for this policy. Not from the faculty or department, and not from the students who were learning the material. I caught the most crap from the students who were looking for others to do the work for them (I know that is a harsh statement, but when someone repeats your class twice and still hasn't learned anything, certain things become obvious).

So, now the students who were in my class knew how to work nominally with others, and learned the material better. They would go on to other classes, and learn from each other. I cannot for the life of me understand the "lone wolf" concept of schools that enforce the no collaboration rule.

Maybe the best example of how collaboration should work comes from a 3rd year class I took. We were required to turn in separate executables with the names of those we collaborated with. We were allowed to discuss strategies, compare code, but had to turn in code that was different from those we worked with. It was the same amount of work for each of us, but we ended up learning three or four solutions to the same problem.

As to real world, anyone who does anything of any significant size in my company usually gets help and ideas from at least four other people. If I tried to go it alone, my boss would probably tell me to work with the team or work somewhere else...

Security
People who get between me and my morning coffee should feel insecure.
IETF RFC on HTCPCP

Back when I was in school (4.00 / 4) (#10)
by djkimmel on Sun Jan 07, 2001 at 02:41:12 AM EST

In school, the basic introductory material was done individually. After that was out of the way everything we did was in teams, except for the tests. But, of course, in the tests there was nothing to stop us from using things we learned off of other people we worked with.

I found that this worked out really good except for the occasional person that would just get pulled along by the teams he was on and never do anything for himself.
-- Dave
Don't take it personally (4.00 / 8) (#11)
by skim123 on Sun Jan 07, 2001 at 02:45:34 AM EST

You (and students like you) are not the reason those rules are in place. If everyone was like you (excited about learning), then they'd beg students to work together. However, there are plenty of students who aren't passionate about programming; there are plenty of students who just want to slide through.

When I was in school I loved group projects if we got to choose our own groups. I could pick those people I liked and knew enjoyed programming and would pull their weight. I hated it when they assigned groups, that always sucked, because, inevitible, I would end up with one or two folks who would literally do nothing... either because they didn't know how to or they wanted to slide through... sadly, I think it was both...

Money is in some respects like fire; it is a very excellent servant but a terrible master.
PT Barnum


re: group work (3.50 / 2) (#14)
by gromgull on Sun Jan 07, 2001 at 04:56:08 AM EST

At my uni. it was argued that, in any real-world scenario, you would end up with a few loosers on your team, and it is a part of the challenge to get the work done, even with less talented team-members.

--
If I had my way I'd have all of you shot

[ Parent ]
True (none / 0) (#48)
by skim123 on Sun Jan 07, 2001 at 08:53:04 PM EST

At my uni. it was argued that, in any real-world scenario, you would end up with a few loosers on your team, and it is a part of the challenge to get the work done, even with less talented team-members

Yes, this is true. But it still sucks. :-) I've only worked for two companies, a consulting firm and Microsoft, and one really nice thing about Microsoft is that everyone there really knows their shit. At the consulting firm it was more like real-life: you had some very talented individuals, a lot of average developers, and a handful of pathetic guys.

Money is in some respects like fire; it is a very excellent servant but a terrible master.
PT Barnum


[ Parent ]
CS at Western Washington University (4.00 / 5) (#12)
by dew_freak on Sun Jan 07, 2001 at 02:46:38 AM EST

I'm a CS major up at WWU. Collaboration on programming projects is encouraged, but there is also a well-defined policy against copying source code. All projects are submitted as source code, both printed and electronically, so finding 'cheaters' is fairly easy.

On a related note, I've been disappointed in the lack of discussion on completed programming projects. A lot of the benefits that collaboration provides, such as alternative solutions, could come in at this point. I've mentioned this on the course evaluation forms whenever it's relevant to the class.

If other CS students have these evaluations, maybe it would help get the point across if we all mention it?



College and "graduating" into Real Life (4.36 / 11) (#13)
by turtleshadow on Sun Jan 07, 2001 at 03:02:26 AM EST

I have great affinity to your subject. +1 FP.
The years I spent studying CS were very difficult due to the seesawing policies on lone development and collaboration. I do believe that the CS curriculum should not stress a strictly lone process. The first year (Freshman in College or H.S. level ) must develop and encourage code review and peer testing. These should be guided class exercises and homework. However I firmly believe once pseudo code and base syntax is covered by the Prof, actual development should be a lone effort until the code is ready for review or turn in.

Students coding are very subjectable to influence of other's styles and techniques. They must develop a firm sense of personal style, understand their own code execution flow, become literate of how basic rules of syntax work, become familiar with figuring out how to find assistance and debug; books, Teacher Assistants, Lab Operators, etc.

Pushing yourself to go it alone till you "fall" is a very tried and true way of learning the basics. I doubt anyone learned to ride a bike with Dad or Mum on the back seat. They were there lending support from the side, not along for the ride.
Entry level coding courses should be like that. As a student progresses to actually utilizing library and other types of calls the collaborative process should be introduced.
This I equate more to learning to drive a car with older sibling in the passenger seat. Such a level much being more complex it can hold more "passengers."

Because the real world involves complex development I actually fault my University for introducing team programming and software engineering techniques much too late -- Junior/Senior year. By this time I was too independent and believed I could go it alone and be better off than participating in a team effort.

When I hit the real world I was sent into a bit of a shock on my first assignment. I learned really quickly the hard way that solid requirement discussions are #1 in terms of a successful project and #2 documenting & validating if the test cases were really what were required so you can actually say the project is complete. Lastly #3 developing the governance of who, how, when, why project changes (PCRs) are introduced into the project and most importantly how to pay for them came with some project management blunders -- er experience that College doesn't teach.

As for me I left College only to re-orient my focus and have applied my CS skills to Large Systems Architecture/Development. I don't work with libraries, I work with departments of people. I don't work with syntax errors I have to debug accidents and human nature. I don't worry about the CPU time used just Real $$ running out. Many say Computer Information Systems (CIS) should have been my degree. I say the CS experience deepened my understanding of my materials and peers and gave me a reality check on what precision of execution really means. As anyone who has done batch processing for a graded CS project learns to know -- "Get it right the first time, try number two is expensively late."

Of those I have kept in contact from school, those that I saw in the lab Freshman year till graduation that constantly shared code sections, "copied" data results, always worked in teams and shared a collective brain have not fared as well in life as those who worked hard on their own; internalized the lectures and the discipline, knew of their strengths and weaknesses and collaborated effectively when the going got tough.
I am not saying this is a hard and fast rule. But frankly the majority of those I know those that relied on shared brain power exited school with half a brain, great human manipulation skills and little insight into CS.


Regards,
Turtleshadow


A middleground (3.42 / 7) (#15)
by sams on Sun Jan 07, 2001 at 05:56:24 AM EST

Where I am, the rule is you can't share code or pseudocode. Sharing ideas is fine, but the C or SML or whatever must be entirely your own.

This means that you can work with friends to figure out in your head what needs doing, but you have to really understand it to write the code yourself.

If you can't code, you shouldn't be a programmer (2.62 / 8) (#17)
by Carnage4Life on Sun Jan 07, 2001 at 07:02:00 AM EST

In any other academic field, this would seem to be a cut-and-dried question. We're talking about plagiarism, aren't we? Who could justify that? My first answer to that would be to compare programming projects to the labs that are done in the sciences: you always want to be working with a lab partner in chemistry or biology. Or do the sciences suffer from plagiarists graduating and going to work without having done their own work? Why isn't copying lab work a problem in these fields?

Unless you are talking about first-year programming assignments then your analogy holds no water. Programming assignments at the sophomore/junior/senior level are aimed at testing a student's understanding of concepts and ideas more so than written tests can show. Telling students that it is OK to copy each other's code for projects that are aimed at teaching and testing concepts as well as testing a student's understanding is akin to telling students in a Math class that all homework is collaborative.

The problems with having collaborative homeworks early on are many.
  • More of the student's grade will have to come from tests and in class projects instead of from programming projects. This of course means that the classes would have to be geared less towards the practice of programming that students are supposed to learn early.

  • Programming involves a lot of blood, sweat and tears in front of the computer. One of the biggest problems with programmers is that they quit too easily and seek help from other programmers instead of spending time tackling problems from all angles. Self-sufficiency, problem solving and where & how to find answers quickly (man pages, info pages, MSDN, books, USENET, etc) should be taught to the students as early as possible instead of creating another group of programmers who are always quick to give up and ask the resident guru.

  • Most good programmers despise group projects in school because there is always at least one person on the team who cannot pull his own weight and gets carried by the rest of the group. In higher level classes the assumption is made that anyone who makes it to being a Somputer Science junior/senior can pull his own weight (unfortunately this isn't true) but to allow openings for slacking off in the early part of the curriculum can only be detrimental to all the parties involved.

I do agree that there should be collaboration between students with regards to programming assignments of significant size. Note that collaboration does not mean copying significant amounts of code but instead means figuring out algorithms, creating test cases, and hunting for bugs together. It is silly to ask students not to work together when it comes to figuring out how to solve a problem but it is just as much folly to say that students should be allowed to copy each other's code.

If you can't code, you shouldn't be a programmer (3.55 / 9) (#18)
by Carnage4Life on Sun Jan 07, 2001 at 07:02:05 AM EST

In any other academic field, this would seem to be a cut-and-dried question. We're talking about plagiarism, aren't we? Who could justify that? My first answer to that would be to compare programming projects to the labs that are done in the sciences: you always want to be working with a lab partner in chemistry or biology. Or do the sciences suffer from plagiarists graduating and going to work without having done their own work? Why isn't copying lab work a problem in these fields?

Unless you are talking about first-year programming assignments then your analogy holds no water. Programming assignments at the sophomore/junior/senior level are aimed at testing a student's understanding of concepts and ideas more so than written tests can show. Telling students that it is OK to copy each other's code for projects that are aimed at teaching and testing concepts as well as testing a student's understanding is akin to telling students in a Math class that all homework is collaborative.

The problems with having collaborative homeworks early on are many.
  • More of the student's grade will have to come from tests and in class projects instead of from programming projects. This of course means that the classes would have to be geared less towards the practice of programming that students are supposed to learn early.

  • Programming involves a lot of blood, sweat and tears in front of the computer. One of the biggest problems with programmers is that they quit too easily and seek help from other programmers instead of spending time tackling problems from all angles. Self-sufficiency, problem solving and where & how to find answers quickly (man pages, info pages, MSDN, books, USENET, etc) should be taught to the students as early as possible instead of creating another group of programmers who are always quick to give up and ask the resident guru.

  • Most good programmers despise group projects in school because there is always at least one person on the team who cannot pull his own weight and gets carried by the rest of the group. In higher level classes the assumption is made that anyone who makes it to being a Somputer Science junior/senior can pull his own weight (unfortunately this isn't true) but to allow openings for slacking off in the early part of the curriculum can only be detrimental to all the parties involved.

I do agree that there should be collaboration between students with regards to programming assignments of significant size. Note that collaboration does not mean copying significant amounts of code but instead means figuring out algorithms, creating test cases, and hunting for bugs together. It is silly to ask students not to work together when it comes to figuring out how to solve a problem but it is just as much folly to say that students should be allowed to copy each other's code.

moderation note (none / 0) (#56)
by codemonkey_uk on Mon Jan 08, 2001 at 07:34:17 AM EST

The above comment is a duplicate of this earlier comment.
---
Thad
"The most savage controversies are those about matters as to which there is no good evidence either way." - Bertrand Russell
[ Parent ]
Collaboration doesn't work between beginners! (4.28 / 7) (#19)
by Majamba on Sun Jan 07, 2001 at 09:03:28 AM EST

Try they following: Grab the first person you find and try to learn German with him. You will fail for sure.

Probably if you have a teacher giving you exercises you could try it. But you would still have two problems. First there isn't much your partner could help you. Second you realy have to understand what you are doing. You can easily copy your partners homework, but it won't help you much in understanding German grammar.

Especially in CS the important thing is to understand a problem. You can ask for help if you don't know how to use pointers in C. But you must be able to recognice that a certain problem should be solved using pointers.

That's quite different from lab in chemistry. Where you have standard procedures to follow. Which easily can be done together.

In my first year in CS we wheren't allowed to do group work. I still tried to help a couple of colleges. At the end I wrote large portions of there programs. One even had the nerve to present my program as his own (I gave it to him as an example). None of them passed there first CS exam.

What's realy missing at most Universities is a good mentoring program. Learning programing isn't easy. Especially if you didn't do programing before starting CS. Having an experienced programer to ask for help would make the live of undergrade students much easier.


I really wouldn't try foriegn language analogy. (5.00 / 1) (#30)
by elenchos on Sun Jan 07, 2001 at 12:46:11 PM EST

Spending time practicing the language with a partner (if you can't corral a native speaker) is exactly what you should be doing if you are trying to learn another natural language. Programming is different, because the syntax and grammar are laughably simple compared to a natural language, and spontaneous speaking ability doesn't mean anything in programming. Many other skills, like creating algorithms and finding errors are what make programming difficult, and of course the aforementioned need to write code that fits into the larger project well; a critical issue.

You could man-handle the natural language analogy around a bit and force it to look like a good parallel to programming, but why bother? Better to look directly at the question of whether we become good programmers better by working alone or by working together. As far as that goes, you make some good points.

Adequacy.org
[ Parent ]

Excellent point, allow me to expand upon that (3.00 / 1) (#35)
by NoNeckJoe on Sun Jan 07, 2001 at 02:17:56 PM EST

I've said before that one failing of a college degree is that many very important things are taught, but no justification is given for teaching them. When an expert (i.e. your professor, or less so your graduate T.A.) has been immersed in a field for a long time, they forget that the ideas that are simple to them sometimes come hard for their students. The students suffer because of this, but that doesn't mean that the suffering doesn't promote growth.

Consider that in introductory CS courses, there is a huge learning curve. There are many formal languages, abstract ideas, and styles that need to be learned. At this stage, the best training is to work lots of problems, by yourself. This is a universal throughout the sciences (mathematics, chemistry, physics). The only way to learn something is to get your hands dirty and do it.

Constrast the first two years of a CS education with the second two years. In my experience, classes became smaller, and projects focused around group work. Why was it this way? The more advanced students were well versed in elementary languages and programming techniques. Less time was spent with students explaining basic concepts to each other, and more was spent on exchanging ideas and building interesting projects.

Yes, in some fashion the first two years of a CS education is a hazing ritual, but one that truly does build character. It introduces you to the ideas, the ritual, and the methodology of the programming culture. You will find hazing within any large group of professionals. Sit in on some mathematics, or physics seminars to see just how hard scientists can be on each other. Once, at a job interview for a new faculty member, I watched the speaker heckled off the stage by his peers; by educated adults. If you think your undergraduate degree is hard, wait until you become a graduate student. Some of those kids go to hell and back to get their degrees (I know, I was one of them). In the end, almost all of them say it was worth it.

No Neck Joe!

[ Parent ]

Business works in teams! (3.60 / 5) (#20)
by redelm on Sun Jan 07, 2001 at 09:10:20 AM EST

While not wanting to get into the whole acedemic/vocational learning debate, isn't one of the main destinations for CS graduates business enterprises where they invariably code in large teams?

One of the main criticisms of bosses is that CS graduates don't work well in teams. So why not give students some practice in teamwork at school? More bizarre, why prohibit collaboration?

In every team, some members end up doing a disproportionate amount of work. Others mooch. Success in buesiness can work around mooching _or_ the shedding of moochers. Why deprive students of these necessary experiences?

CS students takes tests and exams to make sure their individual skills are acceptable. They often do group projects to make sure they can work with others. Different students find one or the other highly objectionable.

Go Team Go (3.75 / 4) (#21)
by zal on Sun Jan 07, 2001 at 09:20:55 AM EST

Around here, University of Dortmund, Germany we are encourage to work in small teams of approx 3 people from day one. This is not only for the practical programminf assignments, but even for the assiggnments in the theoretical classes. The workload of the assignments reflects this, so sooner or klater you basically are forced to team up, because else you will have to work day and night to complete your assignments. I always thought this a very good idea, as students can help each other understanding the coursework while solving the problems. If someonme uses this to just tag along he wil fail in the exams, so i dont really see a problem with that.

Many will say this won't work. (4.00 / 1) (#33)
by elenchos on Sun Jan 07, 2001 at 01:07:03 PM EST

I tried to find a survey or study comparing the success of different methods, but didn't get far.

Do you have any data on how successful your university is in this approach?

Adequacy.org
[ Parent ]

Seems a little strict to me (3.75 / 4) (#24)
by barzok on Sun Jan 07, 2001 at 09:57:45 AM EST

I went to Clarkson University, and we were encouraged to work together if we wanted to in most classes, not just CS. Each person is still responsible for submitting their own work, and while I never saw someone get caught, the professors were probably able to tell when someone turned in something that they didn't do most of the work on. The 1-4 exams per semester would usually point out to the profs. real quick who knew their stuff and who didn't.

I learned far more from working with my fellow students than I did from the books and lectures.

This actually worked better than the "team" projects we were assigned to work on in groups, because you knew you couldn't rely on someone else picking up your slack.

Since we're talking about the "real world" here as well, I've worked on projects both alone and with a small team (2-4 programmers). "Gang-coding" doesn't happen and doesn't work (one person typing, 3 people talking). It's mostly about having another brain to pick when you get stuck, or saying "I don't want to deal with this pice, can you do it?" and most importantly, peer review.

group work is okay, sometimes (2.83 / 6) (#25)
by prwood on Sun Jan 07, 2001 at 10:15:31 AM EST

I am a senior computer science major at a small liberal arts college near Boston, MA. From our first introduction to CS class, we were in fact assigned to work in groups of two or three. Ideas for writing code were to flow freely between the students in groups.

This had some good points. For one, there is always the synergy that comes from working in groups (i.e. the adage 'If you have an apple and I have an apple, and we exchange apples, then we each still have one apple. But if you have an idea, and I have an idea, and we exchange ideas, then we each have two ideas.).

On the downside, however, if one student in the pair was very weak, and the other was very strong, the weak student would generally leech off the strong one. This really doesn't help anyone. I have worked in several groups where my partner has done almost no work, and I have ended up carrying most of the load. This isn't good.

In another situation, though, it's not great for groups of weak people to be together. There was one group of really clueless guys in my intro class. They were so bad, and had nary a idea as to how to complete the project, that they skulked around the computer room, looking for trashed printouts from other groups, and ended up plagiarizing a large part of another group's program. Most of these guys ended up getting kicked out.

In the end, though, after the first year, most of the totally clueless people have been weeded out of the program. Also, by that time, everyone is aware of his or her level of competence, and will choose a partner who is at roughly the same skill level as they are.

Another problem which I haven't mentioned is that although some students in groups may be exceptionally bright, they may also be very reserved or shy, and may not feel that their suggestions have any merit when working in a group. These students should be spotted by the professor early on and encouraged to speak up and share their ideas, lest they develop an attitude of complacency.

I am currently working on my final project as a requirement for graduation, and I am working with one other team member. We are roughly on the same level intellectually, so there is no problem with leeching on this project. I guess this is the most important point: if you are going to work in teams, make sure that everyone in the team is on roughly the same level of comprehension.

group work is okay, sometimes (4.42 / 7) (#26)
by prwood on Sun Jan 07, 2001 at 10:17:13 AM EST

I am a senior computer science major at a small liberal arts college near Boston, MA. From our first introduction to CS class, we were in fact assigned to work in groups of two or three. Ideas for writing code were to flow freely between the students in groups.

This had some good points. For one, there is always the synergy that comes from working in groups (i.e. the adage 'If you have an apple and I have an apple, and we exchange apples, then we each still have one apple. But if you have an idea, and I have an idea, and we exchange ideas, then we each have two ideas.).

On the downside, however, if one student in the pair was very weak, and the other was very strong, the weak student would generally leech off the strong one. This really doesn't help anyone. I have worked in several groups where my partner has done almost no work, and I have ended up carrying most of the load. This isn't good.

In another situation, though, it's not great for groups of weak people to be together. There was one group of really clueless guys in my intro class. They were so bad, and had nary a idea as to how to complete the project, that they skulked around the computer room, looking for trashed printouts from other groups, and ended up plagiarizing a large part of another group's program. Most of these guys ended up getting kicked out.

In the end, though, after the first year, most of the totally clueless people have been weeded out of the program. Also, by that time, everyone is aware of his or her level of competence, and will choose a partner who is at roughly the same skill level as they are.

Another problem which I haven't mentioned is that although some students in groups may be exceptionally bright, they may also be very reserved or shy, and may not feel that their suggestions have any merit when working in a group. These students should be spotted by the professor early on and encouraged to speak up and share their ideas, lest they develop an attitude of complacency.

I am currently working on my final project as a requirement for graduation, and I am working with one other team member. We are roughly on the same level intellectually, so there is no problem with leeching on this project. I guess this is the most important point: if you are going to work in teams, make sure that everyone in the team is on roughly the same level of comprehension.

comments, etc (3.66 / 3) (#27)
by cryon on Sun Jan 07, 2001 at 12:05:54 PM EST

Yes, in my school they also prohibit teamwork on programming assignments. Many and perhaps most of the students are not particularly good at coding, and do not enjoy it. They got into CS because they were good at math as kids. I am apparently among the few in my classes who actually turn in working programs. Perhaps 10-20% do turn in programs that basically work, and a good number of the rest turn in programs that work only in a certain narrow range, and are what you might call extremely fragile and non-robust.

For the final program in my OS class (UNIX system calls programming assignment), I was apparently the only student among 20 or so to turn in a working program. For the final assignment in advanced data structures only 3 of the 20 or so students bothered to turn in a program at all.

I have some evidence that a few students may follow behind me and some few other codeheads in the CS labs and look for copies of our programs on the hard drive.

As for your comment about the divide between coding and Pure Computer Science, I think you are just regurgitating the standard company line for CS, that coding itself involves less refined skills or thinking in some way, as compared to algorithm design.

It's all very self-serving of course. The fact is that math analysis of programs is necessary but in no way sufficient to good software. And that ivory stuff is really a small part of the work done in the software field. Most of the work is just grind-it-out logic-work on program logic, etc. It requires basic smarts and more importantly a certain patient and curious temperament, and yes, some feel for algoritmic math. But I feel that designing and coding a program is very much like writing an essay--same skills are involved: logical and organizational....

But above that a career in the software field seems to require a voracious need for knowledge and topnotch reading skills and personal initiative & drive. The acquisition of knowledge relating to the operation of large software systems, e.g., Java, Unix, etc., and software design concepts, e.g., OOP, patterns, etc. This is really important stuff, and not all that big in CS departments, generally. This all goes to knowledge acquisition through reading skills, and that is not really what most CS curricula is about, is it? They are about mathematical analysis.

Why does it matter that code is copied? The code is the end product of all that work. It also shows that the student possesses the needed temperament, etc. The employer sees the CS degree as proof that the grad meets these requirements.

As for your comments on how much working with other students helped your understanding, I completely agree! I have had the same experiences. What I would like to see is a class discussion AFTER the programs are turned in. But that would not leave enough time to get through the material. I sometimes get together with other students to look at each other's programs after the turn-in deadline. In fact, I sometimes have a driving NEED to talk about my programs with others who have worked on the same problem.

Now let's see....how can I work in a troll about media-establishment conspiracies.....?


HTGS75OBEY21IRTYG54564ACCEPT64AUTHORITY41V KKJWQKHD23CONSUME78GJHGYTMNQYRTY74SLEEP38H TYTR32CONFORM12GNIYIPWG64VOTER4APATHY42JLQ TYFGB64MONEY3IS4YOUR7GOD62MGTSB21CONFORM34 SDF53MARRY6AND2REPRODUCE534TYWHJZKJ34OBEY6

Team projects vs. collaboration (4.00 / 3) (#29)
by fossilcode on Sun Jan 07, 2001 at 12:21:34 PM EST

We weren't given group projects except in certain classes, and then only at appropriate points in the semester. Our profs were pretty anal about copying code and cheating, but they also understood the value of group discussion and shared ideas. Our computer lab was a bazaar, with advanced students helping beginners, beginners helping other beginners, and high school students helping college seniors get through a mandatory computing class so they could get that accounting degree. We even had an advanced student working a "programmer's help desk."

Wholesale cheating wasn't all that easy though. Our academic machine was a System 370 where students were required to submit programs for compilation on card decks which they keyed themselves, and wait 1-6 hours for the printed results. It was impossible to cut/paste code from somebody else, and if you dup'd the cards of another student's program, the prof would detect it in an instant.

That doesn't mean that some marginal students didn't get through the program. We had one young lady who was mostly clueless, but managed to enlist the aid of a couple of the more technically capable (and socially unaware) male students to help her on project after project. When the rest of us went on to programming and management jobs at places like IBM, large banks or manufacturers, she ended up as a computer operator, where she struggled even with that.

I think a blanket policy isn't correct, but I think that tight controls make for better students. Shared ideas in this business are important. I'm still learning new ways of solving old problems even after 20 years. I know though, that being forced to struggle through many of my early college assignments alone honed my problem solving skills so that I could be a successful contributor in group settings.


--
"...half the world blows and half the world sucks." Uh, which half were you again?
Why bother check for cheaters? I will tell you why (4.00 / 6) (#31)
by TigerBaer on Sun Jan 07, 2001 at 12:52:59 PM EST

As a third year CS student at RIT, I know plenty about the rigid tests the professors use to check the code of the students. But, in fact, most professors here do not mind students aiding each other to some degree, they see it as unavoidable (which it is).

The difference arises when students copy ENTIRE programs from professors, and just change variable names, or change a couple whiles to fors... this is unfair and foolish. The RIT faculty rigidly checks for this. But Why?

The only person truly loosing in this scenario is the cheater, right? Wrong! More people graduating without solid knowledge of the application of theoretical knowledge (programming , not discrete math & lang theory) ruins the school's reputation ruining YOUR degree's reputation. I pay more money than i would like to earn a decent degree, so anything that could potentially ruin my degree I avoid.

I do help all my friends on their code, and anyone who asks, with trouble figuring out how to solve an algorithm, or some strange coding problem (pointer tangles!) but when they start asking for me to write them shit, or design their program, in other words, make something self-sustaininng, this is where i hold back. I refuse to weaken my degree by aiding them. I will help them as much as i can, then refer them to the professor. I pity those who code for others, its a sorry situation. Anyway.. my 2cents... Danke Vielmal

Millersville University (3.00 / 4) (#32)
by Fizz at Beyond on Sun Jan 07, 2001 at 12:57:44 PM EST

At My school (Millersville University, in PA) in most of the classes, we are allowed to work together in most of the classes, starting at about second year, the first year though the students help each other too, but no one says anything, as long as it's not like for line, variable for variable identical.

this happened to me (3.60 / 5) (#34)
by yavor on Sun Jan 07, 2001 at 01:37:17 PM EST

A few months ago I and a friend of mine were accused of cheating and exam. And just imagine - because some our variable names were the same! These names weren't something special - they were single character named like i, j, and p. We had to writ some simple short Pascal program - just about 30-40 lines of code. We hadn't cheated - I just had explained him some algorithm - it was very short and did some search in a matrix. When I explained the algorithm I wrote something like
for i := 1 to n do
for j := 1 to n do
{ other stuff } And we wrote a nested iteration using the same variable names i and j. The teacher thought that was suspicious! It is logical that two students may use a variable named "n" what the description of the problem says:
you have a matrix N x N elements too.
We were not punished, because there were no other evidence against us. But I had to explain why we had used the same names.


Watch your language! (none / 0) (#69)
by Kinthelt on Mon Jan 08, 2001 at 05:08:54 PM EST

We had to writ some simple short Pascal program
...
for i := 1 to n do for j := 1 to n do { other stuff }

I hope that didn't compile! :)

[ Parent ]

Thanks jrh! (3.66 / 3) (#36)
by elenchos on Sun Jan 07, 2001 at 02:52:23 PM EST

Hopefully the fact that I pointed to your material was taken as a compliment. I realize that my one-sentence summary is an oversimplification of what you posted, but my assumtion is that anyone whose opinion matters will have taken the time to read your words in their entirity, and that if you were misrepresented by me you will feel free take me to task for it.

My plan was to post this as an editorial acknowledgement right after I submitted the story, but by then it was late and the Guinness was already starting to take effect, so it slipped my mind. My fault.

Adequacy.org

no problem (3.00 / 1) (#42)
by jrh on Sun Jan 07, 2001 at 05:40:25 PM EST

Sure, glad you found my post of use. Great story idea, btw.

[ Parent ]
Plagiarism? (4.20 / 5) (#37)
by Logan on Sun Jan 07, 2001 at 02:52:59 PM EST

What I don't get is that, in any other subject, one can copy from other sources to one's content, as long as one cites references. I remember one teacher in high school not even allowing students to make any original statements at all (then again, this was high school, where bad teachers flock). I think allowing students to build off the work of others is a good idea. There is much more to programming than being able to implement a linked list on one's own. True, some people are good at that. Others are good at piecing together already developed modules into something that is more than the sum of its parts. Or occasionally one chooses to utilize some small piece of code that performs some useful utility (like getopt). Really, we're all guilty of using other people's code, whenever we make reference to a function from the standard library. Yet I doubt anyone has ever gotten into serious trouble for doing that. I'm sure most of you can (and have) written your own version of strtok, but why should you have to?

It would make more sense to allow any student to use the work of others to his or her heart's content, as long as he or she has the author's permission and documents its source -- just like in any other area of writing. Determining whether the student understands the concepts he or she is being graded on would be a judgment call on the part of the grader, rather than meeting the requirements of some formulaic checksheet, as is usually the case. In some cases one could put together a stupendous program, and have it be 75% someone else's code. Making someone else's code work is a very important skill, and is usually much more difficult than it seems. It should be honored as such, not branded as cheating.

Furthermore, I highly doubt that any reasonable portion of cheating is detected or averted by the school's threats and actions (that is certainly the case in my school). I'd be interested to know how many false positives occur. Really, the school's interests would best be served by teaching, as well as recognizing diverse forms of talent, rather than treating us all like criminals and imposing a form of conformity. But it has been my experience that many professors and instructors simply have the wrong idea. We have instructors here at my school that teach freshman level programming classes and simply revel in the number of supposed cheaters they catch (they brag about branding upwards of 30% of their classes as cheaters). It's sickening.

Logan

Legitmate projects will not match (3.85 / 7) (#38)
by PacketMaster on Sun Jan 07, 2001 at 02:53:07 PM EST

As a recent graduate (May) of a computer program, I can tell you that unless you're dealing with a very simple program, no two program's code will look identical. Very few programs can be written and "Accidentally" look idential. I had 4 classes in C/C++ and my code never remotely looked like other student's. We were allowed to discuss problems amongst ourselves but it was clear that copy and paste was a no-no. In four years, there was only one case of "cheating" accused. I was good friends with some of the professors at my school and managed to get a glance at the code and it was obviously a case of copying. Any competent professor can tell when code has been copied and when it has not. It's obviously not as cut and dry as english papers, but you can usually tell.

re: Legitmate projects will not match (none / 0) (#61)
by Bisun on Mon Jan 08, 2001 at 11:45:22 AM EST

This sort of depends on what is considered a "match". I do agree that if a reasonable criterion is used, that this will be correct. I differ in assuming that one can count on those with the power will choose a reasonable criterion. And if they have already decided that you are "guilty", then your protests are likely to fall on deaf ears. OTOH, assigning a new project in case of doubts doesn't usually sound like hardship. Also: Consider the process by which the multiplication tables are learned. "Cheating", when done properly, is no bar to learning. Of course cut and paste would not teach a measureable amount, and if a poor solution is copied without editorial corrections, it indicates that little to nothing has been learned. But it is also true that if the chastisement is so severe that free discussion is inhibited, then learning is similarly inhibited. And similarity of variable names is a rediculous criterion. It is a check on whether or not students have been working together (good), not a check on whether they have collaborated (also good, but dicey), and certainly not a check on whether code has just been copied (anybody sensible who did that would at minimum change the variable names).

[ Parent ]
my $0.02 (4.16 / 6) (#39)
by bradenmcg on Sun Jan 07, 2001 at 03:05:48 PM EST

i have had an experience related to "group work" and "cheating."

freshman year, intro C++ course (The first programming course we are offered - that's another rant entirely). a friend of mine is working on her code. mine is totally done - written and compiled already. i had finished it a couple hours previous. she comes down from her floor and asks me how to work through a certain part. without turning away from my game of Quake 3, i start blabbing the basic algorithm to her. she still doesn't get it, so i pause the game and turn around and sketch out a skeleton of the algorithm. it just so happens that the random single letter variables i used were the same ones i had actually used in my code. she then continued on to use those same letters in one section of her code.

i get an unhappy email the next day telling me that cheating is evil and that i need to come talk to the dean of CS and defend myself or some shit. the asshole ends up assigning me (and my friend) to do an EXTRA assignment to take the place of the one we "cheated" on.

that incedent made me fear ANY contact with a fellow student. my next programming course, "intro to data structures," was a hell class. (mostly because the prof sucked, but that's another rant too) i was deathly afraid to ask any of my peers for help with anything or to bounce any ideas anywhere - i didn't want to be caught "cheating" again.

i dropped the class about halfway through the semester and changed my major around the end. now i'm Management/MIS.

thank you, CWRU!! </thicksarcasm>

<leonphelps>Yeah, now, uh, "sig," what is that?</leonphelps>

Take this tongue in cheek, but... (5.00 / 2) (#47)
by Speare on Sun Jan 07, 2001 at 08:17:38 PM EST

i was deathly afraid to ask any of my peers for help with anything or to bounce any ideas anywhere... now i'm Management.

Some people would say this transition is inevitable. :)


[ e d @ h a l l e y . c c ]
[ Parent ]
lol... ^_^ (none / 0) (#52)
by bradenmcg on Mon Jan 08, 2001 at 01:43:17 AM EST

yeah, i got a chuckle out of it, because i know what the "typical" manager can be. (pointy-haired boss... *shudder*)

i'm doing it because i need to major in *something* and i don't really care about coding all that much. my true passion is networks and servers and such. IS/IT kind of job. thus, the MIS concentration.

still a good poke though. ;-)

<leonphelps>Yeah, now, uh, "sig," what is that?</leonphelps>
[ Parent ]

A fun story... (4.60 / 5) (#40)
by joto on Sun Jan 07, 2001 at 05:09:47 PM EST

At the university where I study, our grades are not based on anything we do during the term (except for a few courses where project work does count).

My feeling is that that is a fairly ok situation. We have a few projects that needs to be delivered during the term in order to take the exam, and some people cheat, but there are so many people taking the courses, that we couldn't possibly check all the assignments for cheating. Anyway, by cheating, you really only hurt yourself, because if you can't even do those assignments by yourself, you stand very litle chance of actually making the exam. It is also reasonably fair, to grade only on the exam as it is much harder to cheat on the written exam. (And no, we don't do multiple choice exams, it is five hours written exams writing code with paper and pencil).

I do remember (about a year ago, working as student assistant) that we discovered some people cheating. It was only through random chance that we discovered it at all. All the student assistants and the professor had a weekly meeting where we discussed the following weeks assignments and so on. If some f use came early, we often spent the time joking about the worst assignments we had gotten, or something like that. One of the student assistants jokingly told of a really horrible solution he had gotten in this week from two of his students. (And trust me, it was really, really bad!) One of the other student assistants realized she had seen a very similar assignment, equally bad, in with the exact same misunderstandings! We checked more closely, the two solutions actually used the exact same stupid (and not working) "algorithm". After some investigation, it turned out that one of the teams had fished out a random solution from the boxes where the assignments were to be delivered, and used it as basis for their own solution. This would have been very difficult to catch, had the solution been ok, but due to their incredible stupidity, these two students had chosen to copy the single worst solution of about 200 other students and gone with it

After talking to the students of the cheating team, the professor gave them an extra assignment. She told us that she actually had a little bit of a problem being strict towards them, because the whole situation was so humorous. None of them made it of course.

After this "incident" we talked a little bit about how we could discover cheating more efficiently by using a database of some sort and look for near matches, but it would probably have been far too much work to be worth the trouble.

Anyway, I guess we can conclude this: Not all CS-departments are ruled by fascists using every means to discover cheating. Secondly, if the two "offenders" had chosen a solution that actually worked to copy, they would even stand the chance of actually learning something, which is the point of having the assignments in the first place. So I guess having a relaxed view on "cheating" is probably the best. That said, I wouldn't mind if some stricter action were taken once cheating was discovered. Cheating is not neccesarily so bad, but bad cheating should definitely be punished!

Student graders? (3.00 / 1) (#43)
by Uller on Sun Jan 07, 2001 at 06:44:28 PM EST

What about situations of student graders? I'm a junior undergrad and have graded the freshman and sophomore CS classes for three semesters now, and have come across similar situations. However, these early classes teach basic concepts of Java and C/C++ and are structured around smaller weekly or bi-weekly assignments.

Again, they tended to pick the worst solution on earth to copy too... the most notable example was a simple exercise in the Java GUI api, to draw a checkerboard pattern beneath a red and black dartboard. Two students turned in the same routine with identical formatting and two changed variable names, that took 15 seconds to draw the checkerboard (500x500, 50x50 squares) on a 1GHz box. They'd probably do well at Microsoft.

Still, it was a simple assignment, so I just gave them the expected nasty grade and let it by. I'm too benevolent of a grader :-P

- Ryan "Uller" Myers

Given an infinite amount of time, an infinite number of monkeys with typewriters must eventually produce the collected written works of Shakespeare. John Romero's Daikatana was a five minute, ten monkey job.
[ Parent ]
Encouraged, even Enforced (4.33 / 3) (#41)
by Osiris on Sun Jan 07, 2001 at 05:14:29 PM EST

At ohio state, there is a three course intro sequence. The first two are individual work, the third requires you to work with a partner (even though I would have preferred to work alone). A few classes down the line is a group project course for teams of 4 or 5, and if you don't have a good team, you will fail, the workload is enormous.

In non group-work classes, you are still encouraged to work on homeworks with classmates. Algorithmic discussion is legal, and syntax type help is fine, too. Where they draw the line is actual copying of code, and I see no problem with this. I was a grader for a couple of quarters, and didn't look too hard for cheating, but sometimes it just jumps out and kicks you (like when two student's labs both dump core on the exact same test case, you check the code and it is identical down to the misspelled comment! Come on, if you want to cheat, at least be smart.)

This is all from a program which includes both engineering, and arts & sciences type people. Maybe the team aspect from other engineering disciplines has bled over, I don't know.



`Excessive Collaboration' (4.40 / 5) (#44)
by HoserHead on Sun Jan 07, 2001 at 06:54:17 PM EST

"Excessive Collaboration" is a Capital Offense at my school, the University of Waterloo. If you're found to have collaborated excessively, you will be assigned a mark of -100% on the assignment, with a minimum of 5% deducted from the final mark, and you'll be reported to the associate dean of computer science as well.

At the same time, however, our CS department prides itself on the group work integrated into the course, as that's what's done in the Real World.

The really scary part is that they (apparently) have pattern-matching software which scans all code submission (done electronically); if you're found to have the same type of structures, setup, layout, etc (regardless of variable names and other things) then it'll get flagged. Apparently it's a rare occurrence that anyone gets pulled in for cheating when they haven't, but even so; distrust!

Pattern-matching software does exist (4.00 / 2) (#45)
by goonie on Sun Jan 07, 2001 at 07:32:57 PM EST

As a former CS tutor (TA), I've used this software myself, and it works very well. I had absolutely no compunction about using it, or the punishments (usually, a 0 for that assignment, a record kept, and second offences led to disqualification from taking any more classes from the CS department)

Group work is an essential part of the CS curriculum, but group work for assessment is a massive PITA for both students and tutors and to make *everything* collaborative projects would mean that the curriculum would cover far less material, as students simply wouldn't have time to do it. Taking the same exercises as were used for individual work and simply allowing colloration would lead to 20% of the class doing the work for the assignments, and the other 80% sponging off the intelligent and enthusiastic ones. No thanks.

[ Parent ]

Old Ma Tech (3.00 / 2) (#55)
by electricbarbarella on Mon Jan 08, 2001 at 06:37:39 AM EST

The Georgia Tech CS department does the same thing, so they say, but no one can think of any time when anyone has been called on it, and there's not a TA who knows WHO uses this software, if it exists.

They call it the cheat finder. We think of it as an undead army of the night loaded down with atmospheric railguns (yes, I said that on purpose) and particle weaponry. Sure, it's possible, but we have our doubts.



-Andy Martin, Home of the Whopper.
Not everything is quantifiable.
[ Parent ]
woohoo! Ma Shaft rules again! (none / 0) (#70)
by djx on Mon Jan 08, 2001 at 05:18:07 PM EST

I was nailed by cheatfinder. Although I did not cheat on the assignment. Basically, the way the thing works at ma Tech is this: it's a diff. But there's an added touch: it can diff binary formats like Excel / Access / whatever as well. One of the things it looks for in the M$ files is the 'name' of the last person to save the file. Of course this comes from the computer it was saved on, not from the person on the keyboard. Naturally, I let one of my pledge brothers use my computer for his assignment (What can I say, I'm good to the Phi Kaps.) and when his got run through cheatfinder, it picked up the same 'name' for the 'last modified by' crap that Excel adds to its files, and we both almost failed the class and got kicked out of the CoC for it. Fortunately, the prof was cool to us. Oh, and by the way Kurt Eislet is a prick, but he's not the dean of the CoC anymore (from what I've been told). This was back in Winter Quarter 97, so I have no idea if their bullshit has changed much since then.

Good luck at Ma Shaft, and drop by the Phi Kap house, while you're at it. =]

-<end of transmission>-
NO CARRIER.
[ Parent ]
Re: `Excessive Collaboration' (3.00 / 1) (#59)
by jfpoole on Mon Jan 08, 2001 at 11:04:00 AM EST

"Excessive Collaboration" is a Capital Offense at my school, the University of Waterloo. If you're found to have collaborated excessively, you will be assigned a mark of -100% on the assignment, with a minimum of 5% deducted from the final mark, and you'll be reported to the associate dean of computer science as well.

At the same time, however, our CS department prides itself on the group work integrated into the course, as that's what's done in the Real World.

I've just recently completed a degree at UWaterloo (CS/C&O if anyone cares), and groupwork does become more important in the upper level CS courses. Heck, there are some courses (such as operating systems, real time, and compilers) where you'd be daft not to work in groups. Plus, in other fourth-year CS courses such as graphics, most students do end up collaborating to some degree on the various assignments (not to the point where one is copying large segments of code off the other, of course), even though the assignments are submitted individually.

I think the rationale behind this is that if you've made it to fourth year and are taking some of the harder courses, you're clearly there because you want to be there and you've got the aptitude to be there as well. However, in the lower level CS courses you still need to prove that you've got some ability, hence the fairly strict rules against collaboration.

Oh, I've a friend who's just come off a work term as a CS TA -- the pattern-matching software does exist (I think it comes out of one of the schools in California or Georgia), and is used fairly actively for the first year CS courses. I've no idea how accurate it is, though.

As always, my 2 cents,
-j

[ Parent ]

Accurate enough (none / 0) (#74)
by goonie on Tue Jan 09, 2001 at 03:56:03 AM EST

While I'm sure it's possible to fool it (and anybody with who has taken a compiler course can probably figure out approximately how it works), if you're clever enough to figure out how to fool it, you're probably clever enough to figure out how to do the assignment in the first place.

[ Parent ]
Missing the point? (none / 0) (#75)
by u02sgb on Tue Jan 09, 2001 at 05:04:50 AM EST

Is that not missing the point slightly though? This isn't meant to be inflammatory but you do get a lot of arrogant "I'm the best programmer I know" types in 1st and 2nd year CS courses. These are probably the very people that would benefit from a more structured approach to there own programming. Remember that a lot of people know the body of there 1st and 2nd year courses before they go to the lectures (or not as the case may be), and simply put a structure around that understanding.

A lot of your CS course was about learning how to do what you already 'knew' in a structured manner.

[ Parent ]

I can't tell if you mean that... (none / 0) (#78)
by elenchos on Tue Jan 09, 2001 at 03:29:29 PM EST

...they would benefit from the structured approach demanded by making your code fit in the structure of group project, or the structrue demanded by working in isolation and doing exactly what you were assigned on your own.

If it is the first one, I think that is similar to what I am trying to say. You have these elite coders who come to school knowing everything and having contempt for others. Some of the potential of these guys is being lost by not teaching them to get the most out of those less quaified than they are. And not teaching them how to handle it when someone else is right and they are wrong; rather than being happy that a solution was found and the project can go forward, often they dig in their heels and want to get into a contest to reclaim the title of top dog.

Please elaborate.

Adequacy.org
[ Parent ]

The first one:) (4.00 / 1) (#82)
by u02sgb on Thu Jan 11, 2001 at 10:13:04 AM EST

Actually I was meaning more along the lines of some of the experience I had in second year. We had at least one guy in our tutorial group who (verbally) came up with novel and interesting solutions to the problems. Unfortunately he didn't have the ability to implement them because there was usually at least one small aspect of the problem he couldn't get his head round. Don't get me wrong he was a bright guy (if a little arrogant) but he was usually the one who was asking around for a copy of somebodies code just to make sure he was doing it right a day before the hand in date:). His general knowledge of programming meant he could get around the similarities between programs. Sad to say he didn't make it past second year.

What I'm really trying to say is that finishing an assignment maybe allows you to solve a complete problem as opposed to the details that interest you of the problem. It's maybe what seperates a good debugger from a good programmer. But then again I could be talking drivel:)

[ Parent ]

it's in the arrows, man (3.57 / 7) (#46)
by simonb on Sun Jan 07, 2001 at 08:03:44 PM EST

It's not what you know but who you know.

Well, is this the case, or what?

I am a second generation programmer
and make code like others make sandwiches.
It's easy, yummy, and sometimes I have mustard aswell.
Most mornings, however, I wake up terrified, lonely,
and maybe I can't make it to midday without
a drop of red. Why is this?

I have a degree in Science, majoring in Math.
This was for my personal interest,
I did a little comp sci, but hey, it's all
pretty straight forward as far as im concerned.
Today I can pick up Knuth and it's enough to keep me on track. The equations don't scare me any more.
And you can't get the math from the CS dept!
It just don't work, you gotta hang round with the masters
(i guess if my dad was a mathematician i'd be saying this the other way around)...
Anyway, coming to my point:
So im a genius.
So what, who cares?
i never worked with anyone at uni,
still don't know how to do it.
I DONT CARE ABOUT THE COURSE WORK.
SHOW ME HOW TO COMMUNICATE
AND BE HAPPY WITH MY FELLOW TRAVELLORS.
How hard can it be to mark students based
on work done in groups?
It's like competition, only symetric
instead of anti-symetric:
people in teams cooperate instead of compete...
hold on a second while i construct
an algorithm that extracts individual
marks from a sequence of marked collaborations
(round robin etc.)....

ahhh, that's better.
Actually, this is an interesting problem
and if you have any ideas let me know :) .
It seems to me that if you do something
naive like take averages you won't
find the losers, but
if you, say, use weights and look for
consistent trends (i think a subtraction is involved ie. an anti-symetrisation )
you should be able to catch them (and the winners too).

The most prolific mathematician
ever (Paul Erdös), published
something like 1500 papers,
the vast majority of which were joint papers.
And let's not forget the *hard-core* scientists,
the physicists and chemists etc., who
often publish in huge teams.

So,as in "category theory", the meaning (or reality) is in the relationships, not in the individuals.

Stick that in your compiler :)

BTW: you computer nerds have too long sentances.

or have i been staring at my C code for too long?
_one_ thing per line...

So what is the problem with school these days?
Everyone, including the lecturers,
is avoiding relationship.
Everything you do is trying to preserve
your own collection of goodies,
and separate it from all the rest.
And this is 'cause where all dying here
in this hot-red place of noise and fear.
Where is the understanding, the compassion?
That is why school is failing.
People are being separative,
hoping somehow to maintain
a mechanical, repetative existance...

Just keep padling; keep padling.
But one day, you're gonna run out of breath...

Teams (3.75 / 4) (#49)
by FigBug on Sun Jan 07, 2001 at 09:43:29 PM EST

First a quote from one of my profs at UVic:

Mantis H.M. Cheng explains why he wants work done in pairs:
"Some of you have asked me, 'Why do I need a partner? I'm so smart.' The reason is, your partner is an idiot!"

That pretty much sums it up.

Collaboration vs. Plagiarism (4.50 / 2) (#50)
by martinchmiel on Sun Jan 07, 2001 at 09:50:56 PM EST

I believe that there is a big difference between "Collaboration" and "Plagiarism". I myself studied my first year at the University of Windsor in Windsor Ontario; Taking the Computer Information Systems program. We were encouraged to work together in groups and "brainstorm" ideas in order to solve problems. Doing "group" assignments was a big part in the program but it all came down to tests and exams where you were on your own and that's where you knowing what to do counted the most. So working in groups and doing assignments together I believe should be allowed because we all know most of our grade comes from the exam(s). The key is to learn from other people and the easiest thing is to learn from your friends. There are the few people that will plagiarise and that will definetely show when exam time comes. I now will be transfering to a University in Waterloo, Ontario; either Wilfrid Laurier or University of Waterloo. And from what I read from the previous posts I might run into a different environment. my .002$ martin..
martin.. waterloo.ontario.canada
UWaterloo (none / 0) (#68)
by Kinthelt on Mon Jan 08, 2001 at 04:58:27 PM EST

For the most part, even "Brainstorming" is frowned upon at Waterloo. But seriously, there are very few students who would make it past first year without at least comparing ideas. Not just in Comp Sci classes, but in pure math courses too.

[ Parent ]
A hard call. (4.00 / 2) (#51)
by www.sorehands.com on Sun Jan 07, 2001 at 10:39:26 PM EST

You can't write code in a group, if you can't write alone. But, having someone to bounce ideas off or point out a problem (or you find when trying to explain it) when stuck helps immensely.

During my first semester, I was tutoring a classmate in Comp. Sci II (in Pascal). The professor (who is real nice) questioned me, since she saw my programming style in my classmates code. The professor knew that neither of us would cheat.

The question is, where is the line? Where does it cross from being paraphrasing to plagerism? Where does helping stop and doing the work for someone else begins?

This is the problem that the school has. They have to draw a line someplace.



------------------------------------------------------------------------------
http://www.barbieslapp.com
Mattel, SLAPP terrorists intent on destroying free speech.
-----------------------------------------------------------

There is a solution. (4.80 / 5) (#53)
by ultrasoul on Mon Jan 08, 2001 at 04:23:20 AM EST

I'm a student at WVU and last semester I took the "Intro to C and UNIX IPC" class, CS 156. This is typically a sophomore or junior level class, depending on what road you take. I was a sophomore and I've been doing UNIX and C since 9th grade so this was a pretty basic class. I have my gripes about the teacher's inexperience with the subject matter, but in the end he is a very smart man and a very good teacher.

His solution to this problem was to create a universal idea of the assignment and vary the details from student to student. For example, our first program was basically an exercise in file IO procedures. Your program had to take input and give output for all the fields (5) of a given object type in XML, ASCII, and binary. You also had to design two child objects (inheriting classes +3 unique elements not specified in the parent) and write the IO procedures for them as well.

By changing the object type from student to student (mine was sun glasses of all things) we were able to work in groups without risk of cheating because everyone had to write something almost completely different. I finished my assignment about a week early and asked if I could give the source to other students in the class, I told him I would release it under a BSD license where you can take the source, modify it, and redistribute it, but you have to give credit back to the author, and if that happens to get you in trouble with your school, so be it. He actually really liked the idea and a few students actually came up to me and him in class with specific problems they were having since they could see with my program what was required.

Does this sound like a solution? I can imagine situations where it fails, where varying the project just too much or not enough can push the system far worse then just a blanket "NO COLLABORATION" warning, but they seem minimal enough. What do you think?

at my university ... (4.66 / 3) (#54)
by Joeri Sebrechts on Mon Jan 08, 2001 at 05:42:23 AM EST

I'm currently following CS at the university of Antwerp, Belgium.
And here the policy is completely different.
Students are encouraged to help eachother, even with dedicated mailing lists setup for each year separately. Although at the same time it is forbidden to duplicate someone else's work, and projects are thoroughly checked for that. The first team project you get is immediately a 6 man project forcing you to have a management structure. In fact, management skills is what you're supposed to learn in this project, since it's expected that by then you already know how to program. They make it very realistically, asking too much features in too short a time span, demanding full structured documentation of everything, and changing the featurelist shortly before release date. And it's all done so realistically that I still don't know if it was geniously devised and on purpose, or if it was pure incompetence.
Also, not really related, instead of focusing on a whole plethora of programming languages we get just the minimal amount of languages, which are viewed more in depth than I could have possibly imagined (although they leave a lot of the work up to the students, expecting them to know their stuff by the end of the year, without really having had a complete explanation of how everything fits together)

Basically, I've found this approach to be the best to teach programming (from a students perspective in hindsight). It teaches you independant study, and team work at the same time, it covers every feature of C++ (and thereby almost every feature of almost every programming language), and it also teaches you about management in a practical way, something you do NOT want to learn "on the job". Also, they demand full structured documentation with every project, forcing you to adopt a documenting programming style.
Sadly, programming is not the only thing they teach you, and the rest of the course isn't all this well devised.

Still I think it's a bad idea to not let students cooperate, as that is what they'll end up doing anyway when they finish their studies. And the better the studies emulate the working environment, the more effective they'll be.

different perspective? (4.66 / 3) (#57)
by bluebomber on Mon Jan 08, 2001 at 09:12:47 AM EST

I got degrees in both Business Administration and Computer Science. From almost day 1 in the biz classes we were involved with group projects. These involved a wide range of assignments (papers to spreadsheets to problem analysis and solution proposals). Generally the group is given a grade, and each member of the group is allowed to rate the others in the group. There was little "leeching" taking place: by the end of our first year, either the moochers had failed out or we were able to recognize who we didn't want in our groups.

This can work in CS too. Speaking from experience, some of my most productive time has been during pair programming. As others have pointed out, though, it is not enough to simply provide instruction in CS, give an assignment, and say "work together". It is much more effective to provide instruction in how to work together. The biz program requires a course in the study of organizational behavior. Something similar (aimed more at engineers) would be highly effective at helping CS students work effectively together (both during and after school).
-bluebomber

When 'cheating' is caused by a professor (4.00 / 3) (#58)
by Kugyou on Mon Jan 08, 2001 at 09:57:44 AM EST

At the university I sort of attend (off-and-on student), we have a certain CS professor that nobody likes. She used to be an IBM wage-slave, and tries to teach everybody to be the same. She grades heavy on documentation, light on functional code, but scrutinizes the code to look for 'cheating' (copying) after telling us indentation styles, variable names, 'proper' function declarations, operand usage, et cetera, essentially telling everyone that *their*code*must*all*look*alike*! And *then* has the balls to tell people that she thinks they've been cheating. I got accused of cheating twice in that class, and I - at the time - was the most antisocial, don't-bother-me-I-do-this-for-a-hobby coder in there (didn't even speak to the other students).

Well, the finger to that cubicle crop.

Anyway, anybody else had this happen? Professor tell you how to code, then accuses you of cheating when your code *fits*what*they*tell*you*?

-----------------------------------------
Dust in the wind bores holes in mountains
Put simply, (4.00 / 3) (#60)
by trhurler on Mon Jan 08, 2001 at 11:23:12 AM EST

you are wrong. The professors are right. Yes, working on large projects requires collaboration. However, this is like editing an encyclopedia - you cannot possibly do it until you have honed your reading and writing skills, and that is NOT a group activity. Until you're proficient in those things, group work just lets lazy people avoid learning things they need to know. Similarly, until you can read, write, and debug code proficiently, group work just lets some people not learn while the ones who already know or can figure it out do all the work.

This is not to say you shouldn't get together with your friends and have fun writing some code together - just don't do coursework together. During my college years, I wrote code for a mud and shared a network connection with a friend who was a much better programmer than I was at the time, which allowed me to collaborate with and learn from him - but we wrote our academic exercises alone, and with good reason. If you don't understand an idea, get a friend who does and work on the idea - write code if you have to - but not the code you're going to turn in. You need to prove - to yourself AND the professors - that you can do it yourself - and ENTIRELY yourself.

--
'God dammit, your posts make me hard.' --LilDebbie

Comp Sci at MTU, STU (5.00 / 1) (#62)
by Zebulun on Mon Jan 08, 2001 at 11:49:12 AM EST

I've been to two schools, Michigan Technological University and the University of St. Thomas. At MTU, we were encourage to code with partners. With lame teachers, it helped. At STU, it varied with professeur. Most profs allowed you two work with other people, but you were supposed to turn in your own work.

The fact is: at work, you work in groups. And it's not like you can get by by just leaching off a partner. There are tests.

no collaboration here as well (5.00 / 1) (#64)
by b1nd0x on Mon Jan 08, 2001 at 12:57:48 PM EST

Here at my school, not only do they not allow collaboration on code, but they go quite a few steps further than just comparing execution time to catch cheaters. a graduate student as a projecct developed a system to check electronically submitted work for plagiarism, i.e. the source code itself. how it works is a closely guarded secret (and i can't seem to find the arcive about this in the crimson archived) but, while some claim it's just a scare tactic used by the administration to dissuade cheating, it has been wielded to great effect in the past. or they just did a hand check and called it this program...but the consensus on campus is that they do have a system like that.

this is enigmatic because in my math class (theoretical lin alg multi-var) we are absolutely expected to collaborate. all the assignments from the class are proofs and he gives us harder problems because he expects teamwork and also the insights to bleed from the smartest/most experienced kids. on the midterm, which was similar to our problem sets but individual, the problems were decidedly easier and more straight forward, though still difficult. meanwhile the CS department here still insists that students absolutely not collaborate on assignments, or, while you can discuss assignments, there can be absolutely no sharing of code.

Collaboration is essential to coding (4.25 / 4) (#65)
by thoryorak on Mon Jan 08, 2001 at 01:17:58 PM EST

Programming on your own might be ok if you never worked with another human or you were Donald Knuth and could readily come up with brilliant algorithms. But for any other situation, going it alone is nearly impossible. Think of the time it takes to write modern programs. There's a reason they measure development time in "man-years".

I'm a CS student at Dartmouth College and many of our CS courses require teaming up with at least one partner. You learn write clear, intelligible code with comments, something a lone programmer might never do. Other people suggest modifications you might never have thought of on your own.

Any reasonable professor would surely see the benefits of such experiences. I suggest you talk to the department chair and see if you can't convince him otherwise.


And so it goes, and goes, and goes....

An actual class at my college (5.00 / 1) (#66)
by hughesjo on Mon Jan 08, 2001 at 02:37:52 PM EST

At the college I went to (A small private college in upstate Iowa) there was actually a class in this. The school wasn't reknown for being a computer science school, but one of the classes you took two years into the was Program Project Design, or soemthing of that nature.
The class was divivded into an equal number of students, you came up with your own project, and the only thing the class was graded on was the end project. Everyone had to work together (Documentation, coding, etc) in order to finish. I don't program after college but it was a great help. They need more of these for programming classes:)

LOL: A telling state of affairs. (4.00 / 2) (#67)
by elenchos on Mon Jan 08, 2001 at 04:44:29 PM EST

I noted this morning how `flat' this discussion is. Almost everyone posted directly to the article at the top level, rather than as a reply to one of the previous comments. I think at least half of what's here could have been a reply to a previous post. I think that shows what fantastic egos programmers usually have (myself included, notice this is a top level comment!), and how much resistance to working together there is. It is no big deal to me if the soon-to-be wash outs get pulled along a little. The problem is that the ones with talent are not developing the ability to work with others early enough, and are in fact having their insular attitudes reinforced by systems that make sharing a dirty word.

I think also that an objective observer will note the tendency towards un-called-for combativeness and unwillingness to compromise among the code elite. The likelihood that such elite geeks have little or no experience with team sports or military service doesn't help matters any. I think it is this character flaw that an undergraduate program can effectively address. You really do have to, sooner or later, develop reliable methods for cooperating with people who are less talented than you. Such people can actually contribute if you are willing to work with them rather than shun them. Moreover, you also have to learn to join forces with coders who are on your level, but have different ideas about what is `right.' Often a pair of top notch coders will waste all their talent butting heads rather than solving the problem.

Open source, by definintion, is a social activity. The success of that method is yet more proof of the value of teamwork and team-building skills. Fear of `being copied' is immature, and should be overcome.

Adequacy.org

Being copied (none / 0) (#76)
by Morn on Tue Jan 09, 2001 at 08:25:24 AM EST

Open source, by definintion, is a social activity. The success of that method is yet more proof of the value of teamwork and team-building skills. Fear of `being copied' is immature, and should be overcome.

Is the 'real world' not different from a teaching environment though? In the 'real world', it is the quality of the final product that matters most, but an assessment is meant to assess individual skill.

If 'being copied' in a marked assignment gives copiers grades on a par with the copyee, the copyee's final qualification might be devalued in the face of others (and, in my opinion, rightly so) when the copiers [the majority, in my experience, if they can 'get away with it'] get out into the 'real world' with the same qualification and little ability.

[ Parent ]

Based on what I'm reading... (5.00 / 1) (#77)
by elenchos on Tue Jan 09, 2001 at 02:46:48 PM EST

...it would seem that it is generally recognized that being unable to work in groups is not something employers look for. I would expect that in a competitive environment, recent graduates with greater experience with teams would have the advantage over those who only had one big team project at the end of their studies. Ironically, that one big project in the senior year (I'm describing Gonzaga here) will be graded as a team, and since it is the most recent work the student did, will be given more weight than whatever happened back in their first programming course. This unfair effect is exacerbated by that situation.

My point about `fear of being copied' is that sooner or later everyone will be judged on their own merits, and that you ought not to worry about your own reputation being slighted because a few first year students slacked off and didn't get caught. In my own experience, a top student who takes the time go help the slower ones and gets as much out of them as he can will attract a lot of positive attention, and that will stick with his reputation far longer than some grade on a team assignment.

I hear some others also saying that the majority are copiers. Maybe in the very first programming class, among those who aren't even sure if they want to major in CS, but I think their numbers are being inflated. Certainly their importance is being overestimated. The ones I am worried about are the talented students. Are they learning as much as they could be?

I suppose your school could get a bad rep if they actually gave degrees to students who just copied code, but that seems an unlikely scenario. Most of them won't make it past first year; certainly they will be gone by senior year, even without a concerted effort to isolate programmers and catch cheaters. Programming is only part of a CS curriculum. There are several math classes to take, for example, which is a hard skill to fake. And in a data structures class for example, there are plenty of things that can be tested for accurately, such as calculating Big O of an algorithm. The ability to write 10 to 20 line functions can be tested for as well, usually 2-5 in a 1-hour test. If you didn't do the coding before, you are not going to have time to learn how during the test! If the instructor has 25 possible algorithms that could show up on the test, and a student memorizes every one of them and just regurgitates that on the test, well good enough. If they are doing well in the math, and everything else, and are walking around with a head full of memorized algorithm implementations, I'd hand 'em a diploma.

Looking at the larger picture, this is a small factor in the way schools pick up reputations. The performance of sports teams, unfortunately, or what US News & World Report says about a school can have a huge impact. An impact, at least, in the minds of a human resources drone who lacks the discernment to actually talk to an applicant and see if he or she knows anything. Those who do know what they are doing (the only kind I hope to ever apply to for a job) are not going to be fooled by all that extraneous stuff. They will be able to tell real quick, by your attitude alone, if not your record, if you will be an asset to a team.

(Thanks for replying to my comment. I was beginning to think there wasn't going to be any dialogue after this article!)

Adequacy.org
[ Parent ]

Groupwork, Testing, Real Life (5.00 / 1) (#79)
by Morn on Tue Jan 09, 2001 at 05:45:31 PM EST

I've quoted a lot - your reply was extensive! Anything I've not discussed, you can take as me agreeing with :-)

Based on what I'm reading it would seem that it is generally recognized that being unable to work in groups is not something employers look for.

I agree! I wasn't suggesting that no group work should be done, but that any projects intended to test coding ability, understanding of concepts or something of that nature should not be collaborative.

In my own experience, a top student who takes the time go help the slower ones and gets as much out of them as he can will attract a lot of positive attention, and that will stick with his reputation far longer than some grade on a team assignment.
Yes, but it's a thin line between 'helping' and 'doing work for' (not that I'm arguing that it can't be walked on the correct side if you're careful).
I hear some others also saying that the majority are copiers. Maybe in the very first programming class, among those who aren't even sure if they want to major in CS, but I think their numbers are being inflated. Certainly their importance is being overestimated. The ones I am worried about are the talented students. Are they learning as much as they could be?

I suppose your school could get a bad rep if they actually gave degrees to students who just copied code, but that seems an unlikely scenario. Most of them won't make it past first year; certainly they will be gone by senior year, even without a concerted effort to isolate programmers and catch cheaters.

You may be right - most possibly wouldn't reach the end and receive good grades, however, I know from experience that there exist people who are not afraid to work off the backs of others and domake it through the system to at least leave with a 'recognised' qualification.

Programming is only part of a CS curriculum. There are several math classes to take, for example, which is a hard skill to fake.

But if you're having a hard time learning maths, it makes things easier if you can copy your programming exercises.

f they are doing well in the math, and everything else, and are walking around with a head full of memorized algorithm implementations, I'd hand 'em a diploma.

I'd have to disagree here, if we're talking about a Computer Science course. The ability to program is an important part of Computer Science, and it must be tested somehow. I don't think exams are adequate for this.

Though it might not look like it, I think we may actually be coming to something of an agreement. I would say that group projects have an extremely important part to play, but that there must be measures in place to ensure that people cannot make it all the way through a course simply by leaching on others. I don't, however, think tests are the only (or, indeed, the best) way of ensuring this. Individual programming exercises, designed to test knowledge of concepts and ways of reasoning are an important part of a CS course.

On a slightly different note, many of the group projects at my university are marked individually, with each person's contribution being assessed individually, but with a prize (something small usually, like a box of chocolates bought by the lecturer) for the best group effort. I think this is a good way of encouraging good teamwork, while still assessing individuals as individuals.

(Thanks for replying to my comment. I was beginning to think there wasn't going to be any dialogue after this article!)

Yes, I sometimes wonder if some people actually look at articles once they've left the submission queue.

[ Parent ]

Agree, and a quick elaboration. (5.00 / 1) (#80)
by elenchos on Tue Jan 09, 2001 at 07:38:21 PM EST

I think most everyone agrees that there should be group work for upperclassmen. The questions are, should it also be done early for underclassmen, and should ensuring students don't help each other be strongly enforced, or should the policy be lax?

One side is justified by avoiding the negative consequence, that of the poor performers being carried along. The other disregards this, and and wishes to avoid the problem of elite coders who lack team skills. I see both sides, but feel the benefit of making the best coders better to be of overriding importance. It is pretty subjective.

I'm still hoping someone will post some kind of objective measure to help uncloud this. I couldn't find anything in my research, but I'm sure others can do better. Even a subjective opinion comparing the relative value of graduates from the two types of schools would be nice. Most people seem to only have experience with either one or the other, with the exception of those who make hiring decisions. Yet do they seem to be holding back?

Adequacy.org
[ Parent ]

Collaboration left up to professors at Colo. State (4.33 / 3) (#72)
by meldroc on Mon Jan 08, 2001 at 05:49:57 PM EST

Here at Colorado State, the official CS Dept. policy has an extensive cheating policy, and one of the policies (aside from plagarism) forbids "unauthorized collaboration," meaning the instructors decide for themselves how much collaboration is allowed. In most cases, each student is required to turn in his own assignments, but most professors make it clear that it is acceptable to work with other students, as long as no blatant cheating happens. In my last class, taught by an Extreme Programming fan, we were required to pair up for our coding assignments, to do the Pair Programming thing. I found it quite helpful. For the most part, this policy makes sense, as long as the instructors make sense.

UVA doesn't do anything like that... (4.50 / 2) (#73)
by egregious on Mon Jan 08, 2001 at 05:57:45 PM EST

The University of Virginia's CS program (the programming ones, anyway) make a point of having some projects be "groupware" and some be single person efforts. In fact, some projects are structured so that they are split over several weeks (different lab periods) and start out as single person efforts that are then transformed into group efforts. I always thought that system was particuluarly good because it had new students dealing with large projects that enforced good (modular) design practices.

Of course, people were "on their honor" to not cheat. But UVA's honor code is a little bit bigger deal than it is a most other schools so cheating is a little more looked down upon.

Johann

We are rather encouraged... (5.00 / 1) (#81)
by Haglund mdh on Wed Jan 10, 2001 at 05:08:20 AM EST

At my universitys (Mälardalen in Sweden) CS education program, we are often required to work in groups, mostly groups of two. This, probably because they want us to have more experience in working together with other people about a task. I think it is a good idea.

Story from the UW.... (4.50 / 2) (#83)
by amnesiak on Thu Jan 11, 2001 at 04:00:05 PM EST

Actually, they go so far as to create programs that compare the code with generic variable names and such.

My freshman year, i was coding a project and my roommate asked for my help on a loop. I helped him the way i did it (the only way i knew how), and because of that ONE LOOP we got called in to the office.

I got full credit but he got half off. just for getting help on one loop.

I think, along with the author, that working with others is a valued and necessary experience. Luckily, it seems to be more valued and required in Electrical Engineering.

-amnesiak
they're trying to avoid what I went through (5.00 / 1) (#84)
by scotpurl on Sat Jan 13, 2001 at 12:32:06 PM EST

At an unnamed university, I began taking the C programming class sequence. I was amazed at how quickly the other students completed the assignments, and how me and my two friends lagged so far behind. When we compared programs, our programs looked nothing like what the rest of the class had written. Our programs didn't even look similar to each other. We felt we were really lost, and doing everything wrong.

We finally figured out what was going on after a C.S. major friend explained it to us. Us three, being the only non C.S. majors, weren't in the loop. The professor never changed what the assignments were, so the rest of the class just took the completed program from someone who had taken the class a couple of years before. The only difference between the programs was a little formatting, comments, and variable names.

Sometimes you have to do extreme things to prevent cheating.

CS structure. (none / 0) (#85)
by fujisan on Sat Sep 22, 2001 at 11:09:26 AM EST

Firstly, I'd like to say that the above comments about CS are dead accurate. It's still to easy to cheat, hence the massive people who can't program properly by 2nd/3rd yr. I lasted 1.5 yrs in CS before I dropped out. I'm in Melbourne, Australia, prior to coming into this course, I and perhaps half the ppl lecture hall didn't have a clue what the hell programming was and what it involved. Also due to the lax policies of the university which shall remain anonoymous, plagarism was rife. Out of the 200 or so students 1st year (rough estimate), 1/2 the students cheated duplicating code. There was absolutely no policy in place to filter out these people, not even a plan to. It was a case of the tutor's reponsibility to check and report this to the head tutor and usually, there was little if at all action done. The major problem was that the tutors often themselves were undergradutaes who also had studies of their own. Another problem is filtering the genuine studenst and ones who can't really program before it was too late. The system is flawed in that uni, it was a case of too easy 1st yr and followed by a hell of a second yr gap as large as the grand cayon. There are still guys I keep contact with in 3rd yr (final) that still cannot program properly at a decent level, god knows how they passed. However, the exam system is flawed as well, these guys sticking in there for the sake of it are almosy regurguitating code out and by luck, get Passes or even DIs standards. Since CS is a heavily practical orientated, group work should really start at first yr. That's all I'll say *yawn*. It would be interesting fi there are any other drop outs out there and why they did. Personally I believe the theory that CS has 3 catergories: 1) u either get it 2) u either don't 3) u work hard and get avg marks as posted by a user b4. I was #3, however, he forgot to metion u really need the effort, heart and momentum to be able to succeed if u do so. Interest and momentum gave way soon after 2nd year, after I passed my software engineering project, I cou;dn't really see myself doung it for a living. I wasn't ur bright programmer but neither was i that crap.

Computer Science Students Unite? | 84 comments (83 topical, 1 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!