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.


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.


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.


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.


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.


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


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.


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.)


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.