Advices: What to Avoid in CS 413
by Andrew Myers
Eleven proven ways to make your group project harder:
Designate one person 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.
Decide that one member of your group is useless and don't invite him to
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.
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.
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.
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
broken; also, you can't figure out which of four entirely
different untested modifications are causing the current bug.
For an additional bonus, forsake any revisioning system, and manage your files by sharing your
directories. Once your project grows in size, you'll have no idea who has the most up to date files
or which directory contains the fixed version. With any luck you'll turn in the that copy
you hacked out yesterday that broke half the previous code.
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!
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.
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.
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!