How to lose in CS 414

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. Ignore your group members - sure, they might complain now, but they will be impressed when you show up for the submission deadline with a working project.
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 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 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 building operating systems 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. Develop your own synchronization routines with their special semantics, build a filesystem interface unlike any other, modify the networking stack so it implements a new interface. Your system won't provide all the required functionality, will not support any of the test cases and applications we give out, and as a bonus, will crash or hang routinely.
10. Don't bother doing any of the homework assignments; surely, they are each too small a component of your grade to worry about, right ? Don't read the book or the papers that are part of the reading for the course; knowing more about the topic will only further the confusion anyway. The sections are for the weaklings who need to be told what to do; certainly you could do better. When you ultimately fail to make the deadline, try to look really innocent as you plead for the extravagant mercy of the course staff.
11. If you fall behind on a project, do not work overtime to catch up. Instead, work on the previous project when all your peers are working on the current one. You can even sound them out for ideas and figure out how they implemented the previous project, which will ensure that your implementation will be better than theirs. If your peers spend M weeks on N projects, and you spend M weeks on N-1, surely you'll roll all over them on those N-1 projects. Now, if only you could get the course staff to grade your previous project instead of the current one, everything would be perfect!
12. When your projects get boring, spice your life up by swapping project partners. Ideally, you will do this two thirds of the way into the course so that your ex-partners will be completely lost when you tell them that you want out and that they will need to work with someone else. Or, on the flipside, incite your partner to leave by not doing your part of the project. Try to clarify the situation through extended conversations with course staff about who wrote which exact line in each project. Better yet, try to convince the course staff that they should up your grade while cranking down your partners'. It's a zero sum game, but that doesn't mean that you couldn't come out ahead.
13. Add a fifth wheel to your project. The course projects are carefully designed to cover the most important aspects of a given topic and produce easily testable systems. As a result, they leave out some non-fundamental details. Get all worked up about the lack of "realism," and jam as many unnecessary optimizations into your project as you can. The more premature and unjustified, the better - surely you are not going to waste time quantitatively justifying the optimizations, when you could be going ahead and implementing them! Of course, this will make your base functionality unstable and prone to crash, but if you pull this strategy off really well, your project will be completely untestable anyway because it implements a different set of semantics than everyone else's. Don't forget to argue with the course staff that, while your filesystem cannot reliably write one byte to the disk, you should get extra credit for having implemented cutting edge optimizations for concurrent block writes.
14. Our all time favorite: first, write ALL your code on paper. Then enter it into the computer. Look puzzled as the compiler discovers 358 errors and 597 warnings. What could be going wrong here ??? Surely, this system implementation technique worked in CS 100 - why would it not scale up ? Probably because of errors in the compiler. Ask for extensive help getting rid of the compiler errors (never mind the warnings - they too are for weaklings to fret over). Look even more puzzled as your system compiles but core dumps/hangs/behaves erratically upon execution. It was all supposed to work right. You could "pretty much" prove it from the implementation on paper. It's got to be the compiler producing bad assembly code.