Soft, hard, and late deadlines (or another failed experiment)

Syllabus Setup

My full syllabus is on the class’s website. For some background, the content is organized around modules that are about one week’s worth of work. Each module has four pieces. Prepare is where students consume videos and reading materials and includes knowledge check quizzes. In class, they do a Group Worksheet that I create using just-in-time teaching where it only has concepts the students did poorly on in the knowledge check quizzes (Note: I’ve turned these into peer instructions after this semester). After the Group Worksheet, they start working on a Practice during and after class, which is basically homework that does not require a perfect score to receive full credit. They are also encouraged to work together on it. Finally, there is the Perform which must be done independently and confirms the students understand the material for that module. The Perform for a module was released one week into the following sprint. This was so that the Practice (hard due at the end of its learning sprint) could be graded and returned before they started working on the Perform.

Deadlines

I had three kinds of deadlines, though each modules pieces only had two of the three:

  • Soft deadline — If you didn’t make this deadline, it’s okay you are not late. These are for Prepares and Group Worksheets. The main natural consequence of not doing these on time is the in-class activities will not benefit the student as much.
  • Hard deadline — All module pieces had this deadline. This deadline needs to be met or the student is behind the intended cadence of the class.
  • Late deadline — This is the last date we would accept work on the Prepare, Practice, and Perform module pieces.
  • Soft due — Prepare A the day before the first day of class that week and Prepare B was the day before the second day.
  • Hard due — Originally, at the end of the sprint. After a few sprints, at the end of the first week of the sprint.
  • Late due — 24 hours after the hard due date.
  • Soft due — The day we used it in class.
  • Hard due — At the end of the first week of the sprint.
  • Late due — No late due date.
  • Soft due — Not applicable, though I strongly encouraged them to get at least one module’s Practice done by the end of the first week. Since there would be Performs from the prior learning sprint released during the learning sprint’s second week.
  • Hard due — At the end of the learning sprint.
  • Late due — One week after the hard due date.
  • Released — One week into the following learning sprint.
  • Soft due — Not applicable
  • Hard due — At the end of the learning sprint it was released.
  • Late due — One week after the hard due date.
Picture showing my students how the deadline system worked

Two Versions of Everything and NULLing Out Submissions

On top of all that, I added an extra complication. I created two versions of basically everything except the Group Worksheets. For the Prepares, there were versions for the soft and hard deadlines. For the Practices and Performs, there were versions for the hard and late deadlines. The titles clearly labeled them as one or the other and I thought this would “tap into” the student’s desire not to be late by clearly labeling when they were not on track.

What Happened in the End?

I’m sure anyone that has taught students can make some guesses on what happened. As I reflect, it is definitely the case I created a system that if I was a student would have had no problem following, but the system was excellent at differentiating students on their time management skills. Not in terms of their grades, but mainly in terms of when they submitted things.

Costs and Benefits

There were definitely costs that I thought were reasonable, but on reflection cost more than I thought:

  • Student confusion — This was definitely something I think I always underestimate because in my mind it’s “clearly obvious” because I came up with the system. But students were definitely confused. They submitted to the NULL form when they shouldn’t or didn’t submit when they should. They also asked questions about why they had a score in both versions of the assignment, even when they did the right thing (Gradescope doesn’t let us “retract” a submission so the score was a 0) plus the gradebook needed to have a score in both columns regardless of what a student did.
  • Extra work — I did extra work creating both versions. My TAs did extra creating both versions. I tried to compensate for the confusion by giving extensions, which sometimes resulted in me doing the grading since I didn’t want to keep asking my TAs to grade late stuff.
  • Tracking NULLing — This had a much higher cost than expected. Mainly because I didn’t expect so many students to submit to this form. On reflection, I should have known better.
  • Student flexibility — Many students appreciated it. I got emails from and had conversations with more students than ever before about how much they really appreciated that I was trying to be flexible.
  • But the caveat here is this system really only benefited the students that had time management skills. Those with poor/undeveloped time management skills were actually worse off in this system.
  • The late version was a good backup — Every assignment always had at least one student, and usually more, that made some mistake in their submission. It wasn’t fully run, it was the wrong file, etc. For those that submitted on time, this wasn’t an issue since we just told them we’ll NULL this on-time version out and they can just submit to the late version.

Conclusions

First and foremost, I’m never doing this kind of system again. I said never again after the semester was over and after writing this reflection I’m underlining that thought with multiple strokes of red ink. And if I even consider any of the elements I’m going to force myself to reread this reflection.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Kristin Stephens-Martinez

Kristin Stephens-Martinez

Assistant Professor of the Practice in Computer Science at Duke University