Every time I teach a course, I see my students making their lives harder than necessary. This is particularly true for group projects. To make sure they aren’t missing out on any opportunities to increase the challenge, I wrote the following top-10 list.
Ten proven ways to make your group project harder:
- The Scapegoat.
Designate your partner as master hacker and have her do all the work. That way she will burn out 3/4 of the way through the course; you won’t be able to finish the project since only she understands it.
- The Lone Wolf.
Decide that your partner is useless and you are the master hacker. Charge off and code everything up without talking to your partner. Unless you are very lucky, you’ll make some bad assumption that forces all your code to be thrown out anyway.
- The Round Robin.
Have a different person implement each programming assignment. This may work acceptably on the first step of the project, but by the third or fourth assignment the person implementing it will have no idea what is going on, and will have a much larger programming assignment to work on too.
- The Schism.
Separately implement the different pieces of the system with no discussion of how they will fit together. Ideally, don’t talk to your partner(s) until just before the assignment is due. Then there is no chance you will be able to glue the pieces together.
- The Borg.
The opposite of The Schism: Work extremely closely all the time, spending all your time talking rather than doing actual implementation; the group will slow down to at most the speed of one person. For extra effectiveness, everyone simultaneously edits the same files. The whole system never works at any given time because something is always broken; also, you can’t figure out which of multiple entirely different untested modifications are causing the current bug.
- The Vicious Cycle. Everyone on the team feels that they are working harder than everyone else, and scales back their effort accordingly. This causes another round of mutual outrage. Eventually, everyone does no work because no one else is doing work. As the deadline nears, you can switch to…
- The Blitz.
Don’t start until three days before the assignment is due. Then pull three all-nighters in a row. Lack of sleep will ensure you write broken code. With luck, you will get sick and blow some other classes too!
- The Stoic.
Don’t ask the TAs or the professor any questions when design problems come up; put off working on the project and hope the problems will magically solve themselves before the due date.
- The Blank Slate.
Don’t use any of the ideas from this class. This works best if you don’t attend class at all. Why pollute your mind with course material?
- The Time Machine.
Don’t bother doing any of the programming assignments; surely you are graded on only your final project, right? Count on the extravagant mercy of the course staff and on having lots of time later on to finish the project up. Of course neither will materialize, and you’ll get so far behind that you can’t finish!
Bonus method: The Combo.
If only one of the above techniques fails to add sufficient challenge, pick two (or more!) and use them together.