Cornell University Computer Science Department, Spring 2012
Proven ways to make your lab and group projects harder:
Don't start until three days before the assignment is due. Then pull
three all-nighters in a row. Unfortunately, this approach will work
fine for lab0, designed to get everyone
warmed up and on the same page. While all-night hacking sessions
can be fun, too much caffeine can and will make you
hallucinate. For instance, if you are convinced that the course
staff will grant you an extension for having started late, you are
hallucinating.
Designate your project partner as the master hacker and have her do
all the work. That way she will burn out 3/4 of the way through the
course and you will not be able to finish the project since only
she understands it.
Decide that your project partner is useless and don't invite him to
group meetings. This makes you the lone master hacker. Two people
can play this game, but the chances are pretty good that
both will simultaneously burn out 3/4ths of the way through the
projects.
Have a different person implement each project, in a grown-up's
version of the hot-potato game. Unfortunately, this will work
fairly well early on, but by the fifth or sixth assignment the
person writing the code will have no idea what is going on. Chances
are pretty good (well, 50/50) that the person having to deal with
the problem, and the associated nervous breakdown, will be your
partner!
Have everyone implement separate pieces of the system with no
discussion of how they will fit together. Ideally, talk to your
project partner just once to do the split, then do not talk
at all until 15 minutes before the deadline. Bet this is how
real-world engineering is done, right?
Opposite of the previous technique: 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.
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.
Do NOT look anything up in the MIPS reference manual. If it's important,
then course staff can individually tutor you. If not, it's not worth
implementing!
Don't use any of the techniques for processor implementation or
systems programming 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 instruction set instead of using the common MIPS
interface, use a different tool set from everyone else where you
have to reimplement all of the modules we provide to you, modify
the simulator so it implements new semantics. Do not use Makefiles,
write your own scripts for compiling the projects.
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.
Don't bother doing any of the homework assignments; surely, they
are each too small a component of your grade to worry about, right ?
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.
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!
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 of code
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.
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 processor cannot
reliably execute one instruction, you should get extra credit for
having implemented a super-pipelined, super-scalar design with
out-of-order issue and speculative execution.
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 1110 -- why would it not
work in a 3000-level course? Probably because the compiler does not correctly implement
the C standard. Demand that the course staff fix up the compiler at
once so your obviously correct code can be parsed. 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's either because the compiler is producing bad assembly
code underneath the covers, or the C runtime has a bug, but
which is it???