Publications

This phenomenographic study opens the classroom door to investigate teachers’ experiences of students learning difficult computing topics. Three distinct themes are identified and analysed. Why, do students succeed, or fail, to learn these concepts? What actions do teachers perceive will ameliorate the difficulties facing students? Who is responsible, and for for what, in the learning situation?

Theoretical work on threshold concepts and conceptual change deals with mechanisms and processes associated with learning difficult material (Meyer and R.Land 2005, Entwistle 2007). With this work as a background we concentrate on the perceptions of teachers. Where do teachers feel that the difficulties lie when studying the troublesome knowledge in computing? Student and teacher-centric views of teaching reported in other literature are also to be seen in our results. The first two categories in the ”what” and ”who” themes are teachercentric. Higher level categories in all themes show increasingly learner centered conceptions of the instructional role. However, the nature of the categories in the ”why” theme reveals a new dimension dealing with teacher beliefs specific to the nature of troublesome knowledge in computing.

A number of prior studies in tertiary teaching concentrate on approaches to teaching (Trigwell and Prosser 2004), and attitudes to scholarship of teaching and learning (Ashwin and Trigwell 2004). Our focus on learning of difficult topics extends this work, investigating teacher conceptions of causality in relation to learning difficulties. We argue that teacher conceptions of enabling factors, for learning difficult computing topics, can act to limit the nature and scope of academics’ pedagogical responses. Improved awareness of teacher’s beliefs regarding student learning difficulties both extends and complements existing efforts to develop a more student-centered computing pedagogy.

We examine the changes in the ways computing students view their field as they learn, as reported by the students themselves in short written biographies. In many ways, these changes result in students thinking and acting more like computer scientists and identifying more with the computing community. Most of the changes are associated with programming and software engineering, rather than theoretical computer science, however.

We examine the changes in the ways computing students view their field as they learn, as reported by the students themselves in short written biographies. In many ways, these changes result in students thinking and acting more like computer scientists and identifying more with the computing community. Most of the changes are associated with programming and software engineering, rather than theoretical computer science, however.

We examine the transformations experienced by students during their study of computing. These transformations led to changes in the students’ perceptions of computer science, in their sense of identity as computer scientists, their behavior and their confidence. The changes are caused by learning or using particular concepts, and often associated with writing computer programs, learning new programming languages, or interacting with peers.

Changing the introductory programming course from a traditional imperative model to an object oriented model is not simply a matter of changing compilers and syntax. It requires a profound change in course materials and teaching approach to be successful. We have been working with this transition for almost ten years and have realized that teaching object-oriented programming is not as simple or “natural” as some proponents claim. In fact, it has proven difficult to convey to the students the advantages and methodologies associated with object-oriented programming. To help ourselves and others in a transition like this we have developed a number of “course design principles” as well as teaching methods and examples that have proven to have positive influence on student learning outcome.

Computer science is a complex, highly technical, and rapidly changing field. In addition, it is a new subject: we have had relatively few years to study the ways in which students learn and how to help them most effectively. Meyer and Land (2003; 2005) have proposed using “Threshold Concepts” as a way of characterising particular concepts that might be used to organise and focus the educational process. The idea has the potential to help us focus on those concepts that are most likely to block students’ learning progress (Davies, 2003).

This chapter describes an ongoing project aimed at empirically identifying threshold concepts in computer science. In a multi-national, multi-institutional study, we have gathered data from both educators and students. The paper outlines our experiences with various experimental techniques, issues raised, and results to date. Directly below, we discuss work in computing curricula that examines, from varying perspectives, the core concepts in computing; this work provides some specific places to begin looking for threshold concepts. We then describe the techniques we have used to gather data about potential threshold concepts from the perspective of both instructors and students. The results of a preliminary analysis of the data are presented, including the identification of two threshold concepts in computing with some associated evidence. Finally, we present our preliminary conclusions and discuss the future directions of this research effort.

Example programs play an important role in learning to program. They work as templates, guidelines, and inspiration for learners when developing their own programs. It is therefore important to provide learners with high quality examples. In this paper, we discuss properties of example programs that might affect the teaching and learning of object-oriented programming. Furthermore, we present an evaluation instrument for example programs and report on initial experiences of its application to a selection of examples from popular introductory programming textbooks.

In this paper, we present the results of an experiment in which we sought to elicit students’ understanding of object-oriented (OO) concepts using concept maps. Our analysis confirmed earlier research indicating that students do not have a firm grasp on the distinction between “class” and “instance.” Unlike earlier research, we found that our students generally connect classes with both data and behavior. Students rarely included any mention of the hardware/software context of programs, their users, or their real-world domains. Students do mention inheritance, but not encapsulation or abstraction. And the picture they draw of OO is a static one: we found nothing that could be construed as referring to interaction among ob jects in a program. We then discuss the implications for teaching introductory OO programming.

This paper examines transformational learning experiences of computing students as a way to better understand threshold concepts in computing. From empirical evidence we found that students often describe transformative experiences as learning situations in which they were led to use various kinds of abstraction, for example modularity, data abstraction, inheritance, polymorphism, reuse, design patterns, and complexity. Some students describe an abstract concept as coming first, and then needing to be made concrete though application; others describe transformations in which they learn the advantages of these abstract concepts from their experience of not using them. Abstraction is certainly of central importance in computer science. It appears, however, from our students’ descriptions of transformative experiences, that abstraction per se is not a threshold, but that particular concepts in which abstraction is paramount exhibit the characteristics of threshold concepts.

Data sharing is common, and sometimes even required, in other disciplines. Creating a mechanism for data sharing in computer science education research will benefit both individual researchers and the community. While it is easy to say that data sharing is desirable, it is much more difficult to make it a practical reality.
This paper reports on an examination of the issues involved by researchers who gathered at a one-day NSF-sponsored workshop held in connection with SIGCSE 2008. We outline the advantages and challenges of developing a repository, show how the challenges have been addressed by repositories in other fields, describe a possible prototype system for empirical computer science education data, and discuss how to move the project forward.

Examples are important tools for programming education. In this paper, we investigate desirable properties of programming examples from a cognitive and a measurement point of view. We argue that some cognitive aspects of example programs are “caught” by common software measures, but they are not sufficient to capture all important aspects of understandability. We propose a framework for measuring the understandability of example programs that also considers factors related to the usage context of examples. Research shows that examples play an important role for cognitive skill acquisition. Students as well as teachers rank examples as important resources for learning to program.

Students use examples as templates for their work. Therefore examples must be consistent with the principles and rules of the topics we are teaching; free of any undesirable properties or behaviour. By repeatedly exposing students to “exemplary” examples, desirable properties are reinforced many times. Students will eventually recognize patterns of “good” design, gaining experience in telling desirable from undesirable properties. We therefore need to be able to tell apart “good” and “bad” examples. To do so objectively and consistently requires some kind of measurement instrument.

In this paper, we describe the development and initial validation of an evaluation instrument for example programs, based on three aspects of quality; technical quality, object-oriented quality, and didactical quality. Validation was performed by six experienced educators using examples from popular introductory programming textbooks.

Results show that the instrument helps indicating particular strengths and weaknesses of example programs. In all but one example program, we identified aspects that need to be improved. However, inter-rater agreement is low. The instrument can therefore not be considered reliable enough for evaluations on a larger scale. Further work is necessary to fine-tune the instrument and provide guidance for its usage.

Yes and yes.
We are currently undertaking an empirical investigation of
“Threshold Concepts” in Computer Science, with input from both instructors and students. We have found good empirical evidence that at least two concepts—Object-oriented programming and pointers—are Threshold Concepts, and that there are potentially many more others.
In this paper, we present results gathered using various experimental techniques, and discuss how Threshold Concepts can affect the learning process.

This paper is part of an ongoing series of projects in which we are investigating “threshold concepts”: concepts that, among other things, transforms the way a student looks as the discipline and are often troublesome to learn. The word “threshold” might imply that students cross the threshold in a single “aha” moment, but often they seem to take longer. Meyer and Land introduce the term “liminal space” for the transitional period between beginning to learn a concept and fully mastering it.
Based on in-depth interviews with graduating seniors, we found that the liminal space can provide a useful metaphor for the concept learning process. In addition to observing the standard features of liminal spaces, we have identified some that may be specific to computing, specifically those relating to levels of abstraction.

Students often “get stuck” when trying to learn new computing concepts and skills. In this paper, we present and categorize strategies that successful students found helpful in getting unstuck. We found that the students reported using a broad range of strategies, and that these strategies fall into a number of recognizably different categories.

This paper reports on the efforts of an ITiCSE 2007 working group with the aim of producing a publicly available, searchable, tagable, Web 2.0-style repository of short debugging videos. This repository may be accessed from http://debug.csi.muohio.edu/. The videos are aimed at novice Java programmers who may need help debugging when none is available (e.g. in the middle of the night before the homework is due). However, it could also be used by instructors of introductory programming. Here we discuss our motivation in creating this repository and detail the process we followed and the products we produced.

This paper examines software designs produced by students nearing completion of their Computer Science degrees. The results of this multi-national, multi-institutional experiment present some interesting implications for educators.

This paper examines the problem of studying and comparing student software designs. We propose semantic categorization as a way to organize widely varying data items. We describe how this was used to organize a particular multi-national multi-institutional dataset, and present the results of this analysis: most students are unable to effectively design software. We examine how these designs vary with different academic and demographic factors, and discuss the implications of this work on both education and education research.

This paper describes Threshold Concepts, a theory of learning that distinguishes core concepts whose characteristics can make them troublesome in learning. With an eye to applying this theory in computer science, we consider this notion in the context of related topics in computer science education.discipline, but are also places in the curriculum where students get stuck, unable to make progress until they become unstuck.

This paper examines results from a multiple-choice test given to novice programmers at twelve institutions, with specific focus on annotations made by students on their tests. We found that the question type affected both student performance and student annotations. Classifying student answers by question type, annotation type (tracing, elimination, other, or none), and institution, we found that tracing was most effective for one type of question and elimination for the other, but overall, any annotation was better than none.

This paper reports a multi-national, multi-institutional study to investigate Computer Science students’ understanding of software design and software design criteria. Student participants were recruited from two groups: students early in their degree studies and students completing their Bachelor degrees. Computer Science educators were also recruited as a comparison group. The study, including over 300 participants from 21 institutions in 4 countries, aimed to understand characteristics of student-generated software designs, to investigate student recognition of requirement ambiguities, and to elicit students’ valuation of key design criteria. The results indicate that with increases in education, students use fewer textual design notations and more graphical and standardized notations and that they become more aware of ambiguous problem specifications. Yet increased educational attainment has little effect on students’ valuation of key design characteristics.

This paper examines the problem of studying and comparing student software designs. We propose semantic categorization as a way to organize widely varying data items. We describe how this was used to organize a particular multi-national multi-institutional dataset, and discuss the implications of using such techniques for education researchers.

A study by a ITiCSE 2001 working group (”the McCracken Group”) established that many students do not know how to program at the conclusion of their introductory courses. A popular explanation for this incapacity is that the students lack the ability to problem-solve. That is, they lack the ability to take a problem description, decompose it into sub-problems and implement them, then assemble the pieces into a complete solution. An alternative explanation is that many students have a fragile grasp of both basic programming principles and the ability to systematically carry out routine programming tasks, such as tracing (or ”desk checking”) through code. This ITiCSE 2004 working group studied the alternative explanation, by testing students from seven countries, in two ways. First, students were tested on their ability to predict the outcome of executing a short piece of code. Second, students were tested on their ability, when given the desired function of short piece of near-complete code, to select the correct completion of the code from a small set of possibilities. Many students were weak at these tasks, especially the latter task, suggesting that such students have a fragile grasp of skills that are a pre- requisite for problem-solving.

This paper examines results from a multiple-choice test given to novice programmers at twelve institutions, with specific focus on annotations made by students on their tests. We found that the question type affected both student performance and student annotations. Classifying student answers by question type, annotation type (tracing, elimination, other, or none), and institution, we found that tracing was most effective for one type of question and elimination for the other, but overall, any annotation was better than none.

This paper reports a multi-national, multi-institutional study to investigate Computer Science students’ understanding of software design and software design criteria. Student participants were recruited from two groups: students early in their degree studies and students completing their Bachelor degrees. Computer Science educators were also recruited as a comparison group. The study, including over 300 participants from 21 institutions in 4 countries, aimed to understand characteristics of student-generated software designs, to investigate student recognition of requirement ambiguities, and to elicit students’ valuation of key design activities. The results indicate that with experience, students become more aware of ambiguous problem specifications and are able to address more of the re- quirements in their software designs, that they use fewer textual design notations and more graphical and standardized notations, that they systemically ignore groupings and interactions among the different parts of their designs, and that students change their valuation of key design activities in response to changes in problem-solving context.

This paper reports a multi-national, multi-institutional study to investigate Computer Science students’ understanding of software design and software design criteria. Students were recruited at two levels: those termed ‘first competency’ programmers, and those completing their Bachelor degrees. The study, including participants from 21 institutions over the academic year 2003/4, aimed to examine students’ ability to generate software designs, to elicit students’ understanding and valuation of key design activities, and to examine whether students at different stages in their undergraduate education display different understanding of software design. Differences were found in particpants’ recognition of ambiguity in requirements; in their use of formal (and semi-formal) design representation and in their prioritisation of design criteria.

In this article, we report on an investigation into how educators describe the design of three software systems. We have been especially interested in how they describe events that are concurrent, as we believe support for concurrency will be required of an educational software authoring system. Their descriptions of concurrent processes can then be used to design the authoring system to “naturally” support concurrent programming.

Almost all participants in our investigation used concurrency as a part of their description. No one seemed to think that this was difficult. In addition, we observed that the educators frequently thought in terms of objects. These results suggest that any authoring environment targeted at teaching should include support for concurrency and objects.