Pair programming involves-two developers simultaneously collaborating with each other on the same programming task to design and code a solution. Algorithm design and its implementation are normally interwoven in that implementation often provides feedback to enhance the design. Previous controlled pair programming experiments did not explore the efficacy of pairs versus individuals in program design-related tasks separately from coding. Variations in programmer skills in a particular language or an integrated development environment and the understanding of programming instructions can mask the skill of subjects in program design-related tasks. Programming aptitude tests (PATs) have been shown to correlate with programming performance. PATs do not require understanding of programming instructions and do not require a skill in any specific computer language. Two controlled experiments were conducted, with full-time professional programmers being the subjects who worked on increasingly complex programming aptitude tasks related to problem solving and algorithmic design. In both experiments, pairs significantly outperformed individuals, providing evidence of the value of pairs in program design-related tasks.

article The benefits of collaboration for student programmers Share on Authors: Judith D. Wilson Computer and Information Sciences Department, Temple University, Philadelphia PA Computer and Information Sciences Department, Temple University, Philadelphia PAView Profile , Nathan Hoskin Computer and Information Sciences Department, Temple University, Philadelphia PA Computer and Information Sciences Department, Temple University, Philadelphia PAView Profile , John T. Nosek Computer and Information Sciences Department, Temple University, Philadelphia PA Computer and Information Sciences Department, Temple University, Philadelphia PAView Profile Authors Info & Claims ACM SIGCSE BulletinVolume 25Issue 1March 1993 pp 160–164https://doi.org/10.1145/169073.169383Online:01 March 1993Publication History 37citation1,414DownloadsMetricsTotal Citations37Total Downloads1,414Last 12 Months74Last 6 weeks11 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access

Abstract Compared to a decade ago, when the first comprehensive study was done in software maintenance, many changes have occurred in the practice of system development. Longitudinal data were obtained by using the same survey instrument, updated to reflect current practices, and sampling the same population. Comparing the current with 1977 results has helped to identify the persistent problems and issues as well as the emerging problems and issues. One of the important, but somewhat disturbing, conclusions is that maintenance problems are pretty much the same as during the 1970s (except for minor changes), despite advances made in structured methodologies and techniques. In terms of specific problems, personnel problems of maintenance programmers, i.e. turnover and availability, and programmer effectiveness problems, i.e. skills, motivation and productivity, have shown a rise, while problems associated with users' knowledge of computer systems have declined.

While validation of user requirements has become an important goal for information system designers, little empirical research has been done in this area. Many methodologies have been presented as the best procedures for achieving user validation of design. An attempt is made to consider four of these methodologies in four different experimental settings. In the four experiments, the following treatments were examined: HIPO (hierarchy plus input, process, and output) vs. system flowcharts; DFD (data-flow diagram) narrative; DFD vs. Warnier-Orr diagrams; and DFD vs. HIPO. The main result of all four experiments was that choice of design methodology had no effect on the level of user understanding of system requirements.>