Introductory programming: a systematic literature review

As computing becomes a mainstream discipline embedded in the school curriculum and acts as an enabler for an increasing range of academic disciplines in higher education, the literature on introductory programming is growing. Although there have been several reviews that focus on specific aspects of introductory programming, there has been no broad overview of the literature exploring recent trends across the breadth of introductory programming. This paper is the report of an ITiCSE working group that conducted a systematic review in order to gain an overview of the introductory programming literature. Partitioning the literature into papers addressing the student, teaching, the curriculum, and assessment, we explore trends, highlight advances in knowledge over the past 15 years, and indicate possible directions for future research

Distributed-Pair Programming can work well and is not just Distributed Pair-Programming

Background: Distributed Pair Programming can be performed via screensharing or via a distributed IDE. The latter offers the freedom of concurrent editing (which may be helpful or damaging) and has even more awareness deficits than screen sharing. Objective: Characterize how competent distributed pair programmers may handle this additional freedom and these additional awareness deficits and characterize the impacts on the pair programming process. Method: A revelatory case study, based on direct observation of a single, highly competent distributed pair of industrial software developers during a 3-day collaboration. We use recordings of these sessions and conceptualize the phenomena seen. Results: 1. Skilled pairs may bridge the awareness deficits without visible obstruction of the overall process. 2. Skilled pairs may use the additional editing freedom in a useful limited fashion, resulting in potentially better fluency of the process than local pair programming. Conclusion: When applied skillfully in an appropriate context, distributed-pair programming can (not will!) work at least as well as local pair programming

Pair programming and the re-appropriation of individual tools for collaborative software development

Although pair programming is becoming more prevalent in software development, and a number of reports have been written about it [10] [13], few have addressed the manner in which pairing actually takes place [12]. Even fewer consider the methods used to manage issues such as role change or the communication of complex issues. This paper highlights the way resources designed for individuals are re-appropriated and augmented by pair programmers to facilitate collaboration. It also illustrates that pair verbalisations can augment the benefits of the collocated team, providing examples from ethnographic studies of pair programmers 'in the wild'

Utilising pair programming to enhance the performance of slow-paced students on introductory programming

Due to its high failure rate, Introductory Programming has become a main concern. One of the main issues is the incapability of slow-paced students to cope up with given programming materials. This paper proposes a learning technique which utilises pair programming to help slow-paced students on Introductory Programming; each slow-paced student is paired with a fast-paced student and the latter is encouraged to teach the former as a part of grading system. An evaluation regarding that technique has been conducted on three undergraduate classes from an Indonesian university for the second semester of 2018. According to the evaluation, the use of pair programming may help both slow-paced and fast-paced students. Nevertheless, it may not significantly affect individual academic performancePeer Reviewe

Do Pair Programming Approaches Transcend Coding? Measuring Agile Attitudes in Diverse Information Systems Courses

Agile methods and approaches such as eXtreme programming (XP) have become the norm for successful organizations not only in the software industry but also for businesses seeking to improve internal software processes. Pair programming in some form is touted as a major functionality and productivity improvement. However, numerous studies show that simply placing two programmers side by side in front of a single computer screen is not enough. We must look at other factors such as programmer expertise, project preparation, and perceived solution quality to understand pair programming’s promises and pitfalls. In our study, we apply tailored programming challenges to a multifaceted group of first-year through senior Information Systems (IS) and non-IS majors to analyze how participant attitudes and perceived benefits of pair programming change from pre- to post-study, as well as determine whether the quality and functionality of the solutions differ across education levels and disciplines. Our findings show a strong interaction effect of gender and major composition (CIS vs. non-CIS majors) in all four dimensions of the ATMI attitude scale. Findings also suggest that experience in problem solving and solution formation are more important than prior specific domain knowledge. Finally, participants’ perceived ability, sense of accomplishment, and completion of the assigned work, regardless of background or demographic, determined their performance outcome on the pair-programming tasks, which suggests that not all forms of attitude and perceived benefits contribute to the performance outcome

A Family of Experiments on Test-Driven Development

Context: Test-driven development (TDD) is an agile software development approach that has been widely claimed to improve software quality. However, the extent to which TDD improves quality appears to be largely dependent upon the characteristics of the study in which it is evaluated (e.g., the research method, participant type, programming environment, etc.). The particularities of each study make the aggregation of results untenable. Objectives: The goal of this paper is to: increase the accuracy and generalizability of the results achieved in isolated experiments on TDD, provide joint conclusions on the performance of TDD across different industrial and academic settings, and assess the extent to which the characteristics of the experiments affect the quality-related performance of TDD. Method: We conduct a family of 12 experiments on TDD in academia and industry. We aggregate their results by means of meta-analysis. We perform exploratory analyses to identify variables impacting the quality-related performance of TDD. Results: TDD novices achieve a slightly higher code quality with iterative test-last development (i.e., ITL, the reverse approach of TDD) than with TDD. The task being developed largely determines quality. The programming environment, the order in which TDD and ITL are applied, or the learning effects from one development approach to another do not appear to affect quality. The quality-related performance of professionals using TDD drops more than for students. We hypothesize that this may be due to their being more resistant to change and potentially less motivated than students. Conclusion: Previous studies seem to provide conflicting results on TDD performance (i.e., positive vs. negative, respectively). We hypothesize that these conflicting results may be due to different study durations, experiment participants being unfamiliar with the TDD process..

Exploratory Comparison of Expert and Novice Pair Programmers

We conducted quasi-experiment comparing novice pair programmers to expert pair programmers. The expert pairs wrote tests with a higher instruction, line, and method coverage than the novice pairs and changed the given program skeleton to a larger extent. However, the expert pairs were also slower than the novice pairs. The pairs within both groups switched keyboard and mouse possession frequently. Furthermore, most pairs did not share the input devices equally but rather had one partner who is more active than the other