No full-text available
To read the full-text of this research,
you can request a copy directly from the authors.
Experimental Evaluation of Pair Programming
Abstract
Pair programming is a kind of collaborative programming where two people are working simultaneously on the same programming task. It is one of the key practices of eXtreme Programming. In the paper we compare it with two variants of individual programming: one of them is based on Personal Software Process that has been proposed by W. Humphrey, and the other is a variant of eXtreme Programming tailored to individuals. Four experiments are described that has been performed at the Poznan University of Technology. During those experiments 21 students wrote 4 C/C++ programs ranging from 150 to 400 LOC. The obtained results are compared with the results of similar experiments described by J.T. Nosek and L. Williams et al.
... Some beneficial effects reported in these studies are that PP helps to produce shorter programs and achieve better designs; programs contain fewer defects than those written individually; and pairs usually require less time to complete a task than programmers working individually. It is observed that PP seems to benefit teamwork, knowledge transfer and learning [15,14,28], however it requires more development effort [15,29,4,28]. Notwithstanding, there are studies in which authors did not observe significant differences when applying this practice [29,4,30,31,21,32,10]. ...
... It is observed that PP seems to benefit teamwork, knowledge transfer and learning [15,14,28], however it requires more development effort [15,29,4,28]. Notwithstanding, there are studies in which authors did not observe significant differences when applying this practice [29,4,30,31,21,32,10]. ...
... However, there is evidence that suggests that in some contexts, the results of empirical studies that employ students with sufficient technical skills are equivalent to the results of empirical studies that use practitioners [60,61]. In the context of PP studies, there is evidence in favor of this claim: PP studies that employ practitioners [4,10] report findings that are similar to studies employing students [29,32]. More significant could be the use of small program assignments instead of larger examples. ...
Abstract. Context: Nowadays the pair programming (PP) approach is a well known practice that has been studied and applied in academia and industry, however the study of gender along with this practice is scarce. Objective: With the aim of approaching the study of gender in PP we conducted an empirical study. Method: We run a controlled experiment in an academic setting to assess the productivity (lines of code per hour) produced by different gender pair configurations (Female-Female, Female-Male and Male-Male). Results: Our results suggest similar productivity rates for the three gender pair combinations. The programming assignments have a significant impact on the productivity. Finally, we observed greater variability of productivity rates with mixed gender pairs (F-M). Conclusions: The experiment reported here can serve as reference for studying further aspects related to gender and pair programming.
... Third, findings on how much more time is required by the pair programming method varied from a decrease in time (Lui and Chan, 2003), a 15 percent increase , a 41 percent increase (Nosek, 1998), to a 100 percent increase (Nawrocki and Wojciechowski, 2001), thus failing to provide a definitive answer to whether pair programming requires more programming hours than solo programming, and if so, by how much. ...
... The results suggested the average time spent to complete all three tasks by solo and pair programmers was very similar, which means pairs needed almost twice as much time to complete the same amount of work compared to individuals. This result was confirmed by student experiments conducted by Nawrocki and Wojciechowski (2001) and . ...
... This definition of effort is widely used for software project effort measurement (Pressman, 2005;Sommerville, 2007), and was adopted by many previous pair programming studies (Nosek, 1998;Nawrocki and Wojciechowski, 2001;Rostaher and Hericko, 2002;Dybå et al., 2007). ...
... He continuously assures quality, trying to understand, asking questions, looking for alternative approaches, helping to avoid defects alone [78]. The programmers regularly trade roles while pairing creator becomes quality assurer and vice versa [79]. Code written by only one member of the pair is reviewed by both partners together before it is officially accepted as part of the program. ...
... It often benefits women and can be a solution for more women in computer science courses [76,89]. But there are those who hate this strategy using various arguments, the first of which is a huge expenditure of time, money and resources: when two people are doing the same task, the spent effort is doubled [77], pairs spend almost twice as much total programmer effort as solo programmers [79]. Others doubt the benefits and say there is a need for more rigorous studies to compare the effectiveness of pair programming with reviewing techniques [73,78]. ...
Teaching and learning how to program are not easy tasks: they can be very challenging. Introductory programming courses traditionally have high rates of failures and dropouts. Teachers and researchers must develop strategies to combat this problem. The purpose of this paper is to analyse the scientific production on strategies on teaching how to program in higher education in journals indexed in an international database’ indexed in Elsevier’s Scopus in the years 2000 to 2019. We provide an up-to-date review of the existing literature. To provide a comprehensive survey, we not only categorize existing strategies but also present detailed descriptions of relevant topics such as Active Learning, Pair Programming, Flipped Classroom and Project Based Learning. The sample was composed by 92 articles in total. The first results obtained by bibliometric analysis showed that publication rates increased slowly but have expanded in the last two years, in which journals the articles are published, which are the organizations and countries that publish the most and which are the most cited articles. The motivation for this study is to bear in mind the research that has been done so that it strategies can be used and experienced by teachers who teach programming to undergraduate students.
... He continuously assuring quality, trying to understand, asking questions, looking for alternative approaches, helping to avoid defect alone [12]. The programmers regularly trade roles while pairing creator becomes quality assurer and vice versa [13]. Code written by only one member of the pair is reviewed by both partners together before it is officially accepted as part of the program. ...
... But there are those who hate this strategy using various arguments, the first of which is a huge expenditure of time, money and resources: when two people are doing the same task, the spent effort is doubled [11], pairs spend almost twice as much total programmer effort as solo programmers [13]. Others doubt the benefits and say there is a need for more rigorous studies to compare the effectiveness of pair programming with reviewing techniques [7], [12]. ...
Pair programming is by definition two-person programming on the same computer. The technique has been used in many higher education institutions and has been reported in some scientific articles, usually for introductory to programming courses. The aim of this article is to make a situation report analyzing the scientific production on pair programming for curricular units of introduction to programming in higher education, measuring the advantages and disadvantages of the strategy. The sample was composed by 153 articles indexed in Elsevier's Scopus. The results obtained by bibliometric analysis showed the publication rates, authors, in which journals they are published, which are the organizations and countries that publish the most, which are the most cited articles and what their purpose. The benefits reported are generally better code, improved programming and group skills, advantages for women and reducing the work of instructors. The problems are group compatibility: there are studies that randomly distribute pairs, while other use personality tests or knowledge self-assessment. Index Terms-Pair programming, CS1, introduction to programming, higher education.
... However, the results draw a rather divergent picture of the productivity of pair programming. While some studies [9,13] report a reduction of development time using pair programming other studies [8] report that there is no benefit. When we look at the defect reduction capabilities, we also see a divergent picture. ...
... When we look at the defect reduction capabilities, we also see a divergent picture. Some studies report on a reduced defect density caused by pair programming [13,11] while others do not [8]. And finally, pair programming seems to be comparable to partner programming [2] and solo programming with reviews [5,7]. ...
... Dingsoyr, Nerur, Balijepally, and Moe (2012) present an interesting review of the work done in agile software development. They suggest that earlier research works focused on adoption of agile methods and the efficacy of pair programming (e.g., Boehm, 2002;Nawrocki & Wojciechowski, 2001;Nerur, Mahapatra, & Mangalaraj, 2005;Williams, Kessler, Cunningham, & Jeffries, 2000) while later research streams have focused on team dynamics issues such as trust, self-organization, and communication (e.g., Moe, Dingsøyr, & Dybå, 2009). Research has also focused on issues related to consequences of testdriven development (Erdogmus, Morisio, & Torchiano, 2005;Janzen & Saiedian, 2005), adoption and post-adoption (Cao, Mohan, Xu, & Ramesh, 2009;Mangalaraj, Mahapatra, & Nerur, 2009), and challenges of agile development in distributed settings (Ramesh, Cao, Mohan, & Peng, 2006), and the like. 1 This wide range of studies have investigated the effects of agile practices on different performance metrics, the most notable one being software functionality. ...
... This study also extends the literature on agile development practices. Prior agile development literature has focused on important issues, such as team dynamics, trust, self-organization, communication, test-driven development (Boehm, 2002;Nawrocki & Wojciechowski, 2001;Nerur et al., 2005;Williams et al., 2000) and adoption (Erdogmus et al., 2005;Mangalaraj et al., 2009) There is no research that has studied whether agile practices have any effect on automating and informating functionalities. We learned that the relation between informating functionalities and agile practices is actually a two-way relation which suggests that it is not just that agile practices help develop informating functionalities, but also that engaging the users in the process of developing informating functionalities, in turn, helps agile practices. ...
We use action research to understand the concepts of automating and informating, and study whether agile development practices could be an enabler of informating functionalities. Two questions based on these contrasts and connections motivate this research. Our first research question is: What are the characteristics of an informating functionality and how does an informating functionality differ from an automating functionality? Our second research question is: What role could agile practices play in the development of informating functionalities? In this paper, we discuss the actions, reflections and lessons learned from three action research iterations while developing an admissions application for a business college.
... Conversely, the authors in [24] observed a significant difference (at α = 0.1) in favor of pairs, whom also completed the assignment in less time than did solos. In this sense, our results are similar to those reported in [17], [44], and [53]- [58], wherein the authors did not observe significant differences when applying the pair programming practice. ...
... However, there is evidence that suggests that in some contexts, the results of empirical studies that employ students with enough technical skills are equivalent to the results of empirical studies that use practitioners [60], [61]. In the context of pair programming studies, there is evidence in favor of this claim: pair programming studies that employ practitioners [44], [54] report findings that are similar to studies employing students [53], [58]. In this respect, the participants in this experiment reported having almost two years of experience with the Java programming language and almost two years of experience with the NetBeans IDE. ...
The adoption of agile software development approaches has been widespread. One well-known agile approach is eXtreme Programming (XP), which encompasses twelve practices being pair programming one of them. Although various aspects of pair programming have been studied, we have not found, under a traditional setting of Pair Programming (PP), studies that examine the impact of using a tool support, such as an Integrated Development Environment (IDE) or a simple text editor. In an attempt to obtain a better understanding of the impact of using an IDE in this field, we present the results of a controlled experiment that expose the influence on quality, measured as the number of defects injected per hour, and cost, measured as the time necessary to complete a programming assignment, of pair and solo programming with and without the use of an IDE. For quality, our findings suggest that the use of an IDE results in significantly higher defect injection rates (for both pairs and solos) when the programming assignment is not very complicated. Nevertheless, defect injection rates seem to decrease when pairs work on more complicated programming assignments irrespective of the tool support that they use. For cost, the programming assignment significantly affects the time needed
to complete the assignment. In relation to the programming type, pairs and solos performed in a similar way with regards to quality and cost.
... One concrete example of such observable outputs runs as follows: Software development projects are often significant in scale and scope, and require the collaboration of multiple computer programmers working on separate parts of the software-system. The project manager or the team-leader can, most often, both observe and measure the individual 'outputs', since the project is comprised of joint, yet individual, tasks within the grand task assigned (see e.g., Nawrocki and Wojciechowski;2001). 11 For examples of companies that reward the highest performer in a team with a Bonus, see Hoffman and Rogelberg (1998). 12 A similar prediction emerges in BPS (2009)however, the setting there is one where rewards are conditioned on the "success-probability" of a project which is different from that in the standard team-production model. ...
... One concrete example of such observable outputs runs as follows: Software development projects are often significant in scale and scope, and require the collaboration of multiple computer programmers working on separate parts of the software-system. The project manager or the team-leader can, most often, both observe and measure the individual 'outputs', since the project is comprised of joint, yet individual, tasks within the grand task assigned (see e.g., Nawrocki and Wojciechowski;2001). 11 For examples of companies that reward the highest performer in a team with a Bonus, see Hoffman and Rogelberg (1998). ...
... Other studies, however, have findings that contradict this positive view of PP. Numerous studies have found that PP does not reduce the time required to solve the tasks correctly and does not increase the proportion of correct solutions (Arisholm, Gallis, Dyba, Sjoberg, 2007;Nawrocki & Wojciechowski, 2001). Thus, there is a general lack of consensus on the merits (or lack therof) of PP, and the conditions under which PP can be more or less effective. ...
... In fact, prior research shows that the average completion time for pairs is about 40% more than for individuals (Nosek, 1998). More recent research shows an even more drastic effect-instead of spending 40% more time on tasks, pairs seem to spend double of the time (Rosta 11 her & Kericko, 2002, Nawrocki & Wojciechowski, 2001McDowell et al., 2003). There are, however, findings contradicting these results. ...
Pair programming (PP) is a practice when two developers work together on the same task using one computer screen (Beck, 2000; Williams & Kessler, 2003). The pair consists of a "driver" and a "navigator." The driver's goal is to write the program code while the navigator's goal is to perform more strategic tasks such as reviewing the code and searching for errors. PP has drawn the attention of many researchers and practitioners because many believe it is a better alternative to individual programming. Yet, the current literature possesses conflicting results, which reflect a lack of consensus. In this paper we look to take a step toward reconciling these ambiguous findings by carefully distinguishing between dependent variables used in the various extant studies, and by developing a contingency approach to understanding the merits of PP.
... The most scientific efforts can be identified within the realm of XP practices, i.e. pair programming (Williams et al. 2000;Nawrocki and Wojciechowski 2001;Succi et al. 2002;Heiberg et al. 2003;Janes et al. 2003;Lui and Chan 2003;Williams and Kessler 2003) and test-first approach to software development (Müller and Hagner 2002), or their combination (Rostaher and Hericko 2002;George and Williams 2003). Experiences from using XP, and its variations, can be identified in university (Müller and Tichy 2001;Nawrocki et al. 2002), research institute (Abrahamsson 2003; Wood and Kleb 2003;Sfetsos et al. 2006), and commercial settings (Anderson et al. 1998;Grenning 2001;Schuh 2001;Murru et al. 2003;Rasmusson 2003). ...
Although agile software development methods have caught the attention of software engineers and researchers worldwide, scientific research still remains quite scarce. The aim of this study is to order and make sense of the different agile approaches that have been proposed. This comparative review is performed from the standpoint of using the following features as the analytical perspectives: project management support, life-cycle coverage, type of practical guidance, adaptability in actual use, type of research objectives and existence of empirical evidence. The results show that agile software development methods cover, without offering any rationale, different phases of the software development life-cycle and that most of these methods fail to provide adequate project management support. Moreover, quite a few methods continue to offer little concrete guidance on how to use their solutions or how to adapt them in different development situations. Empirical evidence after ten years of application remains quite limited. Based on the results, new directions on agile methods are outlined.
... In general, software practitioners have several means to detect bugs. These can range from QA practices such as code review Kononenko et al. (2016); Mäntylä and Lassenius (2008); Bacchelli and Bird (2013), and inspection to different testing approaches, and even development methodologies such as pair programming Williams et al. (2000); Nawrocki and Wojciechowski (2001); Sun et al. (2015), and Test Driven Development (TDD) Bhat and Nagappan (2006); Martin (2007); Aniche et al. (2013); Rafique and Mišić (2012). When a bug is detected, it is common for the development teams to consider the most severe/important bugs first which helps them to prevent extreme consequences. ...
... [19][20][21][22][23] Some researchers argue that pair programming is neither as economical nor productive as individual programming. 24 In comparison, others point out the need for more studies in this regard. [25][26][27][28] The divergence in the results may be due to the investigation's validity. ...
In this article, a systematic review is carried out to identify random and systematic errors in studies on computer programming in pairs in higher education students. Methodologically, we applied the fundamentals of the PRISMA statement. One thousand one hundred eighty articles were selected from the Scopus, Web of Science, and IEEE Xplore databases. After a filtering process, the final sample was 23 23 articles. The results showed that couple programming has positive effects. The existence of both random and systematic errors was observed, which questions the internal and external validity. Further research is needed to establish the benefits of couple programming more precisely.
... In general, software practitioners have several means to detect bugs. These can range from QA practices such as code review [50,56,14], and inspection to different testing approaches, and even development methodologies such as pair programming [109,66,95], and Test Driven Development (TDD) [18,57,10,78]. When a bug is detected, it is common for the development teams to consider the most severe/important bugs first which helps them to prevent extreme consequences. ...
In the past couple of decades, significant research efforts are devoted to the prediction of software bugs (i.e., defects). These works leverage a diverse set of metrics, tools, and techniques to predict which classes, methods, lines, or commits are buggy. However, most existing work in this domain treats all bugs the same, which is not the case in practice. The more severe the bugs the higher their consequences. Therefore, it is important for a defect prediction method to estimate the severity of the identified bugs, so that the higher severity ones get immediate attention. In this paper, we provide a quantitative and qualitative study on two popular datasets (Defects4J and Bugs.jar), using 10 common source code metrics, and also two popular static analysis tools (SpotBugs and Infer) for analyzing their capability in predicting defects and their severity. We studied 3,358 buggy methods with different severity labels from 19 Java open-source projects. Results show that although code metrics are powerful in predicting the buggy code (Lines of the Code, Maintainable Index, FanOut, and Effort metrics are the best), they cannot estimate the severity level of the bugs. In addition, we observed that static analysis tools have weak performance in both predicting bugs (F1 score range of 3.1%-7.1%) and their severity label (F1 score under 2%). We also manually studied the characteristics of the severe bugs to identify possible reasons behind the weak performance of code metrics and static analysis tools in estimating the severity. Also, our categorization shows that Security bugs have high severity in most cases while Edge/Boundary faults have low severity. Finally, we show that code metrics and static analysis methods can be complementary in terms of estimating bug severity.
... Collaboration environments for programming within teams was highlighted 1980s (Constantine, 1995). But, by the end of 1990s, researchers start studying pair programming model as a programming methodology (Nawrocki and Wojciechowski, 2001). The pair programming was defined simply by allowing two programmers to collaborate together to solve a common task while they site in the same place; the first programmer is called driver and the second is called navigator (Arisholm et al., 2007;Begel and Nagappan, 2008;McDowell et al., 2002). ...
Internet-based tools and social media are greatly developed in the tech world. Today, technology is widely accepted and used by all generations. These tools are great and very useful for students in terms of learning, collaboration and information sharing. We aim to present a model for learning programming in social learning environments with the context of the Affinity Research Group (ARG) model. The proposed model is called "Learning Programming in Social Environments within Affinity Group (LPSEAG)". We test the proposed model for two academic years. A comparative approach was used. In the experiment, we divide the students into two categories: (1) Learn programming in the context of using the LPSEAG model, (2) Learn programming in the context of social media groups. Qualitative and quantitative results are compared for the two categories. From the results obtained it was clearly found that the students' satisfaction was high on working within a group using the LPSEAG model compared to the responses of students that use social media groups only. Moreover, the quantitative results supports the assumptions that the use of LPSEAG model in learning programming in the introductory programming courses enhances the learning outcomes. Learning programming in groups enhances the learning outcomes for students whatever the student's programming level. Teachers are encouraged to create students' programming groups and implement LPSEAG model to increase learning outcomes and facilitate learning environments for students over-distance. More researches are needed to develop CVLEs which encourage students to learn programming with teams over distance.
... We illustrate the EyeSAC system for an eye-tracking study on pair programming based collaboration [152] in which two participants were performing a coding task, with one being the Driver and the other being the Navigator [116,160]. ...
With great technological advancement, the scientific community is overwhelmed with the amount of data being produced. Thus, analyzing these data has become a crucial part of the decision-making process in almost all research fields, be it medicine, gaming, chemistry, physics, psychology, transportation, economics, and others. Challenges deepen when the generated data are multivariate in nature and we aim to analyze these data considering all the attributes simultaneously.
To address the specific challenges that come with analyzing multivariate volumetric data, we developed the RadVolViz tool for volume visualization. In volume visualization transfer functions are widely used for mapping voxel properties to color and opacity. RadVolViz uses a new method that applies to volume data with more than three channels using a multivariate information display that allows users to recognize the presence and value distribution of the multivariate voxels and the joint volume rendering display visualizes their spatial distributions.
Our work also addresses the analysis and visualization of eye-tracking data which are spatio-temporal in nature. The challenging issue with spatio-temporal data is the lack of a scalable visual encoding that conveys both the spatial and temporal aspects of data simultaneously. We propose an interactive visualization that comprises of three linked views depicting spatial, metrics-related, as well as distance-based aspects over time.
Further, we also analyzed eye-tracking data in scenarios such as strategic gaming, pair-programming, and visual exploration of metro maps and natural images to understand participants' behavior. To analyze collaborative scenarios using multiple eye trackers in pair programming, we developed the EyeSAC tool that synchronizes the data from different sources, interactively annotates them, and removes the noisy and missing gazes from eye-tracking data with the help of visual feedback from the external recording.
Analyzing eye-tracking data led to the conclusion that eye movement patterns are influenced by the observer's task. However, this claim has received mixed reactions from researchers, and to further validate our claim, we explored the interpretability of models used for such classifications. Since the interpretability of classification models designed for eye movement data comes with its own limitations and challenges, we briefly discuss them in our work and try to improve it in further study.
... We illustrate EyeSAC system for an eye tracking study on pair programming based collaboration [Villamor and Rodrigo 2017] in which two participants were performing a coding task, with one being the Driver and the other being the Navigator [Nawrocki and Wojciechowski 2001;Williams and Kessler 2002]. Using Pupil Labs glasses [Kassner et al. 2014], we recorded eye movement data for both participants using their head camera video mounted to their eye trackers. ...
Eye movement data analysis plays an important role in examining human cognitive processes and perceptions. Such analysis at times needs data recording from additional sources too during experiments. In this paper, we study a pair programming based collaboration using two eye trackers, stimulus recording, and an external camera recording. To analyze the collected data, we introduce the EyeSAC system that synchronizes the data from different sources and that removes the noisy and missing gazes from eye tracking data with the help of visual feedback from the external recording. The synchronized and cleaned data is further annotated using our system and then exported for further analysis.
... The GBOL stack contains over 80.000 lines of R and Java code, OWL and ShEx definition files, and documentation files (mkdocs format). Generating such a large amount of code would entail 1 year of manual work (considering an efficiency of 50 lines per hour) 44 . Moreover, during the development of the GBOL ontology countless updates were made to correctly encapsulate all the data and associated provenance. ...
The RDF data model facilitates integration of diverse data available in structured and semi-structured formats. To obtain a coherent RDF graph the chosen ontology must be consistently applied. However, addition of new diverse data causes the ontology to evolve, which could lead to accumulation of unintended erroneous composites. Thus, there is a need for a gate keeping system that compares the intended content described in the ontology with the actual content of the resource. The Empusa code generator facilitates creation of composite RDF resources from disparate sources. Empusa can convert a schema into an associated application programming interface (API), that can be used to perform data consistency checks and generates Markdown documentation to make persistent URLs resolvable. Using Empusa consistency is ensured within and between the ontology and the content of the resource. As an illustration of the potential of Empusa, we present the Genome Biology Ontology Language (GBOL). GBOL uses and extends current ontologies to provide a formal representation of genomic entities, along with their properties, relations and provenance.
... For example, dyads can use individual computers to do sideby-side programming or use a single computer to do pair-programming. Although collaborating side-by-side with individual computers is very common in classroom activities, this configuration is not studied as often as pair-programming and mostly studied with college-aged students (William et al., 2000;Nawrocki et al., 2001). In this paper, we utilize a mixed-methods approach to analyze a dataset of elementary students' side-by-side programming to discern each pairs' collaborative approach. ...
Collaboration is an effective pedagogical approach in programming instruction. In collaborative programming, students can participate in different types of collaborations settings. Dyads can use individual computers to do side-by-side programming or use a single computer to do pair-programming. However, collaborating side-by-side is not studied as often as pair-programming. In side-by-side programming, students collaborate side-by-side at individual computers but on a shared virtual programming platform. This article aims to explore characteristics of the side-by-side programming collaboration by the elementary level students. Utilizing a mixed-methods approach, we analyzed four dyads of elementary students’ interactions in side-by-side programming to discern each pairs’ collaboration approach. We found several patterns in the collaborative conversations of the dyads depending on how they responded to each other.
... The GBOL stack contains over 80.000 lines of R and Java code, OWL and ShEx definition files, and documentation files (mkdocs format). Generating such a large amount of code would entail 1 year of manual work (considering an efficiency of 50 lines per hour) [351]. The SBOL stack is a recently published platform for storing, publishing, and sharing synthetic biology designs [182]. ...
... The GBOL stack contains over 80.000 lines of R and Java code, OWL and ShEx definition files, and documentation files (mkdocs format). Generating such a large amount of code would entail 1 year of manual work (considering an efficiency of 50 lines per hour) [22]. Moreover, during the development of the GBOL ontology countless updates were made to correctly encapsulate all the data and associated provenance. ...
The RDF data model facilitates integration of diverse data available in structured and semi-structured formats. To obtain an RDF graph with a low amount of errors and internal redundancy, the chosen ontology must be consistently applied. However, with each addition of new diverse data the ontology must evolve thereby increasing its complexity, which could lead to accumulation of unintended erroneous composites. Thus, there is a need for a gatekeeping system that compares the intended content described in the ontology with the actual content of the resource. Here we present Empusa, a tool that has been developed to facilitate the creation of composite RDF resources from disparate sources. Empusa can be used to convert a schema into an associated application programming interface (API) that can be used to perform data consistency checks and generates Markdown documentation to make persistent URLs resolvable. In this way, the use of Empusa ensures consistency within and between the ontology (OWL), the Shape Expressions (ShEx) describing the graph structure, and the content of the resource.
... Pair programming and distributed pair programming is not necessarily a good fit in all situations as illustrated in Section 8. In fact, there is research that suggests pair programming does not provide any advantage as indicated by Nawrocki and Wojciechowski [3], Vanhanen and Lassenius [4], Arisholm et al. [5], Rostaher and Hericko [6], and Hulkko and Abrahamson [7]. Additional research to explain the discord may also be necessary. ...
Pair Programming¹ has quickly become a widespread technique for teams adopting Agile. The interest has gained even more popularity for those implementing Extreme Programming (XP) which is a well-known Agile methodology. There is a general agreement that pair programming works well with a pair of developers working side by side. However, that is not always possible. Distributed teams and distributed team members are becoming the norm. With that said, is distributed pair programming possible? And if so, can it be done effectively? This paper examines a project where distributed pair programming was extremely effective. Contrary to agile dogma, some individuals may perform better in a distributed manner over collocated.
... When REAP is greater than zero but less than 100%, the pair requires more total man hours but completes the tasks faster. The relative productivities of pair and solo programming have been the focus of much research (Nawrocki & Wojciechowski, 2001). ...
... Working in pairs is not new, but studying pair programming as methodology started by the end of 1990s. The authors of [13] reported that pair programming started gaining traction and popularity around 1995. ...
In this paper, we assess the effectiveness of an extension of Alice, named AliCe-VilLagE, which allows two students to work on the same project, with synchronous communication mechanisms and shared view of the same virtual working environment. The virtual environment supports multi-modal interactions among students (e.g., video, instant messaging). AliCe-ViLlagE collects statistics about each team members contributions, allowing for evaluation of the effectiveness of the collaborative environment, and supporting teacher’s assessment of the team work. The paper describes the first formal evaluation of the AliCe-ViLlagE platform with a group of undergraduate students. The results show impressive results in terms of number of interactions between the students, enabled by the AliCe-ViLlagE framework, levels of satisfaction of the students, and completion time.
... Nawrocki and Wojciechowski [16] emplearon 16 estudiantes como sujetos (5 parejas y 6 individuos) donde codificaron cuatro programas. Los autores no encontraron diferencias significativas entre la programación en pareja y la programación individual. ...
... Working in pairs is not new, but studying pair programming as methodology started by the end of 1990s. The authors of [18] reported that pair programming started gaining traction and popularity around 1995. ...
There is a growing literature demonstrating the importance of collaboration and teamwork in the process of learning computational thinking and the foundational aspects of computer science. While Collaborative Virtual Environments are becoming widespread in the software development professional domain and in various areas of advanced learning, their use in the introductory stages of learning computing is still very limited. On the other hand, in recent years, there has been a blooming of attractive programming environments specifically designed to expose young students (e.g., middle school age) to computational thinking. Alice is a very popular introductory programming environment, focused on programming through animations and story-telling. This paper introduces a novel extension of the Alice framework that enables interaction and collaboration among students in the development of programs. In particular, the new version of Alice described in this paper provides support for virtual pair programming. The modified version of Alice allows two students to remotely share a virtual world, and interact in its construction; the system supports roles assignments, to allow teachers to control activities and contributions of the two students in the creation of a programming project.
... Proponents of XP ascribe several benefits to software developers in a paired development setting over software developers in an individual development setting-enhanced learning (Williams, 2000), higher software quality (Nosek, 1998;Williams & Kessler, 2000), and greater satisfaction and confidence in the solution (Williams, 2000). However, the empirical evidence relating to the software quality benefits of paired development is at best mixed (Arisholm, Gallis, Dyba, & Sjoberg, 2007;Nawrocki & Wojciechowski, 2001). The distributed cognition theory (Flor & Hutchins, 1991) ascribes information processing benefits to pairs over individuals; for example, the ability to search through a larger space of alternatives, ready access to shared memory of old plans, and ability to jointly develop ambiguous code segments with fewer defects. ...
Our understanding of factors influencing the effectiveness of software-development processes has evolved in recent times. However, few research studies have furthered our understanding of the cognitive factors underlying software development activities and their impact on performance and affective outcomes. To some extent, this may be attributed to the paucity of measurement approaches available for cognitive factors. In this study, we fill this gap by developing a measurement approach to capture and evaluate the quality of mental models. We investigate the efficacy of mental models in software development using the said approach. We assessed mental model quality by statistically comparing a software developer’s mental model with a referent model derived from multiple experts. Results of a controlled laboratory experiment suggest that a software developer’s mental model quality is a determinant of software quality. Further, we found this effect to be consistent across software development tasks of varying complexities. These results not only shed light on the impact of mental models in software development, but also have significant implications for stimulating future research on cognitive factors influencing software development practices.
... PP não é uma prática nova. Ainda em 1995, Constantine [2] fez um dos primeiros relatos em que se observou o uso de emparelhamento de programadores no desenvolvimento de software [3]. Naquele mesmo ano, Coplien [4] publicou seu livro sobre processo de produção de software sugerindo um padrão organizacional de desenvolvimento emparelhado. ...
... Nawrocki and Wojciechowski [16] emplearon 16 estudiantes como sujetos (5 parejas y 6 individuos) donde codificaron cuatro programas. Los autores no encontraron diferencias significativas entre la programación en pareja y la programación individual. ...
Contexto: La Ingeniería de Software (IS) es una disciplina compleja donde a día de hoy el resultado de la aplicación de alguna tecnología para apoyar el desarrollo de software es impredecible. De manera similar a otras disciplinas ingenieriles, la IS requiere de construcción de modelos, experi-mentación y aprendizaje. La experimentación es un recurso va-lioso que permite evaluar de manera objetiva las distintas tecnologías disponibles para desarrollar software. Objetivo: Con la finalidad de promover el paradigma experimental en la IS, en este artículo se aplica el paradigma experimental para estudiar algunos efectos de la programación en pareja. Método: A través de un diseño experimental cuadrado latino con dos factores de bloqueo, se emplearon 21 estudiantes del programa de licen-ciatura en IS de la Universidad Autónoma de Yucatán (UADY) para examinar la duración y esfuerzo que conlleva la progra-mación en pareja. Los estudiantes se agruparon en 7 parejas y 7 individuos donde codificaron durante dos sesiones dos programas pequeños. Resultados: Los resultados del experimento sugieren una diferencia significativa (en un nivel α=0.1) en favor de la programación en pareja con respecto a la duración de codi-ficación de los ejercicios asignados (28% decremento en tiempo). Por el contrario, los resultados sugieren una diferencia signifi-cativa (en un nivel α=0.1) en favor de la programación individual con respecto al esfuerzo (30% decremento en esfuerzo). Conclu-siones: En este artículo se presenta el paradigma experimental aplicado a la IS. A través del paradigma experimental es posible obtener observaciones de manera objetiva para acumular un cuerpo de conocimientos que pueda ser usado de manera confía-ble por profesionales en IS.
The pandemic situation COVID-19 requires teachers to rethink some of the activities proposed to students since even though they are physically in the same room at the university, they cannot join and must maintain a social distance. The curricular unit of introduction to programming in the first year of computer courses requires several activities: students only learn by doing. One of the activities that has been used a lot in the academic community is pair programming: a single computer for two students working together. In the case that this article reports the pair works sharing a ZOOM room and alternates the position of driver (writes the code) with navigator (one that comments on the code). This article uses the technique of pair programming for writing top-down, algorithm and traces to verify the behavior of variables along the algorithm. If the pair programming technique has had very interesting results in terms of task speed and code quality far superior to programmers alone, there are some doubts about the problem of the constitution pf the groups. In this article we use two opposite strategies: group students with opposite knowledge or group students with similar knowledge. We found that students who prefer this activity are the worst ones (in both strategies) and the best students when grouped with colleagues with similar knowledge.
Emergence of instrumentation frameworks has vastly contributed to the software engineering practices. As the instrumentation use cases become more complex, complexity of instrumenting programs also increases, leading to a higher risk of software defects, increased development time, and decreased maintainability. In security applications such as symbolic execution and taint analysis, which need to instrument a large number of instruction types, this complexity is prominent. This paper presents an architecture based on the Pin binary instrumentation framework to abstract the low‐level OS and hardware‐dependent implementation details, facilitate code reuse in heavyweight instrumentation use cases, and improve instrumenting program development time. Instructions of x86 and x86‐64 hardware architectures are formally categorized using the Z language based on the Pin framework API. This categorization is used to automate the instrumentation phase on the basis of a configuration list. Furthermore, instrumentation context data such as register data are modeled in an object‐oriented scheme. This makes it possible to focus the instrumenting program development time on writing the essential analysis logics while access to low‐level OS and hardware dependencies are streamlined. The proposed architecture is evaluated by instrumenting 135 instruction types in a concrete symbolic execution engine, resulting in a reduction of the instrumenting program size by 59.7%. Furthermore, performance overhead measure against the SPEC CINT2006 programs is limited to 8.7%.
In regard with designing software, users play key role. In order to design software, it is necessary to observe standard principles of designation, using templates and using modern methods. Over the decades, using development methods, XP and one of the XP methodologies of paired programming used to design software. These methods have been designed for purpose of enhancing quality of product and rapidresponse to need of market and customer and overcoming weaknesses of traditional methods based on long-term programming and waterfall method. Therefore, every programmer and developer can pass a series of processes for constructing computer software. The processes can be changed daily and efficient processes maynot be effective and useful; although they can be considered as process. The main objective of the present study is multi-factor analysis of pair programming based on PSP methodology. Practical and analytical methodand two PSP methods have been applied for investigations.
Unbelievable, we have reached the seventh edition of the XP2k+n conference! We started at the outset of the new millennium, and we are still proving that agile pr- esses were neither a millennium bug nor a YAF (yet another fad). In its first editions, this conference was a get-together of a few pioneers who - bated about how to make agile processes and methods accepted by the mainstream researchers and practitioners in software engineering. Now agile approach to software development has been fully accepted by the software engineering community and this event has become the major forum for understanding better the implications of agility in software development and proposing extensions to the mainstream approaches. These two aspects were fully reflected in this year’s conference. They were - flected in the keynote speeches, which covered the background work done starting as early as the early eighties by Barry Boehm, definition of the field by Kent Beck, a successful industrial application in a success story by Sean Hanly, the perspective and the future of agile methods in large corporations by Jack Järkvik, and even some - sightful views from a philosopher, Pekka Himanen.
Currently there are several questions about the pair programming adopt. Is the pair programming more productive when compared to individual programming? When a company must adopt pair programming? To answer these questions the authors of this paper developed 7 controlled experiments, 4 of them in the academic environment and 3 in a software company. The experiments show that the pair programming should be used to production of code highly complex. Based on the results generated by the experiments, the authors of this study conclude that the pair programming should be adopted only in a business environment to solve problems (programs) complex. To detect the complexity problems the company has a defined and institutionalized software process.
Developing working software is a key goal of software development. Beyond software processes, following traditional or agile approaches, coding strategies, i.e., solo and pair programming, are important aspects for constructing high quality software code. In addition developer experience has a critical impact on coding efficiency and code quality. Pair programming aims at increasing coding efficiency, code quality, and supports learning of development team members. Several controlled experiments have been conducted to investigate benefits of different development strategies, learning effects, and the impact on code quality in academia and industry. Nevertheless, reported study limitations and various results in different contexts require more studies to fully understand the effects of experience and programming strategies. Coding contests can be promising approaches to (a) involve different participant groups, e.g., junior and senior programmers and professionals, and (b) can represent a well-defined foundation for planning and executing large-scale empirical studies. In this paper we present coding contests as a promising strategy for conducting empirical studies with heterogeneous groups of participants and report on a set of findings from past coding contests. Main results are (a) that the concept of coding contests is a promising way for supporting empirical research and (b) the results partly confirm previous studies that report on the benefits of pair programming and development experience.
This paper presents a study which synthesizes the various phases of software development and analyze the impact of pairing on each phases of the software development. The main aim of this paper is to find out whether pairing up of developers is required in all the phases of software development, or if there an alternate way to minimize the pair-up times between these developers, in order to maximize the resource utilization and reduce the development cost. The findings reported in this paper are part of a larger study conducted at the Auburn University during spring 2009 and the Alabama State University during summer 2012 and fall 2013 using computer science and software engineering seniors and graduate students. The empirical evidences show that pairing on the design phase and testing phase is beneficial and pairing on the coding phase is not beneficial. The results of this study point that equal quality programs can be produced by pairing up programmers only in the design and testing phases of the software development.
Are you attracted by the promises of agile methods but put off by the fanaticism of many agile texts? Would you like to know which agile techniques work, which ones do not matter much, and which ones will harm your projects? Then you need Agile!: the first exhaustive, objective review of agile principles, techniques and tools. Agile methods are one of the most important developments in software over the past decades, but also a surprising mix of the best and the worst. Until now every project and developer had to sort out the good ideas from the bad by themselves. This book spares you the pain. It offers both a thorough descriptive presentation of agile techniques and a perceptive analysis of their benefits and limitations. Agile! serves first as a primer on agile development: one chapter each introduces agile principles, roles, managerial practices, technical practices and artifacts. A separate chapter analyzes the four major agile methods: Extreme Programming, Lean Software, Scrum and Crystal. The accompanying critical analysis explains what you should retain and discard from agile ideas. It is based on Meyer's thorough understanding of software engineering, and his extensive personal experience of programming and project management. He highlights the limitations of agile methods as well as their truly brilliant contributions - even those to which their own authors do not do full justice. Three important chapters precede the core discussion of agile ideas: an overview, serving as a concentrate of the entire book; a dissection of the intellectual devices used by agile authors; and a review of classical software engineering techniques, such as requirements analysis and lifecycle models, which agile methods criticize. The final chapters describe the precautions that a company should take during a transition to agile development and present an overall assessment of agile ideas. This is the first book to discuss agile methods, beyond the brouhaha, in the general context of modern software engineering. It is a key resource for projects that want to combine the best of established results and agile innovations. © Springer International Publishing Switzerland 2014. All rights are reserved.
Collaborative learning has been used extensively in undergraduate education to improve learning for all students. To improve performance in computer science courses, our study incorporated a new, although related, pedagogical approach entitled Collaborative-Adversarial Pair Learning (CAPL). The CAPL employs a software development technique called Collaborative-Adversarial Pairs (CAP) to teach computer science courses. We have demonstrated that CAP is effective in helping engineers discover software requirements. It seems a natural extension to use the techniques of CAP to help students discover concepts in computer science. In this paper, we describe the design and implementation of a CAPL model for a computer programming course (Software Engineering I), and then present the results of an evaluation of the model when compared to traditional instruction in Software Engineering I.
Pair programming and peer code review are two collaborative inspection methods that improve the quality of software. These light-weight review techniques are low-cost alternatives to formal inspections and rigorous reviews that commonly remove 90% of software defects before even the first test case is run. While pair programming has many advocates, evidence suggests that pair programming is not as useful as claimed and the requirement of the pairs to co-locate is hindrance on many development projects. Peer code reviews, however, have been shown to be just as effective as pair programming and are a better fit for many of today's software efforts that are being developed collaboratively, but asynchronously, in the cloud. In this paper we demonstrate peer review's effectiveness as compared to pair programming in the context of Test Driven Development (TDD), a popular agile programming technique that's rapidly gaining mainstream acceptance. The empirical evidence also shows that equal quality programs can be produced at a lower cost (28% less than pair programming) using a peer review technique in TDD as compared with traditional pair programming
Pair programming is a programming technique in which a pair of people, a driver and an observer or navigator, complete a programming task using a single computer. The advocates of pair programming claim that it has many benefits over traditional individual programming, but the empirical evidence of the benefits of pair programming is mixed. Anecdotal and empirical evidence shows that pair programming is an expensive technology that is difficult to practice. In this study we propose an alternative model called Inverted Pair Programming (IPP). IPP pairs do not work together in all the phases of software development; instead, the pair starts by designing together, split apart during implementation, then join again for testing. Two empirical studies were conducted in spring 2009 and summer 2012 to validate the inverted pair programming against traditional pair programming. The results of this experiment point in favor of inverted pair programming methodology and do not support the claim that pair programming in general reduces the software development duration or overall software development cost.
Pair programming is a programming technique in which pair of people doing programming on a single machine. The programming pair consists of a driver and a navigator or observer. The driver addresses the operational issues; i.e., responsible for implementing the current module in hand. The navigator addresses the strategic issues; i.e., keeps in mind the strategic direction the code must take. Pair programming is a dynamic process and pairing aids the rapid dispersal of system knowledge through the team while developing it. Since most of the pair programming experiments were not conducted as described in extreme programming and the empirical evidence of pair programming is mixed we were not got the true picture about the impact created by pair programming on software development. In this paper, we evaluated the dynamic pair programming methodology with static pair programming and traditional individual programming. The empirical evidence shows that static pair programming is the most expensive and slower technology than dynamic pair programming and individual programming technologies. It also indicates that dynamic pair programming is the fastest software development methodology than static pair programming and traditional individual programming methodologies.
Pair programming is a software development technique with many cited benefits in learning and teaching. However, it is reported that novice programmers find several barriers to pairing up, typically due to the added communication that is required of this approach. This paper will present a literature review discussing the issue of communication, and through a series of observations with industry-based pairs, will derive a set of guidelines which aim to help novice pairs experience better communication within their pairs. An evaluation of the guidelines with undergraduate students is then reported, showing that exposure to these guidelines improved the self-perceived communication experience of novice pairs.
This article presents a technical opinion in the case of collaborative programming for a large, complex system, in which two programmers are working jointly on the same algorithm and code. A field experiment was conducted using experienced programmers who worked on a challenging problem important to their organization, in their own environments, and with their own equipment. Findings revealed that all the teams outperformed the individual programmers, enjoyed the problem-solving process more, and had greater confidence in their solutions. Several aspects of this experiment make the results significant. First, there may be a tendency to dismiss results using small groups. Questions may arise at the value of these results if the collaborators do not perform twice as well as individuals, at least in the amount of time spent. The article concludes that the crunch-time information systems development will demand innovative ways to produce high-quality systems in a short time, with companies increasingly introducing new products. This rare experimental research is phenomenon considering the luxury of using collaborative programming while many companies are experiencing shortages of experienced programmer/analysts.
A summary is presented of the current state of the art and recent trends in software engineering economics. It provides an overview of economic analysis techniques and their applicability to software engineering and management. It surveys the field of software cost estimation, including the major estimation techniques available, the state of the art in algorithmic cost models, and the outstanding research issues in software cost estimation.
The software industry has practiced pair programming (two
programmers working side by side at one computer on the same problem)
with great success for years, but people who haven't tried it often
reject the idea as a waste of resources. The authors demonstrate that
using pair programming in the software development process yields better
products in less time-and happier, more confident programmers