Skip to main content
Log in

Controlled experimentation on adaptations of pair programming

  • Published:
Information Technology and Management Aims and scope Submit manuscript

Abstract

The use of agile methods is growing in industrial practice due to the documented benefits of increased software quality, shared programmer expertise, and user satisfaction. These methods include pair programming (two programmers working side-by-side producing the code) and test-driven approaches (test cases written first to prepare for coding). In practice, software development organizations adapt agile methods to their environment. The purpose of this research is to understand better the impacts of adapting these methods. We perform a set of controlled experiments to investigate how adaptations, or variations, to the pair programming method impact programming performance and user satisfaction. We find that method variations do influence programming results. In particular, better performance and satisfaction outcomes are achieved when the pair programming is performed in face-to-face versus virtual settings, in combination with the test-driven approach, and with more experienced programmers. We also find that limiting the extent of collaboration can be effective, especially when programmers are more experienced. These experimental results provide a rigorous foundation for deciding how to adapt pair programming methods into specific project contexts.

This is a preview of subscription content, log in via an institution to check access.

Access this article

Price excludes VAT (USA)
Tax calculation will be finalised during checkout.

Instant access to the full article PDF.

Similar content being viewed by others

References

  1. J. Aiken, Technical and human perspectives on pair programming, ACM SIGSOFT Software Engineering Notes, 2003, pp. 244–254.

  2. M. Aydin, F. Harmsen, K. van Slooten, R. Stegwee, On the adaptation of an agile information systems development method, Journal of Database Management 16(4) (2005) 24–40. October/December.

    Google Scholar 

  3. K. Beck, Extreme Programming Explained. (Addison-Wesley, Boston, 2000).

    Google Scholar 

  4. B. Boehm and R. Turner, Using risk to balance agile and plan-driven methods, IEEE Computer, June 2003, pp. 57–66.

  5. B. Boehm, R. Turner, Balancing Agility and Discipline: A Guide for the Perplexed. (Addison-Wesley, Boston, 2004).

    Google Scholar 

  6. M. Biggs, Pair programming: development times two, InfoWorld, Framingham, July 24, 2000.

  7. F. Brooks, The Mythical Man-Month, 2nd Edition. (Addison-Wesley, Reading, MA, 1995).

    Google Scholar 

  8. M. Domino, R. Collins, A. Hevner and C. Cohen, Conflict in collaborative software development, in: Proceedings of the SIGCPR/SIGMIS 2003 Conference, Philadelphia, PA, April 2003.

  9. J. Erickson, K. Lyytinen and K. Seng, Agile modeling, agile software development, and extreme programming: the state of research, Journal of Database Management, 16(4), October/December 2005, pp. 88–100.

    Google Scholar 

  10. B. Fitzgerald, N. Russo and T. O’Kane, An empirical study of system development method tailoring in practice, in: Proceedings of the Eighth International Conference on Information Systems, December 2000, pp. 187–194.

  11. B. Fitzgerald, N. Russo and T. O’Kane, Software development tailoring at Motorola, Communications of the ACM 46(4) (2003) 65–70 April.

    Article  Google Scholar 

  12. N. Flor and E. Hutchins, Analyzing distributed cognition in software teams: a case study of team programming during perfective software maintenance, in: Proceedings of the Fourth Annual Workshop on Empirical Studies of Programmers, J. Koenemann-Belleveau et al. (eds.) Ablex Publishing, Norwood, NJ, 1991, pp. 36–59.

  13. A. Gopal, R. Bostrom and W. Chin, Applying adaptive structuration theory to investigate the process of group support systems use, Journal of Management Information Systems, 9(2), Winter 1992–1993, pp. 45–62.

  14. G. Hedin, L. Bendix and B. Magnusson, Teaching extreme programming to large groups of students, Journal of Systems and Software 74 (2005) 133–146.

    Article  Google Scholar 

  15. S. JEX, Organizational Psychology: A Scientist-Practitioner Approach. (John Wiley and Sons, Hoboken, NJ, 2002) pp. 65–90.

    Google Scholar 

  16. L. Lindstrom and R. Jeffries, Extreme programming and agile software development methodologies, Information Systems Management 21 (2004) 41–52.

    Article  Google Scholar 

  17. J. Manzo, The Odyssey and other code science success stories, CrossTalk–The Journal of Defense Software Engineering 15(10) (2002) 22–24 October.

    Google Scholar 

  18. P. McBreen, Questioning Extreme Programming. (Addison-Wesley, Reading, MA, 2003).

    Google Scholar 

  19. J. McGrath, Groups: Interaction and Performance. Prentice-Hall, Englewood Cliffs, NJ, 1984).

    Google Scholar 

  20. M. Muller and F. Padberg, On the economic valuation of XP Projects, in: Proceedings of the Ninth European Software Engineering Conference, September 2003, pp. 168–177.

  21. J. Nawrocki and A. Wojciechowski, Experimental evaluation of pair programming, in: Proceedings of the 12th European Software Control and Metrics Conference, ESCOM 2001, London, April 2001.

  22. J. Nosek, The case for collaborative programming, Communications of the ACM 41(3) (1998) 105–108 March.

    Article  Google Scholar 

  23. A. Parrish, R. Smith, D. Hale and J. Hale, A field study of developer pairs: productivity impacts and implications, IEEE Software, September/October 2004, pp. 76–79.

  24. M. Poole and G. DeSanctis, Use of group decision support systems as an appropriation process, in: Proceedings of the Twenty-Second Annual Hawaii International Conference on System Sciences, January 1989.

  25. M. Poole and G. Desanctis, Understanding the use of group decision support systems: the theory of adaptive structuration. In: C. Steinfeld and J. Fulk (eds.) Organizations and Communication Technology, (Sage, Newbury Park, CA, 1990) pp. 173–193.

    Google Scholar 

  26. C. Rolland and N. Prakash, A proposal for context-specific method engineering. In: S. Brinkkemper, K. Lyytinen and R. Welke (eds.) Method Engineering: Principles of Method Construction and Tool Support, (Chapman and Hall, Atlanta, 1996).

    Google Scholar 

  27. K. Siau, Information modeling and method engineering: a psychological perspective, Journal of Database Management, 10(4) (1999) 44–50.

    Google Scholar 

  28. D.I.K. Sjøberg, J.E. Hannay, O. Hansen, V.B. Kampenes, A. Karahasanovic, N-K. Liborg and A.C. Rekdal, A survey of controlled experiments in software engineering, IEEE Transactions on Software Engineering 31(9) (2005) 733–753 September.

    Article  Google Scholar 

  29. D. Turk, R. France and B. Rumpe, Limitations of agile software processes, in: Proceedings of the Third International Conference on eXtrememe Programming and Agile Processes in Software Engineering, Sardinia, Italy, 2002, pp. 43–46.

  30. D. Turk, R. France and B. Rumpe, Assumptions underlying agile software-development processes, Journal of Database Management 16(4) (2005) 62–87 October/December.

    Google Scholar 

  31. A. Venkatesh and N. Vitalari, An emerging distributed work arrangement: an investigation of computer-based supplemental work at home, Management Science 38(12) (1992) 1687–1706 December.

    Article  Google Scholar 

  32. L. Williams, R. Kessler, W. Cunningham and R. Jeffries, Strengthening the case for pair programming, IEEE Software, July/August 2000, pp. 19–25.

Download references

Author information

Authors and Affiliations

Authors

Corresponding author

Correspondence to Alan R. Hevner.

Appendices

Appendix I: Experimental tasks

Experimental Task I—Discount Invoice Module

This module is part of the invoice processing program for a retailer. In this module, any discounts for the customer are computed. At this retailer, there are two ways to earn a discount:

  1. (1)

    total-purchase-amount-discount—if the total amount of purchases, pre-tax, is greater than an established amount; and

  2. (2)

    product-specific-discount—if the total number of purchases of designated products is greater than a second, set number of purchases. This second type of discount is given to encourage sales of certain products.

If the customer’s purchases earn both types of discounts, the second, product-specific discount is computed first. If the second discount reduces the sale to below the set amount for the first discount, the customer does not get the first, total purchase amount discount.

These values are passed to this module:

  • Total1  = pre-tax total of the prices of one or more items purchased on the invoice

  • Total_num = total number of purchases of designated products

  • Total2 = total purchase price of purchases of designated products

  • Discount_level1 = established amount of total purchases required to earn a discount

  • Discount_level2 = established number of purchases of designated products required to earn a discount

  • Discount1 = percentage discount for total-purchase-amount-discounts

  • Discount2 = percentage discount for product-specific-discounts

You can assume that the values passed to this module do not include negative numbers or zeros, since the input is checked in the other module.

This module should return these values:

  • Total_discount1 = amount of total-purchase-amount-discount

  • New_total1 = new total purchase amount (that reflects the discount(s))

  • Total_discount2 = amount of product-specific-amount discounts

  1. a.

    Prepare a test data set with at least 10 cases for this module.

  2. b.

    Write the pseudocode for this module and check it for accuracy.

Experimental Task II—Sales Report Module

This module produces a sales report for a car dealership. For each car sold, the following information is stored in the SALES file, which is sorted by date and time of a car sale.

   

The sales manager wants a report on the first day of each month that lists total sales and commissions for each salesperson. There should be just one line for each salesperson, listing name, average commission, total sales for the previous month, and total commission amount. At the end of this list there should be a grand total of all sales and all commissions earned.

  1. a.

    For this module, the test data should be a SALES file with many records. Describe the test records you would put into the SALES file in terms of the number of records and their content.

  2. b.

    Write the pseudocode for this module and check it for accuracy.

Appendix II: Scoring templates

Rights and permissions

Reprints and permissions

About this article

Cite this article

Domino, M.A., Collins, R.W. & Hevner, A.R. Controlled experimentation on adaptations of pair programming. Inf Technol Manage 8, 297–312 (2007). https://doi.org/10.1007/s10799-007-0016-8

Download citation

  • Published:

  • Issue Date:

  • DOI: https://doi.org/10.1007/s10799-007-0016-8

Keywords

Navigation