The case for collaborative programming
Communications of the ACM
The impact of pair programming on student performance, perception and persistence
Proceedings of the 25th International Conference on Software Engineering
The collaborative software process(sm)
The collaborative software process(sm)
Extreme Programming Refactored: The Case Against XP
Extreme Programming Refactored: The Case Against XP
Experimenting with pair programming in the classroom
Proceedings of the 8th annual conference on Innovation and technology in computer science education
A Cognitive Model for Solo Programming and Pair Programming
ICCI '04 Proceedings of the Third IEEE International Conference on Cognitive Informatics
Extreme Programming Explained: Embrace Change (2nd Edition)
Extreme Programming Explained: Embrace Change (2nd Edition)
Pair programming productivity: Novice-novice vs. expert-expert
International Journal of Human-Computer Studies - Human-computer interaction research in the managemant information systems discipline
Crystal clear a human-powered methodology for small teams
Crystal clear a human-powered methodology for small teams
When does a pair outperform two individuals?
XP'03 Proceedings of the 4th international conference on Extreme programming and agile processes in software engineering
| Hi-index | 0.00 |
The role of pair programming process in software development is controversial. This controversy arises in part from their being presented as alternatives, yet it would be more helpful to see them as complementary software management tools. This paper describes the application of such a complementary model, software process fusion (SPF), in a real-world software management situation in China. Pair and solo programming are adopted at different stages of the process and according to the background of programmers, as appropriate. Unlike the usual practice of eXtreme Programming, in which all production code must written in pairs, all-the-time pair programming, the proposed model encourages programmers to design code patterns of their own in pairs and then to use these patterns to build sub-modules solo. The report finds that the longer team members work alone, the more code patterns they develop for reuse later in pairs.