The Point System

The major experiment of the quarter was the use of what has come to be known as ``The point system.'' My previous experience with the lower division courses was that the students were not really getting enough hands-on programming experience. It seemed that the thing to do to aid those on the lower end of the curve is to allow large amounts of extra credit, giving them a chance to make up for any initial foibles. This also gives the students on the high end of the distribution the opportunity to engage in more interesting work on their own time, honing their skills and keeping their attention more focused on the course.

The second major theme of the point system stems from the fact that these are lower division courses, where students do not have the experience required to accurately judge the difficulty or expected time requirements for an assignment. Hard deadlines mean that if the student misjudged, they are very likely to turn in what they have finished for partial credit, and not finish the remainder of the assignment. Our goal as educators is to educate, which means finishing ought to be more important than finishing by an arbitrary time. In an upper division course there needs to be more requirement on hard deadlines to mimic the behavior of the corporate world, but the goals in the lower-division sequence should be simply to teach the students a language and give them the time and experience necessary to become proficient in programming with that language. The students in CS 14 were generally fluent in C++, the skills they were sadly lacking were the general programming skills: abstraction, logical thought, program design, understanding the problem, debugging, reading compiler errors, etc. These are activities that are best learned when not frantically fighting against a deadline. Further, we want the students to learn to take care and pride in their work. Work that is done with an impending deadline is far less refined, and represents a much more superficial knowledge, and can in some case brew resentment against the instructors for forcing ``boring'' and ``pointless'' work on the students.

With these goals in mind, the following system was developed:

Over the course of the session, $20\%$ of the student course grade was allocated to ``programming points.'' At the end of the quarter, a total of 200 programming points were needed to earn the full $20\%$, meaning that each point was in actuality one tenth of a percentage in the final grade. Ten points were available for each lab assignment, with average student scores of between eight and ten for each assignment. The remaining 100 points for a perfect score were available through assignments, which were usually worth 20 points each<sup>B.1</sup>. Each assignment had a ``due date'', if the assignment was turned in on that date then it was graded out of the full point value. For each half-week (full week if this were a regular quarter course) early an assignment was submitted, the points possible rose by $10\%$^B.2 Similarly, for each half-week late, the points possible decreased by $10\%$, as the assignments were generally timed to coincide with expected knowledge and experience in the course.

At the end of the course, when it was becoming more obvious that many of the students did not have the programming proficiency that was required to be successful, I also introduced a set of programming ``Exercises'' worth a small number of points (about six to eight). These covered some basic CS 10/12 material, writing simple functions and composing them together to perform more complicated tasks. These were intended as a remedial step, not a substitute for performing the actual course work, and thus the number of these points for each student was capped at 25.

The result of this allocation of points was that the average student needed to attend all ten lectures and complete five assignments on time for an 'A+' score in that $20\%$ of the course grade. Actual behavior ranged wildly:

• One student attended only one lab, submitted five assignments an average of two weeks early, and did two of our practice exercises, for a total of 173 points (B- in lab, A+ in lecture, A overall)
• One student attended two labs, turned in no assignments or exercises, for a total of 22.2 points. (F in lab, F in lecture, F overall). This student's motives are highly puzzling (the student did take the final exam, and was seen in lecture throughout the term).
• One student attended all labs, but struggled mightily with assignments. After three weeks the student was still unable to complete any assignment. The student spent much of the next week completing four of the six exercises, and then was able to complete three assignments late. The student totaled 144 points. (C- in lab, C- in lecture, C- overall.) This student personally mentioned to me that without the point system, he would likely have dropped from CS entirely, this being his third attempt at CS 14.
• One student attended all labs, and completed all nine programming assignments an average of a half-week early^B.3, in addition to finishing one exercise. The student totaled a whopping 349 points. A+ in lab, A+ in lecture, A+ overall. This student also high-scored the midterm and several of the weekly quizzes.
• A fairly average student attended all of the labs, finished three assignments and two exercises for a total of 162 points. (B in lab, C in lecture, C overall.)
• A good, but not exceptional, student attended all of the labs, finished five assignments slightly late, completed one exercise, and earned a total of 174 points. (B in lab, A in lecture, A overall.)

Students evaluations of the point system are unanimously in favor, they value the ability to choose what to work on and to not have their schedules entirely dictated to them. Even the appearance of some form of choice in their education appealed to them. There were some complaints about the relative closeness of due-dates, which comes mostly from having twice as many possible assignments as required assignments. Students mentioned that it takes a little bit of adjustment to allow a deadline to go by without beginning an assignment. This could perhaps be lessened by introducing the system under different terminology^B.4 in the future.

Overall, the course average was nearly 3.72 assignments successfully completed per student -- submissions that were drastically incomplete were sent back for resubmission. This is statistically more than were completed during the Spring session of CS 14, which had four assignments of which one was drastically too difficult for the students, which caused the average student to fail that assignment with less than $40\%$ credit. This is approximately equal the Spring 2002 offering of CS 14, which also had four assignments, although the difficulty level of the Summer-Session assignments was a bit more challenging^B.5. In addition, the average student completed two to three additional exercises to help shore up gaps in their proficiency. The help that these really gave is probably negligible -- the real benefit of the exercises was in improved student morale and in my learning to write assignments of that type, which will hopefully be appearing in CS 10 and 12 in future offerings.

Through the early and mid section of the course, until about the $80\%$ mark, students were generally behind the expectation, and showed little sign of overcoming that inertia. During the last two weeks, and especially the last week, the lab was populated throughout every day with CS 14 students working on one assignment or another. The final days were a frenzy of activity, many students doubling their number of completed assignments. On one hand I regret this, as it means that those students were likely not putting in the time and effort to really work as craftsmen/craftswomen on their projects. On the other hand, I think it does demonstrate that a thirsty horse will eventually drink.

Final analysis of the point system shows that the student average was 172 points, of which 18 were from exercises, for a CS 14 total of 154 points: a $75\%$. The histogram distribution of the point totals approximates a normal reasonably well (difficult to be truly normal with only 22 measurements), requires no re-centering or rescaling, and gives the average student a solid C grade. Combined with $7\%$ of the course grade going to Style for producing good, readable code, and $8\%$ going to practical exams on which all non-cheaters should average eigth to ten; the average lab total was a B-.

Considering the makeup of the CS 14 summer section, which likely has more low-end students retaking the course than any other section proportionally, I find it difficult to interpret these results as anything less than successful.

One further note about the point system is its possible effects on cheating. When deadlines are not strict, there is greater chance for social pressures to cause cheating. One instance during this summer found a boyfriend turning in an assignment on time and a girlfriend failing toward the end of the quarter and resubmitting a modified version of the same assignment. The other noted instances of cheating this session (three of them) were all students resubmitting sample solutions of code from the previous quarter. This is something that we will have to address as our curriculum moves toward less variability from offering to offering, but hopefully enough publicity for those that are burned by it will reduce the rate of such occurrences.