How to lose in CS 4120

Ten proven ways to make your group project harder:

  1. The Scapegoat. Designate your partner as master hacker and have them do all the work. When your partner burns out 3/4 of the way through the course, you won't be able to finish the project since only they understand it.
  2. 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!
  3. 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.
  4. 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.
  5. 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 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 multiple entirely different untested modifications are causing the current bug.
  6. 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...
  7. 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!
  8. The Stoic. 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. The Blank Slate. Don't use any of the ideas from 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 simple methods you learned in CS 2110 or 3110 for much simpler languages. For example, use top-down parsing to write a single-pass compiler that generates stack-machine code! Your compiler will be flaky, won't provide all the required functionality, and as a bonus, will generate terrible code.
  10. The Vibe Mirage. Who needs to write code any more—don't we just ask Generative AI to do the work for us? This approach might sound like it's going to save a lot of time and headache, but it won't. AI-generated code will look very plausible until you test it carefully and find it contains subtle bugs that waste far more time than they save. Since you build each step of the project on top of your existing code, your foundations must be solid. Using AI will undermine your understanding of your code, which is critical for success.