Teaching Portfolio CS-1P Programming - Glasgow University - Quintin Cutts

Home
--- Introduction
--- Content Summary
--- Acknowledgements

Context
--- Teaching Philosophy
--- Institutional Context

Course Structure
--- Aims, Objectives, Content
--- Delivery Methods
--- Assessment

Reflection
--- Commenting on Content
--- Use of Voting Handsets
--- Laboratory Examination
--- Written Examination
--- Continuous Assessment
--- Overcoming Blocks

Outcomes
--- New course rationale
--- Personal learning

Continuous assessment

In the traditional sense of continuous summative assessment, we have none.

This development came from a reaction to the overwhelming mark-chasing attitude of most students, and the consequent issues around plagiarism when a student was unable to complete work because they weren't understanding the course.

Instead our students are formatively assessed on what they have completed. They have access to their tutor during tutorials and labs, and outside these times if they make the effort to contact him/her, and they receive written comments on their submitted work each fortnight.

The only carrot in place to encourage the students to do any coursework is that they must hand in at least 8 of the 10 assignments during the year. And this need be at a most basic level - virtually writing their name on the submission is enough. If they miss the hand-in, they've lost the opportunity to get any credit for that assignment - hence there is no perceived value in revisiting it if they are behind. It is the next one that is important now - always the next one, to ensure they get the required 8 hand-ins.

Whilst my initial aim was to remove the stress of continuous hurdles, I now believe that we are failing the students because we know that a newcomer to programming will not be able to pass the course without regular and significant effort. Further, the last thing that a student who is behind should be doing is struggling on to the next assignment. They need to retrace their steps and get the poorly understood work properly under their belt before attempting the more challenging work. This is all in the nature of every new bit of programming building on what has gone before.

A new assessment design is required that requires the students to put in a significant investment of time, but does not incorporate the stress of having the meet a regular hand-in deadline.

The crux of the issue here is that programming students all learn at different rates. By insisting on a regular hand-in point, with no opportunity to catch up if missed, we are requiring that all students can keep up with the pace set by those deadlines. If a weaker student were able to work at their own pace, attending regularly and submitting when ready, they might be able to get, say, 50% of the work successfully completed in the duration of the course, rather than missing the first few deadlines and almost inevitably dropping out.

Hence in the new course design, we will adopt a more flexible approach: attendance requirements, so that students are putting some work in; but a completion system that requires students to, say, complete at least 50% of the exercises, but at any pace they like. This caters for students who start late, who just aren't good programmers, who are ill mid way through the course, and so on.