Undergraduate computing courses inevitably include a high degree of regeneration in order to keep abreast of this rapidly changing field. Introductory programming modules in particular need to adapt to changing trends and languages. Until recently, the focus of debate within the Oxford Brookes University curriculum has therefore been on the course content, but since 2012 there has been a major change in the method of delivery through the introduction of a new apprenticeship model. This paper seeks to reflect on this, and other recent changes which have led to improved student engagement and results. The data is limited however, and so the results presented here are not conclusive.
The teaching of programming has attracted a lot of attention in the literature over the years and remains a challenging problem. Programming is a many-layered endeavor. At the most basic level the challenge is to understand the syntax and structure of a single programming language and to find a solution to a problem that can be expressed in terms of the structures of that language. So there is an immediate interplay between the nature of the problem to be solved and the structures of the programming language in which a solution has to be expressed. As the study of programming progresses, so too does the study of the nature of problems and algorithms for solving particular classes of problem (e.g. sorting problems). The student is led to consider whether, say, sorting is an aspect of the solution of a problem and if so what available algorithm (and code) might be the basis for the solution of this aspect of the problem. As students’ programming skills mature, issues about the elegance and efficiency of solutions arise (including considerations of the computational complexity of problems and algorithms) and also issues about style and expressing solutions in such a way that others can understand them and maintain and adapt them for their own purposes. This leads to questions about the generality of solutions and whether by generalizing a problem in some way the solution might be a better basis for future work. Then there is also the collaborative dimension to programming, the programmer as part of a team of programmers, the programmer as part of an interdisciplinary team, and management of the whole process of creating and maintaining software artefacts. There are hints here of why learning from a master can be a good model.
This paper is a reflection on changes that have taken place to the delivery of the teaching of programming at Oxford Brookes University to undergraduate students in recent years. Whilst efforts have been made to quantify the effects of these changes, inevitably the paper has a more subjective (anecdotal), rather than quantitative flavour as measurable like-for-like comparisons are not possible. Key changes have been made to the language taught and the way in which this is done – a transition from traditional point and talk modes to a so-called apprenticeship model (Vihavainen et al., 2011) in which concepts are introduced and practised as a co-operation between students and lecturers. Changes have also been made to module structures. The effects of these changes have been explored by looking at module average and pass-rate data
The structure of this paper is as follows. Some background information and related work in the study of the teaching of programming is first presented. The new methods introduced at Brookes are then described, including the curriculum changes that have taken place in the past six years and issues around reusability of teaching materials. This is followed by a summary of the available data. The paper concludes with a discussion of the issues arising from our experience and ways to take forward what has been gained from this approach and to address shortcomings.
Ever since universities began almost a millennium ago, the primary method of teaching has been traditional lectures in which students have a very passive role (Brockliss, 1996). Yet this form of instruction has endured criticism for many years by educational theorists who have highlighted the need for students to be actively involved in their learning (Piaget, 1926). The central flaw with lecturing as a teaching the method is captured by the following quotation (Miller, 1927), which is originally attributed to Edwin E. Slossen:
‘Lecturing is that mysterious process by means of which the contents of the note-book of the professor are transferred through the instrument of the fountain pen to the note-book of the student without passing through the mind of either.’
The problems are particularly acute in science, technology, engineering and mathematics (STEM) subjects in general and computing in particular, since much of the curriculum depends on problem solving and practical skills that need to be practised as they are acquired. This is not to say that there is no place at all for lecturing in such disciplines, but it may not be ideal for some modules, and this is supported by evidence drawn from broader studies of STEM subjects (Freeman et al., 2013). This study showed that:
- Students on active learning courses, who thereby engage in activities like reading, writing, or problem solving to help digest and analyse the content of the course, perform significantly better in assessments including formal examinations
- Students on traditional lecture courses are 1.5 times more likely to fail than students on courses with active learning
Active learning is also particularly beneficial to STEM students from deprived backgrounds and for female students in fields that are typically male-dominated (Haak et al., 2011, Lorenzo et al., 2006). It can have an impact on retention too. For example, one study showed that nearly twice the percentage of students changed course after the traditional course than an alternative one involving a particular active approach, called peer instruction (Watkins et al., 2013). In this method lectures are replaced by sessions based around short, conceptual, multiple-choice questions. The instructor starts with an overview and then students tackle the questions, which are supported by small group discussion and further explanation of the concepts if the students do badly on the questions.
An active technique for learning programming was introduced at Oxford Brookes University in 2012 to coincide with the launch of a new curriculum that was designed to improve student engagement and satisfaction. The change in teaching style was introduced in direct response to student feedback, which showed that the separation between teaching the concepts of programming in lectures and practising them in the practical classes had not been helpful. Extra-curricular activities were also introduced in line with research in computing teaching which has shown that students’ motivation to learn can be increased significantly by mixing academic instruction with practical professional experience (Fincher et al., 2013). So a new mode of delivery, called the apprenticeship model was adopted whereby the weekly lectures and practical classes were replaced by mixed front-of-class and hands-on based teaching within the same session. One fundamental difference between our approach and that used in the studies reviewed in (Freeman et al., 2013) for example is that all of the instructors involved in those studies implemented the chosen methods voluntarily. In the case of Oxford Brookes, the curriculum design team designated certain modules to use the apprenticeship model, and then organised the timetable in such a way as to facilitate the new teaching method. This strategy for change could therefore have failed if the staff affected by it had not engaged with the process, but instead the improvement in satisfaction among both staff and students has resulted in a very successful transformation. This corroborates research that suggests that the most effective change strategies work by changing the beliefs of the individuals involved through long-term intervention, rather than by developing best-practice teaching materials or making top-down policies (Henderson et al., 2011).
Apprenticeship models in teaching programming are not new, though it is true to say that adoption of such an approach is far from universal. The approach to be described in this paper was developed ab initio to address issues in the particular context of Oxford Brookes University, for example curriculum structure, student backgrounds (wide ranging from those with programming experience through school or hobby activities to those with no prior exposure to programming, and wide ranging backgrounds in mathematics), and an existing framework for allocating lecturers and practical assistants to course modules. The University of Helsinki have developed an apprenticeship model terms Extreme Apprenticeship (by analogy with Extreme Programming methodologies). (Vihavainen et al., 2011) Their work is based on a Cognitive Apprenticeship model which recognizes three phases to instruction: modelling – the student is given a conceptual model of a process and observes a master performing a programming task from start to finish, scaffolding – students are progressively given just enough information to enable them to complete a related task, and fading – the final stage in which the student can tackle a task alone and the scaffolding is no longer needed. The Extreme form of the model stresses the scaffolding stage. An initial paper described the method and results after one cohort of students and a second paper reviewed results after three years (Vihavainen et al., 2013). Their approach has also been extended to the teaching of mathematical logic (Rämö et al., 2014). There are parallels between their work and ours, though our context was different and in this paper we also expand on experience gained in the design of materials for the new courses and enabling staff to teach in this style.
A less extreme form of the apprenticeship model is found in the practice of live coding (Rubin, 2013) which supplements lecture-style presentations with problem-solving demonstrations, starting with a blank screen and ending with a working solution, attention being paid throughout to externalizing the thought processes involved in creating the solution. Rubin has reported the results of one experiment in this approach, which included live coding and control groups in the research design.
Transition to the apprentice model
The content of computing syllabus has been a long-standing topic of debate at Oxford Brookes, but until recently the discussion has focused upon which languages to teach, rather than how to teach them. Over the past fifteen years the introductory language of choice has changed from Modula 2 to Delphi, and then on to Alice (Cooper et al., 2000) before the settling on the current choice of Python, which is the main topic of the first programming module (8008 in Table 1). One of the difficulties has been the need to teach the same course to students studying on a variety of degree programmes, ranging from media and sound technology to computer science and software engineering.
The second programming module (8004/9 in Table 1) has undergone a similar evolution. It is compulsory for all computing students and introduces object-oriented programming. The language taught has also moved from Modula 2 to Delphi, and now Java. Students who entered the university before 2009 had a two-hour lecture per week followed by a one-hour practical session with two main courseworks. Students were not engaged with the module, did not attend the practical sessions and the pass rates were low. So in subsequent years the length of the practical classes was increased to two hours and weekly marking of code was introduced, the results of which contributed to the final mark. Students engaged much better with the module, attendance improved, and so did the pass rate. In 2012, there was a major change to the curriculum, both in terms of content and teaching methods as detailed below. The results of this change are detailed in Section 4.
Some key features of the new curriculum are listed below. Its introduction coincided with the adoption of a new virtual learning environment (VLE) by the University, which was useful in facilitating some improved automated feedback facilities such as online quizzes. Important changes to the curriculum included:
- A much stronger core of compulsory modules common to all computing courses to in order to clarify programme learning outcomes and also increase cohort identity.
- A longer and more rigorous introduction to programming: the previous series of three modules, culminating in Data Structures at the start of the second year was replaced by a chain of six compulsory modules, ending with Advanced Object Oriented Programming in the final year (see Table 1 below).
- A change of programming language: the previous sequence of Alice, following by Processing (Meada et al., 2007) and then Java was replaced by an introduction to fundamental programming concepts using Python, followed by four modules covering more advanced topics in Java.
- Entrance requirements were raised from A-level grades BCC to BBC.
- The introduction of the apprenticeship model to core programming modules, which has involved a substantial increase in the teaching resource on these modules. The teaching timetable at Oxford Brookes University is divided into three hour slots, where typically a two hour lecture is followed by multiple one hour practical classes or seminars, led by various tutors. In the new model, identical three hour sessions are run simultaneously with one staff member, and sometimes two, in a pooled computer room. During each session the tutor will introduce a concept to the whole group and then pause to give students the opportunity to try some related exercises on their own, or in pairs, in much the same way as they would have learnt skills previously in schools. As such, the apprenticeship model gives an explicit process by means of which the working knowledge of the tutor is imparted to the student. This mode of teaching is not used for all modules, but it is common to all core programming modules.
- Students receive weekly summative feedback from online quizzes on all introductory programming modules.
- Extra-curricular activities were introduced such as programming competitions, and participation in activities such as hackathons and Google days was encouraged through support of student societies.
With so many changes, including the addition of new modules and removal of old ones, it is difficult to make direct comparisons between student performance on the new curriculum and the old one. It is also not possible to attribute improvements to the apprenticeship model alone, but close inspection of the available data has shown some interesting characteristics from which we feel valid conclusions can be drawn. Table 1 below shows modules between which comparisons can be made, where each module has the module in the row above as a prerequisite.
|Old curriculum||New curriculum|
|8003 Programming the Virtual World||Alice Processing||4||8008 Modern Computer Technology||Python||4|
|8004 Programming with Objects||Java||4||8009 Introduction to Object Oriented Programming||Java||4|
|8026 Further Object Oriented Programming||5|
|8223Data Structures||Java||5||8223 Data Structures||Java||5|
|8186 Advanced Object Oriented Programming||Java||6||8186 Advanced Object Oriented Programming||Java||6|
Table 1: Compulsory Programming Modules
Note that module 8186 was optional in the old curriculum, but is now compulsory. This particular module is taken in the final year and so it does not form part of the current comparison since it has not yet been run in the new curriculum. Note also that 8008 is a double module, but only 75% of it is concerned with Python programming, the remainder consists of other computing fundamentals such as computer architecture and simple logic. The programming content has therefore only increased by 50% compared with module 8003 that 8008 replaces, but the language has changed from Alice and Processing to Python. Module 8026 was introduced to cover more advanced objected oriented concepts such as inheritance and overriding which had previously been squeezed into the Data Structures module 8223.
Apprenticeship model guidelines
The adoption of the apprenticeship model has been managed without too much “top down” direction. In accordance with this principle, no fixed definition of the model has been imposed on teaching staff. Instead a de facto interpretation is being allowed to emerge through practice, and through the discussion and sharing of experience at our weekly “pedagogic reflection” sessions, which all staff are encouraged to attend. At these sessions we have discussed guidelines for use of the model and, crucially, reasons why it might be appropriate to break those guidelines. The following guidelines have been presented for discussion at our meetings, although no consensus has emerged as to their value:
Guideline 1: Don’t talk for too long.
The three hours allocated for an apprenticeship teaching session should be divided up as illustrated in Figure 1 below. There are short periods of exposition, in which a teacher explains relevant theory and techniques. Each such exposition is followed by practical reinforcement, in which students undertake activities designed to guide them to a more concrete understanding of those theories and techniques. Typically the session ends with a relatively lengthy period of reinforcement, which is similar to a traditional practical session. The main reason for dividing the session in this way is that long lectures are less well retained by students than shorter expositions (Gibbs, 1981). It is therefore sensible to restrict periods of exposition to no more than twenty minutes, and to incorporate regular “changes of demand” – points where the students are asked to stop passively listening and do something (see examples in Figures 2 and 3). There are reasons why one might break this guideline. For example, it might be difficult to devise practical activities that will reinforce the theoretical material, but can still be done in a short period of time.
Figure 1: Apprenticeship teaching session
Figure 2: Example of exposition slide where student is asked to repeat code
Figure 3: Example of exposition followed by reinforcement exercise
Figure 4: Example of problem solving activity
Guideline 2: Save problem-solving activities until the final part of the session
Difficult problem-solving exercises should be saved for the final period of practical reinforcement. The earlier periods of reinforcement, which are sandwiched between “exposition” periods, should require the students to perform relatively straightforward activities. For example the students may be asked to implement programs that have been presented by the teacher (see Figure 2), convince themselves that these programs behave in the way that has been explained to them, and explore simple modifications to those programs (see Figure 3). The reason for the guideline is that, if students are set a difficult problem-solving task, it may be hard to decide when they should be asked to stop working on it. The more able students are likely to complete the task quickly, and will be impatient to move on to the next period of exposition, whilst the less able students may get stressed if they are asked to stop working before they have completed the exercise. This is less of a problem during the final period of practical reinforcement, because students who find an activity challenging can continue with it in their own time, without worrying that they are holding up the rest of the class. It may be sensible to break this guideline if you know that you have a relatively homogeneous class who will all complete an activity in roughly the same time (see Figure 4).
Guideline 3: Write teaching material so that it can easily be used by other teachers
The teaching material to be used in a session is usually written by one teacher and delivered by several colleagues, often in simultaneous sessions. This means that it is vital, when writing material, to make it readily intelligible to two different audiences: the students, and the teachers who deliver it. This is of particular importance if fellow teachers have limited time to prepare for a session and limited opportunity to customise teaching material. For example, when writing a slide presentation it should be made clear where a teacher is supposed to introduce a change of demand, and how he or she is meant to “talk around” any given slide. It may be desirable to break this guideline in order that a teacher can draw on his or her own research, or personal experience, or repertoire of humorous anecdotes, but this might pose insuperable problems if a session has to be delivered simultaneously by colleagues and so it should probably only done if the timetable can be arranged so that the material is delivered by the person who wrote it.
Guideline 4: Do not display anything other than lecture slides
In the exposition periods, the teacher should explain theoretical matters to students using a set of slides. It is tempting to break off from the slide presentation and launch a development tool such as NetBeans so as to give the students a “live” demonstration of a programming technique, or a tip on the use of the tool. Sometimes it actually makes sense to do this, but there are a number of disadvantages to such an approach. Firstly it can be inconsistent with guideline 3. If a session has to be presented simultaneously by several different teachers, then it can be difficult to arrange that live-coding is used in a consistent way in each session. Secondly, if the lecturer switches from one application to another, it can make the exposition hard to follow. Thirdly development tools are designed to be viewed on a desktop computer, not presented on a data projector, although this disadvantage can be mitigated by changing the resolution of the screen or the size of the fonts used. Fourthly, a live demonstration leaves no material that students can look back over if they have not understood the demonstration. The students can, of course, take notes, but if they have not understood the demonstration then those notes may be of little use. It may therefore be better to take screenshots illustrating how to use a development tool and incorporate them into a slide presentation.
This is probably the most controversial of the guidelines listed here, particularly as there is evidence that live coding can be an effective teaching tool (Rubin, 2013). Furthermore, if students ask unexpected questions during a session, live coding may be the most effective way of answering them. All the guidelines listed here should be broken when it is appropriate to do so, and this guideline may be the most frequently broken.
Guideline 5: Don’t use the apprentice model if it is not appropriate to do so.
As we have already mentioned, the apprentice model can be costly, because it requires more person-hours to deliver and requires access to rooms equipped for both lecturing and practical activities. This extra cost is only worth incurring if teaching in apprentice mode is felt to be more effective than a traditional approach. If it is more appropriate to deliver teaching material as a separate lecture and practical, then there is no point in losing the economy of scale that is achieved by delivering the lecture in a large hall, so that all students can attend in the same place and at the same time.
Changes to teaching material
In recent years, a significant amount of research has been devoted to the problem of creating teaching resources that can be shared and reused between individuals and institutions. Much of this research has focussed on the development of relatively small reusable learning objects (RLOs) (Downes, 2003). Although reusability of teaching material was not a specific concern when introducing the apprenticeship model to Brookes, and although we did not aim at producing RLOs, it is possible to argue that the way in which the model has been adopted at Brookes, implicitly encourages the development of reusable material. Firstly the practical arrangements for teaching in apprenticeship mode make it essential to produce material that can easily be shared between, and delivered by different individuals, because timetabling constraints often mean that it has to be delivered that way. In the Brookes implementation of the model identical three hour sessions are run simultaneously, each session is run by a different teacher, with a different small group of students. This means that teaching material has to be developed so as to be easily useable by people other than its original author. Secondly the structure of the teaching material tends to consist of relatively short sections in which the teacher gives a brief exposition of some particular aspect of the subject being studied, and the students then undertake practical exercises to reinforce their understanding of the material explained. Each of these short sections, of necessity, revolves around a relatively limited set of learning objectives, and it is easy for anyone examining the material to determine what these objectives are because they are made explicit by the exercises that accompany them.
In practice reusability of teaching material is of enormous importance, because it is highly likely that, at some point in time, it will be necessary for teaching material written by one person for use in one module to be used by another person on another module. This repurposing and transfer of teaching material typically happens as teaching staff move on to other institutions, or other modules, or when courses are restructured so that the same general learning objectives get delivered in a different set of modules. Most teaching staff will have faced the problem of inheriting teaching material from a colleague, and having to decide how to deliver that material, possibly in a slightly different context. We would argue that teaching material designed for apprenticeship teaching make this process much less troublesome, error-prone, and time-consuming.
It is not possible to analyse a full set of data because the new curriculum has only been in place for two years, and so a full cycle has not yet been completed. However, the tables that follow can be used to compare average marks and pass rates of some first and second year modules. Additional performance metrics that were considered include student satisfaction, as determined from module feedback forms, and staff satisfaction, derived from unstructured interviews. Retention rates have not been considered here, and neither has demographic data such as gender or socio-economic environment.
The tables that follow show the progression of average marks and pass rates on the core modules listed in Table 1, over a period of up to six years (depending on available data). The data presented in these tables includes students on all computing fields, but a more refined comparison, by individual field is given in Section 4.5. The computing fields from which this data was gathered are as follows:
- Computer Science
- Software Engineering
- Network Computing
- Information Technology Management for Business
The first two programming modules have been compulsory for all of these fields during the time period under consideration, but the status of the subsequent modules changed in 2012. The department did run two other degrees during this time but the number of students on them was too small to make the sample worth including. These were:
- Computer Games and Animation
- Mobile Computing
The chart below shows the average marks on these modules over the past six years for students on the Computer Science and Software Engineering degree programmes
First programming module
The table below shows the statistics across all fields for the first programming module that the students undertake, and includes an indication of when the module content changed from 8003 to 8008.
|Pass rate (%)||76||79||85||90||90||89|
|Average mark (%)||51||53||51||54||62||67|
This table shows a general upwards trend in performance measured both by pass rate and average mark. So students appear to be coping very well with the increase in technical content by moving from Alice to Python, which may be attributable to the apprenticeship model and other changes that were designed to improve engagement. Module feedback shows that students are also more satisfied with the new module because they feel that they are learning a language that is of genuine use in industry, as opposed to a mere teaching tool.
Second programming module
The table below shows the statistics across all fields for the second programming module which covers object-oriented programming.
|Pass rate (%)||66||80||82||77||79||77|
|Average mark (%)||48||58||53||60||54||56|
The content of the two modules 8004 and 8009 is similar, but the latter was extended to include some additional topics such as inheritance and polymorphism. Another difference is that 8009 is taught using the apprenticeship model and students come in to the module with improved programming skills having previously undertaken a double programming module in Python, and a single module on the use of software development environments.
The table shows an improvement from 2009 onwards, which was the point at which the length of the practical classes was doubled to two hours, and weekly marking of exercises was introduced. All of the subsequent results are fairly consistent, which shows that students were able to manage the expanded syllabus of 8009, perhaps because of the change in teaching mode to the apprenticeship model. Student engagement has improved since 2012 too with the levels of attendance and engagement in classes significantly better than before, and satisfaction levels have increased.
A more refined analysis, separated by field is included in the appendix. This shows that students on degree programmes that are less focused on programming, such as Information Technology Management for Business do appear to be struggling with 8009, but then the corresponding data for 8004 shows that they have never performed well at this level. One advantage of the apprenticeship model is that it would be relatively easy to treat this group of students entirely separately from the rest and offer increased support or a lower pace of teaching.
Third programming module
The third programming module introduces data structures (8223). The content of this module has not changed but the delivery mode has been altered in a similar way to its predecessors.
|Pass rate (%)||73||77||92||90||97|
|Average mark (%)||50||59||59||65||74|
Average marks and pass rates for the data structures module have been increasing year on year. The improvement over the past two years may be a result of students being better prepared by the longer prerequisite chain, but the results are not conclusive. The data structures module is a transitional module, which begins the move away from the apprenticeship style, which is only used for some concepts on this module, since a longer, lecture-style exposition is needed for some of the more advanced ideas.
Final programming module
The last programming module covers advanced object oriented programming (8186). This module was optional until 2012 when it became compulsory for the two largest fields: Computer Science and Software Engineering. The first run of this module for students who have come through the new curriculum has not yet occurred.
|Pass rate (%)||76||52||89||79|
|Average mark (%)||55||39||55||54|
This module has had the worst results in the past in the sense of average marks. It is too soon to see whether this will change with the new curriculum, and it is possible that the performance may even deteriorate since this module is no longer optional, but it is hoped that the average marks will start to improve as a result of the more robust preparation for this module.
Analysis by field
The results described in the previous sections miss some important characteristics that can be observed by considering separate fields independently. These features were analysed using a visualization technique called parallel coordinates to help gain insight into patterns within the data collected, both average marks and pass rates, for cohorts of students in different years. The idea behind parallel coordinates, attributed to Alfred Inselberg, (Inselberg, 1985; Inselberg, 2009) is to regard multivariate data as a data point in a high dimensional space. Treating the average marks for a cohort of students in each module of a set of modules in this way means that the data are represented by a point in a space in which there is one dimension (coordinate axis) per module. In parallel coordinates the axes are represented as a set of parallel vertical lines, one per axis. A data point is represented as a polyline connecting the values of the coordinates of the point. The visualizations used for the analysis were interactive, so one could selectively add and remove different cohorts of students and mouse over lines to highlight the results for a given cohort. The figures attached to this paper are necessarily non-interactive. One slight complication for these datasets is that not all cohorts of students took the same set of modules, which leads to polylines crossing axes for which there is no coordinate value. Such crossings are represented here as gaps in the polyline.
The charts in the appendix show the parallel coordinates for the average marks and pass rates for two groups of subjects. The field of Information Technology Management for Business is considered in isolation because it is quite different from the other fields in the sense that half of the degree consists of Business modules. The results from the two fields Computer Science and Software Engineering are combined because there is a large overlap between the content of these two fields. The results from remaining fields are omitted due to small sample size.
Apart from module 8186, which has not yet been taken by students on the new curriculum, the results for all of the programming modules for Computer Science and Software Engineering are fairly constant. This is consistent with the tables in Section 4, which is no surprise since this body of students form the majority of the total group of computing students. What is noticeable is the difference for students on Information Technology Management for Business however. The results for 8008 are relatively strong: the pass rate has only dropped slightly from 8003 for example, even though 8008 is the module for which the technical content has increased the most. The results for 8009 are not so good though, and this is consistent with those of its predecessor 8004. This suggests that this group of students should be given extra support in future: something that is easily arranged within the apprenticeship model.
The data presented here is rather sparse since the new curriculum only began two years ago and the final module in the chain has not yet been run. So the first impressions presented above show a preliminary analysis rather than a fully controlled study, which is also difficult to conduct due to the multiple changes that have occurred. We can however observe that there has been an increased level of engagement among students on all the degree programmes, as evidenced by improved attendance and higher confidence with programming tasks. Students are also becoming less tolerant of traditional lecturing methods and have begun to complain when modules are not taught using the apprenticeship model. Staff have enjoyed the switch to the new mode of teaching which was imposed upon them, and the results show that the performance of students has not deteriorated despite the increase in content and technical depth. The true test will come when the results from the final module in the sequence (8186) are available, but we are optimistic that they will show some improvement.
The change to a more active learning mode seems like such an obvious improvement to the educational experience that it prompts the question: why did we not do it before? The most obvious reason is cost: the teaching resource required for the apprenticeship model is a lot greater than for traditional methods. There are other difficulties too, for example, the quality of tutors needs to be high, so Phd students who would have worked on practical classes in the past may not make suitable tutors in the new mode. Another major concern is the lack of suitable teaching spaces: most of the pooled computer rooms currently have a maximum capacity of 20 students, which offers another challenge to the economic viability of this method. It can also be difficult to accommodate different learning styles and speeds. However it may be that, in the long run, the increased reusability of teaching material yields savings that may compensate for the additional staff costs.
The optimal scope of the model is still an open question: it is certainly very flexible and has been implemented beyond the undergraduate curriculum. For example, some postgraduate modules have used it and also some outreach activities, but it is not suitable for everything and the benefits of wider deployment need to be weighed against the cost. This decision will form part of the future refinement which will also consider the best way to solve problems like the poor performance of particular subject groups.
Brockliss, L. (1996) Curricula. A History of the University in Europe. Ed. De Ridder Symoens, H. Cambridge University Press, UK. Vol II pp 565-620.
Cooper, S. Dann, W. and Pausch, R. (2000). Alice: a 3-D tool for introductory programming concepts. J. Comput. Sci. Coll. 15, pp 107-116.
Downes, S. (2003) Design and Reusability of Learning Objects in an Academic Context: A New Economy of Education? in USDLA Journal Volume 17, Number 1, online Jan 17, 2003.
Fincher, S. and Knox, D. (2013) The Porous Classroom: Professional Practices in the Computing Curriculum The Computer. Vol. 46, No. 9, pp 44-51, IEEE Computer Society.
Freeman, S. , Eddy, S. L., McDonough, M., Smith, M. K., Okoroafor, N., Jordt, H. and Wenderoth, M. P. (2014) Active learning increases student performance in science, engineering and mathematics. Proceedings of the National Academy of Sciences doi:10.1073/pnas.1319030111 Gibbs, G. (1981) Twenty terrible reasons for lecturing, SCED Occasional Paper No. 8, Birmingham.
Haak, D. C., HilleRisLambers, J. Pitre, E. and Freeman, S. (2011) Increased structure and active learning reduce the achievement gap in introductory biology. Science 332(6034): 1213-1216. Henderson, C., Beach, A. Finkelstein, N. (2011) Facilitating Change in Undergraduate STEM Instructional Practices: An Analytic Review of the Literature. J Res Sci Teach 48(8):952-984.
Inselberg, A. (1985). The plane with parallel coordinates. The Visual Computer 1, 2 (1985), 69–91.
Inselberg, A. (2009). Parallel Coordinates: Visual Multidimensional Geometry and Its Applications, Springer-Verlag, ISBN13 978-0470856185
Lorenzo, M., Crouch, C. H. and Mazur, E. (2006) Reducing the gender gap in the classroom. Am J Phys 74(2):118-122. Maeda, J., Reas, C. and Fry, B. (2007) Processing: A Programming Handbook for Visual Designers and Artists. MIT Press.
Miller, H.L. (1927) Creative Learning and Teaching, Charles Scribner’s Sons, New York.
Piaget, J. (1926) The Language and Thought of the Child. Harcourt Brace, New York.
Rämö, J. and Vikberg, T. (2014) Extreme Apprenticeship – Engaging undergraduate students on a mathematics course. Proceedings of the Frontiers in Mathematics and Science Education Research Conference, 1-3 May 2014, Famagusta, North Cyprus
Rubin, M. J. (2013) The effectiveness of live-coding to teach introductory programming. In Proceeding of the 44th ACM technical symposium on Computer science education (SIGCSE ’13). ACM, NY, USA, 651-656. doi:10.1145/2445196.2445388
Vihavainen, A., Paksula, M. and Luukkainen., M. (2011) Extreme apprenticeship method in teaching programming for beginners. In Proceedings of the 42nd ACM technical symposium on Computer science education (SIGCSE ’11). ACM, NY, USA, 93-98. doi:10.1145/1953163.1953196
Vihavainen, A.; Luukkainen, M., (2013) Results from a Three-Year Transition to the Extreme Apprenticeship Method, Advanced Learning Technologies (ICALT), Proc. IEEE 13th International Conference , pp.336,340, 15-18 July 2013; doi: 10.1109/ICALT.2013.104
Watkins, J. and Mazur, E. (2013) Retaining Students in Science, Technology, Engineering and Mathematics (STEM) Majors, Journal of College Science Teaching, Vol. 42, No. 5.