Table 1 - uploaded by Martin Dick
Content may be subject to copyright.
describes the different data gathering techniques used through the course of this research. 

describes the different data gathering techniques used through the course of this research. 

Source publication
Article
Full-text available
This paper reports on an Action Research project that investigated the effect of introducing a number of Extreme Programming (XP) practices as teaching techniques to introductory programming students. The focus of the study was on using the XP practices to assist students in an introductory programming subject develop object oriented programming sk...

Similar publications

Article
Full-text available
The adoption of agile practices in software projects has been faced with scepticism by practitioners, with concerns about the actual effectiveness of these practices. Using system dynamics, this study investigates the impact of four popular agile practices, Test-Driven Development, Pair Programming, On-site Customer Involvement and Pair Testing, on...

Citations

... Moreover, Corney, Teague and Thomson (2010) disclosed that the students' engagement can be improved through collaborative approach. Keefe, Sheard and Dick (2006) earlier highlighted that the use of pair programming makes the class more enjoyable. Interestingly, Salleh et al. (2011) examined the effects of pair programming and concluded that it can improve the achievement and interest to the programming class. ...
... He highlighted the important factors that need to be considered in implementing a successful pair programming technique which are the compatibility with the partner, the programming ability and similar motivation levels. These factors are also consistent with the existing study by Eierman and Iversen (2018) and Keefe et al. (2006). ...
Chapter
As programming is one of the core subjects for BSc IT students, it is vital for them to have programming skill. However, students are often terrified of programming since it is a challenging subject. Traditionally, the programming teaching and learning process are limited to lectures and lab exercises. This approach is no longer appropriate in today's learning environment and required skills in the 21st century. Collaborative learning is acknowledged as an approach that fits the programming students. Thus, this chapter has adapted the collaborative approach in Programming 1 class. Three techniques were applied namely problem-based learning, buzz groups, and pair programming. At the end of the semester, an online survey to obtain students' opinions and a focus group discussion were conducted. In addition, the examination results of the repeaters were also compared. Results from the survey and focus group indicate that the collaborative approach is able to increase students' interest and the grade of the repeaters in the Programming 1 subject.
... Software development projects in industry frequently include code review in the development process. Such reviews aim to identify defects and improve the quality of the code [13,15]. Ultimately, the main purpose of these industry code reviews is to produce a better software product. ...
Conference Paper
Full-text available
The practice of Peer Review is widespread across a range of academic disciplines. We report on a study that compared two different approaches of peer reviewing program code --- reviewing a sequence of solutions to the same problem (sequential code review), and reviewing a set of multiple solutions side-by-side (parallel code review). We found that the parallel approach was preferred by the majority of participants in the study and there were some indications that it might be more helpful for reviewers, but the sequential approach elicited more written comments in general, and more specific critical comments compared with the parallel approach. Although parallel reviews may be preferred by reviewers, using sequential reviews appears to result in increased levels of formative feedback for the recipient.
... Finally, an action research study by Keefe et al. followed 19 students over a period of eighteen weeks, during which the subjects were attending a course about several extreme programming practices including TDD ( Keefe et al. 2006). The analysis of the subjects' reflection showed that none of the students, even the ones who passed the course with excellent scores, expressed a preference for TDD. ...
Article
Background: Test-Driven Development (TDD) is claimed to have positive effects on external code quality and programmers’ productivity. The main driver for these possible improvements is the tests enforced by the test-first nature of TDD as previously investigated in a controlled experiment (i.e. the original study). Aim: Our goal is to examine the nature of the relationship between tests and external code quality as well as programmers’ productivity in order to verify/ refute the results of the original study. Method: We conducted a differentiated and partial replication of the original setting and the related analyses, with a focus on the role of tests. Specifically, while the original study compared test-first vs. test-last, our replication employed the test-first treatment only. The replication involved 30 students, working in pairs or as individuals, in the context of a graduate course, and resulted in 16 software artifacts developed. We performed linear regression to test the original study’s hypotheses, and analyses of covariance to test the additional hypotheses imposed by the changes in the replication settings. Results: We found significant correlation (Spearman coefficient = 0.66, with p-value = 0.004) between the number of tests and productivity, and a positive regression coefficient (p-value = 0.011). We found no significant correlation (Spearman coefficient = 0.41 with p-value = 0.11) between the number of tests and external code quality (regression coefficient p-value = 0.0513). For both cases we observed no statistically significant interaction caused by the subject units being individuals or pairs. Further, our results are consistent with the original study although there were changes in the timing constraints for finishing the task and the enforced development processes. Conclusions: This replication study confirms the results of the original study concerning the relationship between the number of tests vs. external code quality and programmer productivity. Moreover, this replication allows us to identify additional context variables, for which the original results still hold; namely the subject unit, timing constraint and isolation of test-first process. Based on our findings, we recommend practitioners to implement as many tests as possible in order to achieve higher baselines for quality and productivity.
... ly " . Like us they did this by assessing students' test coverage and by keeping some unit tests used in marking from the students. (In fact, in our experiments we did not provide the students with any unit tests at all. Instead we gave them an Application Programming Interface to satisfy, so that they had to develop all the unit tests themselves.) Keefe et al. (2006) aimed to introduce not just test-driven development into first-year programming, but also other 'extreme' programming concepts such as pair programming and refactoring. (These principles are also introduced in our overall curriculum, but not all during first year.) Their survey of students found a unanimous dislike of test-driven develo ...
Conference Paper
Full-text available
The well-known difficulties students exhibit when learning to program are often characterised as either difficulties in understanding the problem to be solved or difficulties in devising and coding a computational solution. It would therefore be helpful to understand which of these gives students the greatest trouble. Unit testing is a mainstay of large-scale software development and maintenance. A unit test suite serves not only for acceptance testing, but is also a form of requirements specification, as exemplified by agile programming methodologies in which the tests are developed before the corresponding program code. In order to better understand students’ conceptual difficulties with programming, we conducted a series of experiments in which students were required to write both unit tests and program code for non-trivial problems. Their code and tests were then assessed separately for correctness and ‘coverage’, respectively. The results allowed us to directly compare students’ abilities to characterise a computational problem, as a unit test suite, and develop a corresponding solution, as executable code. Since understanding a problem is a pre-requisite to solving it, we expected students’ unit testing skills to be a strong predictor of their ability to successfully implement the corresponding program. Instead, however, we found that students’ testing abilities lag well behind their coding skills.
... A study performed by Keefe [9] introduced students to four XP practices: Pair Programming, Test Driven Development, Simple Design, and Refactoring. Of the four practices TDD was least preferred by the students in the study. ...
... These very simple first steps are to help the student build confidence and to not be overwhelmed too early. This will attempt to break down some of the initial resistance to TDL other studies have found to be common in beginning students [9,8]. ...
... We have gradually been introducing testing, but at this point they are now doing test-first development. In order to avoid the confusion that has bothered other students in the past [9] we attempt to make the tests as straight forward as possible and directly related to the outcome of the code. ...
Article
Full-text available
Test-driven development (TDD) has been shown to reduce defects and to lead to better code, but can it help beginning students learn basic programming topics, specifically arrays? We performed a controlled experiment where we taught arrays to two CS0 classes, one using WebIDE, an intelligent tutoring system that enforced the use of Test-Driven Learning (TDL) methods, and one using more traditional static methods and a development environment that instructed, but did not enforce the use of TDD. Students who used the TDL approach with WebIDE performed significantly better in assessments and had significantly higher opinions of their experiences than students who used traditional methods and tools.
... Edwards [17] has suggested an approach to motivate students to apply TDD that incorporates testing into project grades, and he provides an example of an automated grading system that provides useful feedback. A number of early adopters have successfully incorporated TDD into first year programming courses [18], [19]. A variety of web-based tools exist to support learning to program, from static lab exercises to applets that let you interact with data structures. ...
Conference Paper
We describe the preliminary construction of a web-based tool for test-driven learning in the first weeks of programming. We discuss obstacles to test-driven learning - both pragmatic and ideological - and describe the ways that we believe our tool overcomes these obstacles.
... Edwards [17] has suggested an approach to motivate students to apply TDD that incorporates testing into project grades, and he provides an example of an automated grading system that provides useful feedback. A number of early adopters have successfully incorporated TDD into first year programming courses [18], [19]. A variety of web-based tools exist to support learning to program, from static lab exercises to applets that let you interact with data structures. ...
Article
We describe the preliminary construction of a web-based tool for test-driven learning in the first weeks of programming. We discuss obstacles to test-driven learning--both pragmatic and ideological--and describe the ways that we believe our tool overcomes these obstacles.
... Although objects-first sounds like a concrete and specific pedagogical idea, there are a lot of different pedagogical dimensions involved. A list of paper titles contributing to the debate on objects-first gives an impression of the issues involved: @BULLET Mental models and programming aptitude [5] @BULLET From objects-first to design-first with multimedia and intelligent tutoring [21] @BULLET Day one of the objects-first first course: what to do [3] @BULLET Implications of perspective in teaching objects first and object design [7] @BULLET An objective comparison of languages for teaching introductory programming [16] @BULLET Methodology first and language second: a way to teach object-oriented programming [27] @BULLET Relationship of early programming language to novice generated design [6] @BULLET A study of the development of students' visualizations of program state during an elementary object-oriented programming course [22] @BULLET Adopting XP practices for teaching object-oriented pro- gramming [11] In the study of Vilner et. al. [25], no significant differences were found between procedural-first vs. objects-first. ...
Conference Paper
In this paper, results of an empirical comparison of objects-first vs. objects-later are presented and discussed. The study was carefully designed to align the two approaches so that the comparison is focused on the main difference between the two approaches; that is the different sequence in which topics are taught: object oriented topics from the beginning or not. The study with duration of one year was carried out in a secondary school. In the end, both groups showed the same increase in learning gain, but perceived the difficulty of topics differently. We discuss study design, results and pedagogical implications.
... A reinforced learning approach such as TDL could be key to successfully introducing TDD. In cases where students were just briefly introduced to testing at the start of the semester, TDD was not preferred[10] and only 10% of the students wrote test cases[1]. Numerous TDD-based controlled experiments have been reported and surveyed[9, 6, 2]. ...
... However, nearly all of the controlled experiments looked at sophomore-to graduatelevel classes, not CS1 or CS2 courses which present unique challenges. As Keefe et al. note[10], students starting to learn what programming is and how it works find it tough to find purpose in the code, so testing it is difficult. Erdogmus [5] compared a TDD group to an iterative testlast group. ...
Article
Many academic and industry professionals have called for more testing in computer science curricula. Test-driven development (TDD) has been proposed as a solution to improve testing in academia. This paper demonstrates how TDD can be integrated into existing course materials without reducing topic coverage. Two controlled experiments were conducted in a CS1/CS2 course in Winter 2008. Following a test-driven learning approach, unit testing was introduced at the beginning of the course and reinforced through example. Results indicate that while student work loads may increase with the incorporation of TDD, students are able to successfully develop unit tests while learning to program.
... Following the 2007 survey and aiming to develop a collaborative learning environment to support novice programmers (Werner, L.L., Hanks, B. et al. 2004;Keefe, K., Sheard, J. et al. 2006; Bagley, C.A., Chou, C.C. 2007) an experiment was conducted over two semesters involving introductory level programming students at QUT The hypothesis tested was that pair-programming style collaborative learning has a positive effect on students' learning outcome. ...
Article
Full-text available
The consistently high failure rate in Queensland University of Technology’s introductory programming subject reflects a similar dilemma facing other universities worldwide. Experiments were conducted to quantify the effectiveness of collaborative learning on introductory level programming students over a number of semesters, replicating previous studies in this area. A selection of workshops in the introductory programming subject required students to problem-solve and program in pairs, mimicking the eXtreme Programming concept of pair programming. The failure rate for the subject fell from what had been an average of 30% since 2003 (with a high of 41% in 2006), to just 5% for those students who worked consistently in pairs.