How to lose in CS 412
Andrew Myers, Spring 2001

Ten proven ways to make your group project harder:

1. Designate one sucker in your group as master hacker and have her do all the work. That way she will burn out 3/4 of the way through the course and no one else will be able to finish the project since only she understands it.
2. Decide that one member of your group is useless and don't invite him to group meetings.
3. Combine techniques 1 and 2: decide that all the other members of your group are useless and you are the lone master hacker. Charge off and code everything up without talking to anyone else. Unless you are very unlucky, you'll make some bad assumption that forces all your code to be thrown out anyway.
4. Have a different person implement each programming assignment. Unfortunately, this will work fairly well on the first programming assignment, 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.
5. Have everyone implement separate pieces of the system with no discussion of how they will fit together. Ideally, split the group into two or more factions that don't really talk to each other until just before the assignment is due. Then there is no chance you will be able to glue the ill-fitting pieces together.
6. Opposite of #5: Work extremely closely all the time, spending all your time talking among yourselves rather than doing actual implementation; the group will slow down to at most the speed of one person. For extra effectiveness, everyone simultaneously edits different files in the same directory. That way, the whole system never works at any given time because something is always broken; also, you can't figure out which of four entirely different untested modifications are causing the current bug.
7. 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!
8. Don't ask the TAs or the professor any questions when design problems come up; just put off working on the project and hope the problems will magically solve themselves before the due date.
9. Don't use any of the techniques for compiler building that you learn in this class. This works best if you don't attend class at all, so you avoid polluting your mind with the course material. Write your parser and code generator using the hackish shortcuts you learned in CS 211 or 312 for much simpler languages. Your compiler will be flaky, won't provide all the required functionality, and as a bonus, will generate terrible code.
10. Don't bother doing any of the programming assignments; surely you are graded on only your final compiler, right? Count on the extravagant mercy of the course staff and on having lots of time later on to finish the compiler up. Of course neither will materialize, and you'll get so far behind that you can't finish the project!