Reflections on Programs
by Jon Moter and Amanda Silver
The focus of cs15 is clearly on the programs. It is what the students
will remember the most, and what the most time is spent on. Thus, it
seems the most time and effort are spent on the programs, and well they
should. Students learn the material through the programs.
Issues involved in the programs
Here are some of the things we felt were issues in the programs of cs15,
and how they were dealt with this past year.
Goal of Programs
We feel that the goal of the programming assignments is to allow
students to practice and implement the ideas that are taught in
class. Programming is a skill which is acquired primarily through
practice, and therefore the programs are the outlet for students to hone
their skills in programming. Thus, they should be designed in order to
emphasize and follow the principles taught in class, which we feel they
do a good job of doing.
Design
The designs of the programs were highly stressed in cs15. Between the
design checks, the focus on patterns, and the emphasis of design in the
grading scheme, design was clearly one of the concepts that was highly
emphasized in the grading. We felt that the programs taught design
fairly well. While the design was mostly given away with the early
programs, as time progressed the students were asked to do more design
on their own. We felt the design checks were a good measure to make sure
that students thought about the design, and also an opportunity for TAs
to offer guidance, and steer people away from possibly troublesome
design decisions.
Of course, there comes the question of whether design should be the
primary focus of the programs. Another approach would be to make some,
but not much, emphasis on design, and focus more on functionality and
implementation. This question brings up the issue of whether cs15 is
intended to teach object oriented design, or teach the students how to
implement programs effectively. It seems that some students get out of
cs15 with a pretty good sense of how to design a small to moderate sized
system, but have serious problems with implementing that system. Whether
that is more or less preferrable to a focus on implementation is a huge
question, but certainly reflects on how we present and grade the
programs.
Grading
While grading of programs is not perfect, we seem to do as good as job
at it as possible. One issue with grading is the problem of
consistency. Students who submit equivalent work should get an
equivalent grade on the assignment. This is primarily addressed by
having one Head TA in charge of an assignment, and be responsible for
assigning point deductions or extra credit for a program. However, when
different TAs are grading assignments, there is still always the
possibility that one will have a sharper eye, or be less forgiving, than
another. This seems to be somewhat unavoidable, but training on how to
grade can hopefully alleviate that problem as much as possible
Also, there comes the question on how to grade on design. Design is a
somewhat subjective thing, and there is rarely one "correct" design for
a program. The policy that was used this year was to give a student
full credit for a design if it was "reasonable" and/or they backed up
their design decisions. Obviously, there are times where a design which
a student attempts to justify is not well-justified (such as putting all
of Tetris in one class) and they lose points depending on how bad the
design is. Again, since this is a subjective issue, this makes the Head
TA in charge of the program responsible for evaluating the design, but
it is the same Head TA assigning points for an entire assignment, so at
least there is consistency in point losses.
The Programs
Most of the programs we really like. They seem to teach the material
well, and are ramped pretty well. A mojority of the students said that
they had enough time to work on the assignments...this is a good
sign. We are including the number of handins for each assignment. For
comparison, we created a total of 218 accounts for cs15, and there were
205 handins for Objects.
Cloud
199 Handins
The only concern we had with Cloud was the issue that the support code
was a little much for the first assignment. Some students were confused
by the idea that React() and Update() are called
automatically, without ever having to call them yourself. But most
students got that eventually, and we feel that it is a good first
assignment.
Street
190 Handins
Street teaches parameters and polymorphism. The design for this program
was essentially given away at the help session, but that was the intent
for the first couple of programs. Hopefully giving the design for this
program stessed the idea of polymorphism, which some people (but not all)
caught onto the year before. Not surprisingly, some people had some
trouble with parameters, but that happens to a lot of people when they are
first introduced to them.
One student said in their questionarre that
Street came at a difficult point in time, referring to the fact that not a
lot of the course material had been taught at that point. Matt Chotin, a
former TA, led an impromptu help session on street a couple of nights
before it was due. He says that he thinks that the reason the students
had a hard time with this program is because it introduced two major
concepts: parameters and polymorphism. He thinks that they went over
polymorphism well enough in the help session but they didn't do enough on
parameters. His suggestion is to have a really long help session; give
the design away as much as we did and explain polymorphism and,
especially, parameters in more detail.
MoviePlayer
189 Handins
We felt that MoviePlayer went really well for a new assignment. One of
the concerns that was addressed before was that students would not like
the requirement that the GUI had to be exactly like it was in the
demo. However, that did not seem to be much of an issue, and people
seemed to understand that the point was to teach how to create a
GUI. This was also the first introduction to GP, but it was a fairly
gentle introduction. The size of GP seems to intimidate some people, and
few people have a sense of how it works, and where to look for
components in it. That could probably be alleviated by a user's guide,
or some better teaching of how GP works.
"MoviePlayer I hear was an addition, GREAT CHOICE, I wouldn't not have
been able to do swarm without it, because having done MoviePlayer I
had the concept of GUI and containers and most importantly PARAMETERS."
-former 15 student
Swarm
183 Handins
Swarm is the first program in which there is a significant amount of
design that students must deal with. Design patterns are first
implemented in Swarm. Swarm is definitely a challenging assignment, but
it seems to be appropiate for its location in the semester. Aside from a
larger design, it does not cover any new concepts, but students must put
together a lot of different things in order for it to work. The design
check was really important, and stressed the value of a good design for
this project. One issue that seemed to confuse some students was how GP
managed to keep track of all the bees that you create. It is somewhat
contrary to the teaching that losing all references to an object causes
it to be garbage collected, so perhaps in the future it should be
explained how GP keeps a reference to every graphical object which is
constructed with a reference to its container. Behaviors were also
introduced in Swarm, and perhaps a better explanation of them could help
students with this assignment.
Tetris
176 Handins
Tetris is probably the longest-existing, unchanged, project in cs15, and
easily one of the most notorious. However, with all the years that it has
existed, it has been well-revised, and is a good project. One of the most
important things about Tetris, and something we should make sure we stress
to students, is how it is an incremental program to write. When tackling
Tetris, a student should work on it in stages: have the board appearing,
then have a piece moving down the screen, then have it stopping at the
bottom and sides, etc. Perhaps next year we should give the students a
suggested timeline of when they should have a given component of the
project done by. Many students did this for themselves, but it might help
people manage their time a little better, and give a good idea of how to
tackle a program this big. Students cited that the help sessions for this
program were the most helpful of all help sessions.
It seems that the students are prepared for Tetris by the time it
hits. Admittedly, it teaches a lot of new things, such as arrays, loops,
conditionals, and other flow of control constructs. Also, the size of
Tetris is significantly bigger than Swarm, which makes it more
difficult. However, despite its size and new concepts, it seems to be a
fair assignment, and the majority of people got fully functioning
Tetrises.
Amanda writes:
I vividly remember giving myself a rigid schedule. I remember being
completely overwhelmed with the project and I wanted to take Tetris a
little bit at a time so that I would be able to tackle it. First I
attacked the board. Arrays were new to me so I had to understand them and
how to implement them first. Then I had forgotten exactly how loops and
if statements worked so I had to brush up on that.
After the board, I wanted to make each piece appear. This was a part of
the design that I hadn't figured out yet. Do I assign each block a
position when I create the piece? Does each piece have to have an
instance of four blocks or can it contain an array of blocks?
After the blocks I had to make each one move around. I first tackled
left, right, and down, then rotate. After they could move I could do
border patrol..which checked to see that the pieces COULD move where they
did.
At the end I could work on checking to see that the game was over and
stuff. This was the ONLY way to approach the program...not necessarily in
that order but bit by bit. (No pun intended.)
PizzaDex
173 Handins
This was the assignment that seemed to garner the most complaints from
students. We gave this some thought, but did not come up with any solid
answers for it. Some of the problems we saw with it was that it dealt
with text, unlike any other program; much of the functionality was
trapped in the support code, which made debugging difficult; it was
advertised as an "easy" program after Tetris, but some students did not
agree. There is also the issue of the amount of code that can be copied
from the lecture slides. Some may think that this makes the program too
easy, or students too apt to copy code without understanding
it. However, it seems that most programs have analogous code somewhere
in the lecture foils that can be translated to the program on hand, so
that isn't much of an issue here. Regarding the copying but not
understanding, if the student wants to add the required additional
functionality of the previous pointer and the current node, she has to
understand how the existing code works.
We tried to think of some solutions to the problems with the
program. Regarding the visualization, we had two possible solutions. One
is to make a visualizer similar to that of cs16's. It seems that
creating a visualizer that displays all the nodes in a list is much more
useful for figuring out what's going on in your list. However,
visualizing an entire list like that would probably require the support
code to do much more, possibly behind your back. Another option we came
up with is to have the students write their own GUI to visualize the
list. That way the code is entirely theirs, and much easier to
debug. However, that would make the program larger, which probably isn't
what we want right before final projects.
Interestingly, in our final questionnaire, PizzaDex had more comments
than any other assignment (from Tetris on) that it was too hard, but
also the most comments that it was too easy. This seems to imply that
many people considered PizzaDex to be a no-brainer, but another large
chunk had a lot of trouble with it. It would be interesting to see how
those opinions matched up against the experience of the people answering
it, but we can only conjecture on it.
Final Projects
159 Handins (not counting 9 incompletes)
Both of us were involved with Adventure, so that is what we are focusing
on. For Adventure, learning a new Graphics package was understandably
challenging. ThreeD had several issues to fix for next year, but since
we will be using a different package, that should not be too much of an
issue. For the most part though, Adventure seemed pretty solid. There
was some question as to whether the Drunken Walk algorithm was on par
with the algorithm for Othello, but that seems to be a matter of
opinion.
Something we were interested in was the breakdown of final project
choice versus programming experience. Traditionally, it seems as if
Othello is the assignment which most unexperienced people gravitate
towards, but there were definitely quite a few people without background
doing Adventure this year. We did not have a very good sense of how
Orbit went, but for a new project it seemed to have many people do it,
and it turned out very well. Also, the skit was funny.
[BACK]