Resubmitting Projects

Question

How do y'all decide when to allow a student to resubmit an assignment rather than just taking a low grade?

I have 3 things that tend to pop up when projects get turned in.

Wrong Thing: Student turns in starter code, an earlier version of their project, or the entirely wrong files.

Wrong Files: I mostly teach Java and there are always a handful of students that turn in the .class files instead of .java files. It's not the same students each time, so I assume it's an honest mistake.

Cheating:: Yeah, there's always a few.

I teach high school and tend to allow resubmissions when it's clear that what they turned in doesn't match up with what they're capable of. But I think part of that may be from the pressure in high schools to not fail anyone.

I'm also asking more about larger scale projects and not just lab style assignments. Projects that might have a significant affect on their averages.

Answer 1

The cheating issue is real, and it caused me to rethink how I approached labs entirely. I think of them as learning laboratories now, and don't give them a tremendous weight in grades (though I do spend a huge amount of time grading them, as I grade during code interviews.)

If you want some context for my approach, I have previously outlined some of the ways that I think about lab work here, here, and here.

In general, though, I come to the grading with the expectation that there will be many rounds of refactoring.

This year, I started a new procedure, and it has worked very well for me and my students. It utilizes my school's SMS (we use PowerSchool, though I imagine that any online grading system would have similar functionality.)

At our first code interview for a lab, I walk through their code in depth with them, and ask them to explain their approach (big picture) to me verbally. If they start walking through their code like by line, I stop them and ask for "just an overview". They are allowed to look at their code as they talk, but I don't want a play by play. (Students who have trouble with this raise some potential red flags for cheating.)

I also create a wish-list of comments as I go. "It would be better if you...", or "This code is not clearly written because...". I notate all of these in the comment field for the lab's grade.

As the interview gets to an end, I put on my best unforgiving professor hat, and award a rather punitive grade. So now, the student hasa 33% (or some other vileness.)

Then, in the comments section of the grade, I put on my kindest professor hat, and imagine what grade I would give if they came back in week with all of the problems fixed. Students with better initial labs might wind up with higher grades here, but everyone has rather high grades available.(*) I also leave in the list of problems that should be fixed.

Now, the students have to come back to me with the problems all fixed to receive the higher grade. I can draw this proccess out as much as I want in order to ensure that my students produce beautiful, clean code. I don't change the grade to the higher one until the code is wonderful. (This may take several attempts.)

(*) - Not cheaters. If you work through my extremely forgiving system and still cheat, I will give you a zero for that section with no way to make it up.

Answer 2

Note: Like the OP, I teach high school. Some of the things I discuss may not be useful in a university setting.

Resubmissions are not a factor for me because I will take anything from any student at any time. And it must be correct. So they get 100%, or they get nothing. Wait before you shoot me.

Timing: When I assign an exercise (program), I let my students know when it is due. I create the assignment in the grade book with its due date but leave it blank (we use PowerSchool as well, mentioned in another answer). As the students complete exercises, I check them off on a paper checklist. When the due date for a particular exercise arrives, I transfer checkmarks from my list to the grade book. If the student has a check, they get the points. If they don't have a check, they get a zero.

To get a check, their code has to be correct. It must have the expected output. It must adhere to all coding conventions. And it must use the structure suggested in the assignment (e.g., a foreach loop instead of a bounded for loop). Of course, I allow for personal variation that is not blatantly incorrect. Coding is a creative process and each student develops their own style.

I use zeroes in the grade book because it creates a sense of urgency in most students. But the zero is just a place holder, a reminder that something is missing. The student may, at any time, turn in their missing items, up until exam day. I clearly communicate what the zeroes mean to both students and parents at the beginning of the semester. My students actually like this method and give me positive feedback about it.

I allow what some might call "late" work because not everyone works at the same pace. Some students are just going to struggle (and Carol Dweck suggests that the student who struggles may actually learn the material better in the long run than the student who gets it immediately). Not everyone has a wonderfully happy, supportive home life. Not everyone has a two-parent family. Not everyone feels accepted and affirmed at school. Not everyone is healthy all the time. I don't know what my students face when they leave my classroom. If they really want to do the work, I want to take it, no matter how long it takes them to complete it.

Do some students abuse this? I don't have many who try. Students who care about their grades will work diligently to get work in no matter when it was "due". Students who don't care weren't going to turn it in anyway, due date or not.

Even with this system, I would say 90% of my students turn in their work "on time".

Cheating: My best defense against shared code is my familiarity with each student's coding abilities and style (or lack thereof!). When not actively teaching, I am circulating the room, interacting with my students, watching what they are doing - not in a hawkish way, but in an interested, encouraging way - "oh, you decided to add graphics to the assignment, that's cool". This way I can watch progress, help with errors I see before the student gets completely off track or wastes a bunch of time, or notice a student go from blank screen to complete multi-page solution - still highlighted from the clipboard - within one circulation of the room ("hmmm, where'd that come from"?). I can also gain insight as to how and why they do things, become familiar with their coding style, and nip bad habits in the bud. When I first started teaching, I thought if they were coding quietly and there were no questions, I should just sit at my desk and ignore them. Not anymore! I stay engaged and give them my full attention the entire class time. They deserve it, and it really makes my job much easier in the long run.

(Honestly, a very good rolling chair helps with this. I have my lab set up so I can easily roll and achieve maximized, efficient coverage).

Checking code: I don't ask students to submit code electronically. I check code for assignments with the student at their computer. Meaning we scroll through it together, with me asking questions as I see fit. If it's good, they get a check. If it is not, I tell them what to fix (or guide them to it), and they call me back again for a re-check. This works for me because a) I'm familiar with the way they do things and can almost immediately tell if they are showing me code they didn't write; b) I'm an extremely fast reader; and c) I make sure I have written a solution myself ahead of time so I know what I'm looking for.

Note: If I really feel I need it, I already have an electronic copy of students' work because of the way our network is set up. Every student has a virtual drive. All student work is maintained on their virtual drive that only they can access when they are logged in at school. Yes they have a lab computer, but they are restricted from accessing the C:\ drive. Any projects they create (code or otherwise) are saved to the virtual drive.

Teachers can access all students' drives. So I can access each student's work from my own computer. If I have academic dishonesty suspicions, it is easy enough to compare time stamps or file sizes between or among students and determine if sharing has occurred. Johnnie was missing 10 projects yesterday, but now he has them all, and every folder was created at the same time (when he unzipped his friend's work)? Nada.

In summary, "resubmission" is not an issue for me. If my students did the work, and they want to give it to me, then I want to take it.

Answer 3

Remembering that your job is teaching, not grading, yes, you should allow resubmissions - you can even encourage them if you take the right approach.

Some of your problems can be easily solved. Assuming your students are submitting electronically, you can (fairly) easily write a script that watches the submission folder for incorrect things. You can have the script respond to the student about the issue so that they can resubmit before the deadline.

Another tactic is to have them simultaneously submit a printed version of the project. They are much less likely to submit the wrong thing this way and it gives you a way to guard against some kinds of cheating as well as many kinds of errors. I'm assuming that projects are at most tens of pages, not hundreds, of course.

Having a printed copy permits something even more creative. After you have marked and commented on their first submission, you can encourage them to improve it based on your feedback. You have a base line and a base grade. When a resubmission occurs, the student submits the original marked up (paper) version with your comments along with the new work. Any changes in the project can be required to be highlighted with a marker pen so that you can see what is new at a glance. You can give them additional points for the resubmission, though probably not "full marks" based on the second (or later) submission. My standard used to be that you could earn up to 90% of the marks lost for the first submission on rework.

With the printed copy, your first two problems go away. You can permit resubmissions of the electronic copies freely if you have the paper to prove the work. It provides an audit trail, even if you prefer to actually look at and/or execute the electronic copy.

This recognizes that students don't need to be "perfect" to do well. It encourages them to be reflective about their own work. It avoids endless arguments with some students over why you marked them down the first time, as they can correct with little penalty. For me, it was always win-win to do this. The highlighting of the rework also made it nearly painless for me, though I never tried it with more than about 50 students. Students would turn in their work in a folder that contained both the old and new work with changes marked and old comments included on the originals.

Answer 4

To thwart cheating, and also to give some leeway to honest mistakes, we select a few students "at random" and their grade isn't for what they turned in but for one-on-one explanation of what they turned in/should have done. I'm interested in them showing they know the stuff, if they copied it from elsewhere is secondary. The risk of getting asked to explain the hand in on short order makes them at least look over it.