Background

It is generally accepted that it is difficult to learn how to program (Bellström & Thorén, 2009; McCracken, Almstrum, Diaz, Guzdial, Hagan, Kolikant, Laxer, Thomas, Utting & Wilusz, 2001; Pane, Ratanamahatana & Myers, 2001; Robins, Rountree & Rountree, 2003). As a result, the pass rate for students taking first-year programming courses, in general, is low, with a high drop-out rate. At the same time, there are also a high number of distinctions, thereby creating a bimodal results distribution (Bornat, Dehnadi & Simon, 2008; Corney, 2009; McCracken et al., 2001; Robins, 2010). Unisa is no exception in this regard, as the pass rate for the introductory programming module at Unisa, COS1511 (Introduction to Programming I), from 2011 to 2014 varies from 28% to 32%, while the number of distinctions at the same time varies from 8% to 14% (see Table 1.1). Being an open distance learning (ODL) institution may even exacerbate this situation, given the fact that students have to study independently, without face-to-face support.

In contrast with the above, two independent studies claim that the average pass rate for introductory programming courses worldwide is 67% (Bennedsen & Caspersen, 2007; Watson & Li, 2014), although pass rates may vary considerably – from 23.1% to 96% (Watson & Li, 2014). Nevertheless, literature shows that the teaching of programming remains a continuous field of investigation

(Morgan, Sheard, Butler, Falkner, Simon & Weerasinghe, 2015). Researchers attempt both to determine the reasons for the perceived bimodal phenomenon as well as to remedy it. This leads, to Table 1.1 Registration, pass rate, distinctions and dropout for COS1511 from 2011 to 2014, as obtained from Unisa’s Directorate Information and Analysis (DIA) (Nyalungu, 20 March 2015; Van Zyl, 15 March 2015). Exam Year Sitting Registration Module Count*** Examination Sitting Admitted Normal Wrote* Normal Pass* Normal* Pass Rate Percentage (Passed /written %) Number of Distinctions (Percentage of written in brackets)** Dropout *** Dropout rate (Dropout / Enrollment %) 2011 Jun 2381 2183 1923 549 28.5% 198 (10%) 458 19.2% 2011 Nov 1457 1197 1191 346 29.1% 111 (9%) 266 18.3% 2012 Jun 2213 2061 1827 582 31.9% 197 (11%) 386 17.4% 2012 Nov 1528 1417 1267 352 27.8% 106 (8%) 261 17.1% 2013 Jun 1180 1083 988 337 34.1% 138 (14%) 192 16.2% 2013 Nov 1145 1020 920 276 30.0% 83 (9%) 225 19.7% 2014 Jun 976 889 809 258 31.9% 101 (13%) 167 17.1% 2014 Nov 1054 1017 894 263 29.4% 78 (9%) 160 15.1%

(Legend: * – The term ‘Normal’ refers to students who were registered for the specific semester.

** – The percentage of students who wrote the examination and obtained distinctions appears in brackets after the number of distinctions.

*** – ‘Dropout’ refers to students who were registered at the end of the semester but did not write the examination. It does not include cancellations, which will raise the dropout rate considerably when taken into account.) Similarly, ‘Registration Module Count’ indicates the number of students still registered by the end of the semester and therefore excludes cancellations.

research being conducted inter alia on programming ability or aptitude; teaching and learning theories and models; teaching, learning and assessment tools and techniques; the curriculum and typical problems first-year programming students experience (Dale, 2006; Kinnunen, McCartney, Murphy & Thomas, 2007; Lahtinen, Ala-Mutka & Järvinen, 2005; Lister, Adams, Fitzgerald, Fone, Hamer, Lindholm, McCartney, Moström, Sanders, Seppälä, Simon & Thomas, 2004; Milne & Rowe, 2002; Robins et al., 2003; Sheard, Simon, Hamilton & Lonnberg, 2009; Simon, Carbone, Raadt, Lister, Hamilton & Sheard, 2008). Judging by the variety of factors investigated in this research and its results, the cause of the bimodal results distribution is probably over-determined, that is, influenced by several factors (Sheard, Simon et al. 2009).

In an attempt to explain this phenomenon, Robins (2010:58) suggests a new mechanism, referred to as learning edge momentum (LEM). The learning edge is “the boundaries of existing knowledge which form the context into which newly learned concepts (information, understanding and skills) must be integrated”. Over time, the consequences of either successful or unsuccessful learning becomes self- reinforcing, since any successful learning in a specific domain makes it easier to some extent, to acquire further related concepts from that domain, while unsuccessful learning has the opposite effect. Robins (2010) also investigated the well-known assumption that there are two different groups of people, those who can program and those who cannot. He found no convincing evidence to support this premise, and therefore proposes that both the high drop-out and bi-modal results distribution in introductory computer science courses, are due to the nature of the subject material concerned. To improve the pass rate and lower the drop-out rate, effective teaching and learning during the initial stages of first-year programming courses, should take advantage of the LEM mechanism to achieve a better through-put rate (Robins, 2010).

Two aspects employed to improve the success of novice programmers, both related to this study, namely visualization and tracing, are discussed below as well as the researcher’s experiences while teaching introductory programming.

1.2.1 Visualization to enhance comprehension

Visualization is one of the methods used by computer science educators to assist students in mastering programming concepts. Software visualization (SV) in particular, aims to demonstrate different elements of software graphically, so that users can comprehend and reason about it (Petre & Quincey, 2006). This may take on the form of either AV or PV. AV demonstrates the high-level operations of an algorithm to assist understanding of its procedural behaviour (Hundhausen, Douglas & Stasko, 2002). PV shows the effect of each operation in implemented code (Röβling, Malmi, Clancy, Joy, Kerren, Korhonen, Moreno, Naps, Oechsle, Radenski, Ross & Velazquez-Iturbide, 2008). PV also facilitates program comprehension and debugging (Helminen & Malmi, 2010).

The success of SV is debatable. It is for instance, not always pedagogically successful (Foutsitzis & Demetriadis, 2008; Hundhausen et al., 2002; Lahtinen, 2008; Naps, Röβling, Almstrum, Dann, Fleischer, Hundhausen, Korhonen, Malmi, McNally, Rodger & Velázquez-Iturbide, 2003; Pears, Seidman, Malmi, Mannila, Adams, Bennedsen, Devlin & Paterson, 2007; Shaffer, Cooper & Edwards, 2007). Responses about the situations in which PVs are useful are also ambiguous – students may use PVs while studying, but claim they are most beneficial when presented by a teacher (Lahtinen, Jarvinen & Melakoski-Vistbacka, 2007). On the other hand, the literature indicates that individual engagement is essential to benefit from visualization (Isohanni & Knobelsdorf, 2011; Kaila, Rajala, Laakso & Salakoski, 2009). Depending on the level of engagement with visualization, it

can improve knowledge acquisition, attitude and programming skills (Urquiza-Fuentes & Velázquez- Iturbide, 2009a).

A significant number of SVs have been developed, but they are rarely used by teachers or lecturers other than the developers themselves. While instructors may agree that visualizations can help students, they are frequently not sufficiently convinced of its value to use it. They cite reasons for not using it, such as the difficulty and lack of time to adapt and maintain the visualization according to the courseware used at the institution (Ben-Bassat Levy & Ben-Ari, 2007; Domingue, 2002; Hundhausen & Brown, 2007; Naps, Röβling et al., 2003; Pears, East, McCartney, Ratcliffe, Stamouli, Berglund, Kinnunen, Moström, Schulte & Eckerdal, 2007; Röβling et al., 2008). According to Shaffer, Cooper, Alon, Akbar, Stewart, Ponce and Edwards (2010:9:18), “much of AV development seems to occur in a social vacuum”, since despite larger developers communicating with each other, smaller developers do not seem to be aware of the results of studies on the effectiveness of visualizations.

1.2.2 Tracing

Research has shown that students need to be able to read (that is trace) and explain code to be capable to write code (Lister, Clear, Simon, Bouvier, Carter, Eckerdal, Jacková, Lopez, McCartney, Robbins, Seppälä & Thompson, 2010; Lopez, Whalley, Robbins & Lister, 2008; Philpott, Robbins & Whalley, 2007; Rountree, Rountree, Robins & Hannah, 2005; Sheard, Carbone, Lister, Simon, Thompson & Whalley, 2008; Venables, Tan & Lister, 2009). Soloway (1986:857) pointed out this requirement in 1986 already, by stating that “designers and maintainers who did not carry out simulations did not develop an effective design or an effective enhancement”.

The BRACElet project’s1 research (Clear, Philpott & Robbins, 2009; Lister et al., 2004; Lister et al., 2010; Whalley & Lister, 2009) suggests that novice programmers develop these skills in a hierarchical order, as follows: They first learn to read, that is trace, code. Once this ability becomes dependable, they develop the skill to explain code. When students are reasonably adept at both reading and explaining, the capacity to systematically write code develops. The skills in this hierarchy are not necessarily acquired in a strict order, but instead support each other and improve in parallel. However, a certain minimal competency at tracing and explaining is required, before a minimal competence to systematically write code is displayed (Lister et al., 2010; Lister, Fidge & Teague, 2009; Venables et al., 2009; Whalley & Lister, 2009).

Cogan and Gurwitz (2009) indicated that teaching students memory tracing (tracking the changes in values of all variables on paper during program execution) early in their introductory programming courses, improved the pass rate rate. Hertz and Jump (2013) report similar results. This seems to

1

confirm both BRACElet’s findings (Lister et al., 2009; Venables et al., 2009) and the LEM effect (Robins, 2010).

Calls for teaching students manual memory tracing (Lister, 2007; Lister et al., 2004; Lister et al., 2009; Soloway, 1986) are supported by the benefits of doing so. Manual memory tracing teaches students to focus on understanding the detail of what their programs actually do (Cogan & Gurwitz, 2009; Lister et al., 2004; Lister et al., 2009; McCracken et al., 2001; Perkins, Hancock, Hobbs, Martin & Simmons, 1989). This allows them to create a mental model of the program and to predict its behaviour (Robins et al., 2003), which in turn assists in avoiding errors and finding them more quickly (Cogan & Gurwitz, 2009). It also serves a motivational role by breaking down the initial technical and emotional barriers to the complicated process of creating correct code, while better preparing them to understand more difficult algorithms (Cogan & Gurwitz, 2009). This encourages them to continue doing so (Thomas, Ratcliffe & Thomasson, 2004).

In the light of the above, it is clear that in an ODL environment such as Unisa, where students usually have to study without physical contact with lecturers or fellow students, the ability to trace in order to analyze and debug programs, therefore is all the more important. Furthermore, manual tracing is an important debugging skill. Therefore this is important in writing code too, especially when maintaining programs written by others.

1.2.3 Experiences while teaching introductory programming

In the introductory programming course at Unisa, COS1511, memory tracing is taught by means of static variable diagrams. While explaining these static variable diagrams to students during individual consultations, the researcher noticed that they seemed to understand a manual visual simulation of tracing, that is what happens in computer memory while a program is being executed, much better. In marking examination scripts for the follow-up first-year module, she also noticed that the kind of errors students make can be linked to lack of knowledge and comprehension of the processes that occur in CPU memory during program execution, particularly during parameter transfer. This corresponds to the findings of Milne and Rowe (2002), who ascribe students’ problems with object- oriented programming to lack of a clear mental model of how their programs’ storage work in memory and how objects in memory relate to each other.

The findings by the BRACElet project (Clear et al., 2009; Lister et al., 2004; Lister et al., 2009; Whalley & Lister, 2009) triggered the researcher’s interest in providing a way to assist introductory programming students at Unisa in learning to trace, in the hope that this would assist them to master the art of programming. Since PV has been used successfully in non-ODL settings, the researcher wished to provide Unisa’s introductory programming students with a tool to compensate for their lack of face-to-face instruction. The tool took the form of a customized tutorial to teach students to draw

variable diagrams to do memory tracing. The tutorial was not intended as a tool to be used during program construction, but instead to teach the students how to do manual tracing. This is in line with research showing that students need to engage with tracing themselves, in order to benefit from it (Hundhausen et al., 2002; Lauer, 2008; Naps, Röβling et al., 2003; Thomas et al., 2004).