Carter, Janet

Efford, Nick

Jamieson, Stephan

Jenkins, Tony

White, Su

English

Kent Academic Repository

The TOPS Project – Teaching our Over-Performing Students  Janet Carter Computing Laboratory University of Kent Canterbury, CT2 7NF  J.E.Carter@kent.ac.uk  www.cs.kent.ac.uk/~jec  Nick Efford School of Computing University of Leeds Leeds, LS2 9JT  nde@comp.leeds.ac.uk  www.comp.leeds.ac.uk/nde/ Stephan Jamieson Department of CS University of Durham Durham, DH1 3LE  stephan.jamieson@durham.ac.uk  www.dur.ac.uk/alic/ Tony Jenkins School of Computing University of Leeds Leeds, LS2 9JT  tony@comp.leeds.ac.uk  www.comp.leeds.ac.uk/tony/ Su White School of Electronics & Computer Science University of Southampton Southampton, SO17 1BJ  saw@ecs.soton.ac.uk  users.ecs.soton.ac.uk/~saw/  ABSTRACT It would be unlikely for any first year programming class to be solely composed of novices.  We all have students with a range of abilities, and this generates challenges as to the best way in which to manage and teach the class.  The students at the top need to be enthused whilst we provide extra help to the students at the bottom, and try not to demotivate the ones in the middle.   This paper reports the outcome of a project aimed at enthusing the better programmers within the first year of a Computing degree programme.  The activity and judging process have been designed to retain student motivation and to value the integration of professional and technical skills.  Students and academics have evaluated the process.  Student achievements have been enhanced and the approach is seen as a useful addition to existing teaching methods. Keywords Top students, programming, enthusing students. INTRODUCTION First year programming classes are not solely composed of novices; typically students possess a range of prior experience.  This creates teaching issues relating to how to ensure the maximum benefit and engagement for each of the participants.  Maintaining motivation for both neophytes and the most experienced whilst ensuring that students receive a sound introduction to software engineering practices may be particularly difficult.   Stretching the most able students in order to ensure their development and continued motivation is a constant challenge in computer science education.  It is an area which would benefit from further consideration and greater understanding.  Various differentiated approaches to teaching have been developed and their implemented and evaluation has been analyzed and well documented [1, 2, 3, 4, 6].   This paper presents the outcomes of a collaborative initiative across four universities who have already implemented specific practice to accommodate the variety of student needs, but who wanted to further develop understanding and good practice in this important area.   The TOPS (teaching over-performing students) project was designed to incorporate sharing of current practice, peer observations across universities, collaborative problem setting and intra-university programming competitions as a means of extending the most able students in programming classes.  It is a collaboration between the Universities of Durham, Kent, Leeds and Southampton.  It builds upon existing activities which have been initiated through the HEA-ICS Southern Network, the Disciplinary Commons [4] and the HEA-ICS programming community.  Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission. © 2007 HE Academy for Information and Computer Sciences   OUR MOTIVATION Independent competitions, such as those run by the BCS, Microsoft and IBM [5] can be used to motivate students – winning looks good on the CV – but the challenge may not fit well with the local syllabus and student knowledge.  Activities which are designed in the specific context of an existing curriculum can therefore have greater educational strengths.  Furthermore, students can be encouraged to learn new skills and extend those that we consider important for their future educational career. Our Aims • To build a community of practice amongst academics working to address the needs of our most able students; • To produce a proof of concept activity which demonstrates effective methods for working with the most able students; • To identify useful future work, this can support academics in developing their most able students. What We Did The project comprised a series of face-to-face meetings augmented by email, peer observations and a student competition. The participating academics met twice prior to the competition.  The meetings were a mixture of operational detail and educational planning.  Not only was the competition to be fun, but it also had to address our departmental learning objectives. The peer observations facilitated the sharing of existing practice within its natural context and to facilitate reflection upon current practice and the inception of new ideas; it also enables a comparison of student cohorts.  Academics at each of the four institutions already have existing in-house schemes to cope with keeping the good programmers engaged whilst teaching the rest of the cohort.    THE COMPETITION Eight students from each of the four institutions were involved in the competition, which was split into two sections: designing a challenge for the other students to attempt in pairs; attempting the three challenges designed by students from the other institutions. Choosing the Teams Academics from each institution facilitated team selection in a manner which suited their particular group of students.  Durham students held a selection party and Kent students held a meeting during which they ultimately filled the last place on the team with a flip of a coin.  Teams comprised eight students, six of whom went to London; this allowed students with commitments or who were reticent about competing in the programming stage of the competition to join in, as well as allowing for drop-outs. What the Students had to do The competition had two strands.  The first was for each group of eight students to create a challenge for students from the other institutions to attempt in pairs.  The second strand involved a trip to London for some of the students in order to attempt the challenges created in the first strand.  Designing the Challenges The teams of eight students were given the brief to design a challenge that could be undertaken by a pair of students sharing a laptop, using Java and any development environment they felt comfortable with, within the timeframe of 1-hour.  The scenario for the challenge must be related to a group of students attending a Sun tech day in London.  The students were advised to consider previous assessments as a guide. The students were given one week to determine their particular interpretation of the scenario and devise an outline for a challenge; the academics needed to ensure that there weren’t going to be four versions of the same challenge.  The students then had two weeks to create the detailed challenge, word the challenge task document, to create any files required for the challenge and to create a mark scheme for the judges. The four challenges were all very different to each other.  The Leeds team created a debugging challenge. The Southampton team interpreted the brief very liberally and created a challenge relating to tamagotchi – working from the perspective of doing the sort of activities they covered in their basic Java but making it motivating, and using new technologies that may be available on the day.  The Durham team created a “6 degrees of separation” system which allows one to find who is linked to who and the nature of the relation – work, friendship, whatever.  The Kent challenge was to design a GPS tracking system:   “The scenario for this challenge revolves around a group of directionally challenged students trying not to get lost whilst attending a Sun tech day… ”  Attempting the Challenges Six students from each institution went to London to work on the challenges set by the teams from the other institutions; these students attempted each challenge in pairs with a time limit of 1 hour for each challenge.  The students worked with 1 laptop per pair, but many brought extra equipment just in case it was allowed or needed.  The start and end times for the challenges were denoted by the blowing of a  whistle.  Academics then copied student responses onto pen drives ready for marking.  The schedule for undertaking challenges is shown in figure 1.  Timetable: 1030 – 1045 Introduction 1045 – 1145 Challenge 1 1200 – 1300  Challenge 2 1300 – 1400  Lunch 1400 – 1500  Challenge 3 1500 – 1600  Judging 1600 – 1630  Prize giving  Team  Durham Kent Leeds Soton 1 K L S D 2 L S D K Challenge 3 S D K L Figure 1 – The order for the challenges Organizational Issues The venue for the event was Westminster Central Hall, as an activity taking place during a Sun tech day [7] on March 14th.  It was too far for Durham students to travel as a day trip, so they stayed overnight in a London youth hostel.  On the day the Kent, Southampton and Durham teams arrived in time to attend James Gosling’s keynote talk.  This gave academics time to set up the room and finalize preparations for the day.  Leeds students, with a long day trip, arrived just before the competition began.  Judging and prize-giving were undertaken by Sylvia Alexander (HEA-ICS manager) and Simon Ritter (Sun Technology Evangelist).  Marking, however, was undertaken by as many academics as were available.  Marks for each challenge were ranked and then the pair with the highest overall ranking was declared the winner.  The criteria for judging the best programming attempts were almost exclusively determined by the mark schemes created by the students designing the challenges.  The criteria for best challenge included: task most enjoyed by students; task best fitting the scenario; easiest mark scheme; as well as actual programming content. Photos from the event form figures 2-4. Challenges for the Academics Discussion of possible challenges revolved around a range of factors including syllabus (content and order), term lengths and dates, the exact timing of the competition date, individual academic’s teaching and academic commitments.  The peer observations helped with academic’s understandings of institutional differences.  The institutions were paired on the basis of geographical proximity: Kent and Southampton, Leeds and Durham.  Details of the curriculum, the syllabus and the typical teaching process and departmental ethos were shared and discussed.   The academics faced three objective tasks which related to the student competition.  1. To ensure that the student teams would construct viable and realistic challenges for the programming pairs; 2. To ensure that the challenges were appropriate for the level of expertise and prior learning; 3. To ensure that the challenges could realistically be attempted and potentially be completed within one hour. Allowing the students to create challenges that themselves were to be considered for prizes eliminated the urge to create something outside the specification.  You cannot win a prize if your challenge is inappropriate.  Marking was normalised rather than absolute to allow for variation.  EVALUATION The project did manage to meet its stated aims.  Through the peer observations the academics now have a greater understanding of the workings of their other partner institutions, and the students that attend them. The competition can be viewed as a success.  The students say that they enjoyed it and it has created interest amongst others at our institutions.  It also managed to stretch the top students in our programming classes without being detrimental to the others or affecting the syllabus and teaching schedules. What the Students Thought The students appeared to enjoy the day.  The atmosphere was particularly tense during the first challenge session, but once the students had settled into having to work intensively and collaboratively on something that was actually designed to stretch them they relaxed and the atmosphere became much calmer. Having teams of eight with only six going to London did initially cause concern, but because we stated this up front at the outset the students did not mind.  Indeed, at least one student participated that otherwise would not have been able to do so because she could not travel due to family commitments. Students were canvassed about their thoughts on the day and their comments were overwhelmingly positive: • Working together was great.  Everyone worked amazingly well in teams. • I liked that we were supposed to work at our  natural pace and that we had to think. • It was really intense, but great fun. • It’s great – thank you for organising it.  Logistical Issues There were a couple of issues that caused problems: trains and marking. Travel Issues There were some logistical issues that created problems.  One rail company’s pricing structures caused headaches for the budget.  This was a time-consuming nightmare causing meetings to be held in Peterborough rather than London, and students to have convoluted journeys – for example, Leeds students getting off their fast train to London at Peterborough and getting onto the next fast train to London 10 minutes later saved over £400.  It did not detract from the students’ enjoyment of their day in London, but was stressful and complex for the academics managing the budget. Marking Marking the challenge responses, however, was a more serious issue.  We did not fully appreciate the scale of the marking load.  It is much easier to mark work that one is familiar with and from students who know your expectations.  If the competition is to run in future years this is an issue which needs to be addressed.  Suggestions include being more prescriptive with challenge setting criteria, or even allowing a subset of challenge task types, but this would limit student creativity.  Another suggestion is to pay postgraduate markers to familiarise themselves with the challenge tasks and mark schemes beforehand, and then to mark the work. Suggestions for the Future The project was conceived as a pilot scheme to determine levels of interest and practicality of running such events for more students in the future.  The limited budget of a development fund grant would be problematic unless extra sponsorship can be found for prizes – we supplied the prizes for the team creating the best challenge.  The current format could extend to include up to 10 teams if we can sort the marking issue.   There has been a suggestion that we should also include stage 2 students in the competition.  Allowing students with an extra year of teaching to compete would create a level of inequality that might not be productive.  A competition for students that are all at the same point in their academic career seems much more motivational.  We will investigate the possibility of creating a second competition, or a separate strand, for students in their second year, but motivating the top students in their first programming course remains our primary goal.  ACKNOWLEDGMENTS The authors wish to thank: • HEA-ICS for the development fund grant that made the project possible; • Sun Microsystems for sponsoring the competition by providing the venue, catering, and prizes for the winning pair; • Sylvia Alexander and Simon Ritter for judging and awarding the prizes; • Essam Eliwa for helping with marking; • The students for participating. REFERENCES [1] Carter J and Boyle R, Teaching Delivery Issues: Lessons from Computer Science, Journal of Information Technology Education, vol. 1, pp. 77-89, 2002. [2] Carter J, English J, Ala-Mutka K, Dick M, Fone W, Fuller U, and Sheard J, How Shall We Assess This? ACM SIGCSE Bulletin, vol. 35, pp. 107-123, 2003. [3] Davis HC, Carr LA, Cooke EC and White SA, Managing Diversity: Experiences Teaching Programming Principles, presented at the 2nd LTSN-ICS Annual Conference, London, 2001. [4] Fincher S, Barnes DJ, Bibby P, Bown J, Bush, V, Campbell P, Cutts Q, Jamieson S, Jenkins T, Jones M, Kazakov D, Lancaster T, Ratcliffe M, Seisenberger M, Shinners-Kennedy D, Wagstaff C, White L, and Whyley C, Some Good Ideas from the Disciplinary Commons, presented at the 7th Annual Conference of the HE Academy Subject Centre for Information and Computer Science, Dublin, 2006.  [5] IBM Programming contest central, http://www-304.ibm.com/jct09002c/university/students/highschool/ [6] Kölling M, and Barnes DJ, Enhancing Apprentice-Based Learning of Java, presented at 35th SIGCSE technical symposium on computer science education, 2004 [7] Sun Microsystems, London tech days 07, http://uk.sun.com/sunnews/events/2007/mar/revolution/techdays07/index.html   PHOTOS OF THE COMPETITION DAY  Figure 2:  Students hard at work during one of the challenges   Figure 3:  Kent students winning the prize for “best challenge”   Figure 4:  The Southampton students who won the programming strand 

Enhancing Apprentice-Based Learning of Java, presented at 35 th SIGCSE technical symposium on computer science education,

Enhancing Apprentice-Based Learning of Java, presented at 35th SIGCSE technical symposium on computer science education,

How Shall We Assess This?

IBM Programming contest central,

London tech days 07, http://uk.sun.com/sunnews/events/2007/mar/rev olution/techdays07/index.html

Teaching Delivery Issues: Lessons from Computer Science,

The TOPS project - teaching our over-performing students

http://kar.kent.ac.uk/14551/1/The_TOPS_Project.pdf

The TOPS project - teaching our over-performing students

Abstract

Similar works

Full text

Available Versions

Kent Academic Repository