« Sudoku Puzzles and Computer Science | Main | Audits of AP CS Courses »

Correctness and Finishedness

As a certified soft touch, I'm constantly running into the problem of students asking for extensions on their work. It is hard to deny a motivated student additional time to keep working on a problem rather than admitting to failure.

I think this may be more of a problem in CS than in other classes. In most classes, it is fairly straightforward to tell when a problem is finished and fairly difficult to know if it is correct without the answer key. In math, if I have an answer to the equation, I'm done, whether or not the answer is accurate. In humanities, I know if the paper has said what I have to say and whether I hit the page count, whether or not I was blowing hot air or completely wrong about the causes of WWII.

In CS, students have the golden test - does the program run? Until it will compile without errors and fulfill some approximation of the requirements, it is clearly not done. For a dedicated student who is used to working until the work is complete, it can be difficult to learn when to walk away, especially when the grade depends on the assignment. The difference between an overlooked missing semicolon and a significant logic error can be indistinguishable to a novice.

How can we better support our students in learning when to give up, when to persevere, and how much time to allot for assignments?

Michelle Friend Hutton
Equity Chair

Comments

Students need firm but fair time limits on all computer assignments. I battled this challenge for 20+ years. Here is the solution I finally arrived at:
Do the project you expect them to do. Then double the amount of time it took.
Be sure students have the prerequisite skills to do the project by giving a quiz before any major assignment is made.
Evaluate the time frame at what should be the midpoint. Adjust, if needed, only at this time juncture and only with good reason. Do not put it up for a vote. You are the boss. You set the rules.
On the due date, require students to submit what they have with any explanation of why it is not finished and require any additional work to be done in your lab before school hours for a maximum of of the credit yet to be earned for the job.

This policy, which must be strictly and firmly enforced for all students, provides a variety of real world services for them.
They will not have forever, in the real world, to complete work without dire consequences.
Force them to face the fact that a great deal of the delay is simply procrastination and poor time management.
Encourage them to pace their work with the mid-point check.
Illustrate a serious reality check by having to catch up at an inconvenient time called burning the midnight oil. When we make poor choices we suffer the consequences.

Other ideas to consider:
Perhaps the projects are too big or there are too many of them.
Break large projects into smaller parts and set a deadline for each part algorithm due one day, the window layout the next, the stub code the next, completed code the next and the documentation the last.
Instead of an all-or-nothing grade consider using a rubric that gives credit for the many components of a successful program. In this way a project that has only 1 small flaw in logic or syntax still can earn a reasonable grade for all of the other components.
Do more team projects that allow individuals to learn from others. Balance this with individual test scores and homework assignments. This is how work in the real world actually occurs.
Expect a great deal of resistance to this or any change in classroom procedures. It will take great stamina to let them know you mean business.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)