# Resubmitting Projects

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.

• This is somewhat related to cseducators.stackexchange.com/questions/4410/…, though not exactly the same. Apr 6 '18 at 16:38
• You can look at time stamps, especially on school computers, on code they forgot to submit, to make sure it was really an honest mistake. (I don't know how hard it is to fake time stamps on personal computers.) Apr 6 '18 at 19:47
• @EllenSpertus It's about as easy to "adjust" the clock on a personal computer as it is to adjust the alarm clock on the dresser. Timestamps from other controlled hardware is useless, and even from school controlled is sometimes questionable. Apr 8 '18 at 17:35
• If this is for larger projects as you say, then why not have multiple submissions as part of the project completion process? Peer code reviews, you do the final review, students get one more submission if they want when you are done.... Apr 16 '18 at 18:39

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.

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.

• What you are talking about sounds a lot like Competency-Based Education. Is that what you are intending to do? Apr 9 '18 at 22:37
• @RobertColumbia, that certainly sounds like what I am describing (after looking up the definition), although I wasn't aware of the term. Apr 9 '18 at 23:16
• Two of the principles that often define Competency-Based Education are an ability to resubmit work (or turn in work late) with a (perhaps corresponding) increase in the quality of work required. Instead of allowing students to squeak by with a C- or even lower on a few assignments, students are required to get an A (or sometimes an A or a B) on everything, but have extended opportunities to try and retry to get that A or B. Apr 9 '18 at 23:26

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.

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.

• I think you need to be especially careful here to account for personality. An extremely introverted person might not do well in such an examination, even having contributed to (or created) the work. For group projects I used a (conceptually) related idea. Every project (or a subset if the class was too large) did a presentation of results to the class. Everyone on the team had to take a turn in the spotlight. It pretty much guaranteed that those who contributed less were forced to learn what the team did. Some folks (extreme stutterers, for example) found it hard, but doable. Aug 3 '18 at 12:55
• @Buffy, you are absolutely right. But, on the other hand, for such people it is even more important to overcome such, and this is useful training. Aug 3 '18 at 13:16
• As long as you are sensitive to the issue and account for it all is good. I just point it out as a caveat. Aug 3 '18 at 13:18
• @Buffy, here (informatics engineering at a technical university) we alone (among some dozen of specialities) get 40% of the freshmen with autistic spectrum disorder. We are acutely aware of the problem. Aug 3 '18 at 13:22
• My caveat wasn't for you, actually, but for future readers. Not everyone will notice the issue, so I raised it. That is a fairly common practice here since the site isn't intended just for the benefit of the asker of the question, but for future visitors with similar concerns and issues. Hopefully, someone will read this in 4-5 years and still be able to take something from it. Aug 3 '18 at 13:29