Effects of Pair Programming at the Development Team Level

Effects of Pair Programming at the Development Team Level

HELSINKI UNIVERSITY OF TECHNOLOGY Department of Computer Science and Engineering JARI VANHANEN Effects of Pair Programming at the Development Team Level: An Experiment Licentiate thesis submitted for official examination for the degree of Licentiate in Technology. Espoo, 27.05.2005 Instructor: Casper Lassenius Supervisor: Casper Lassenius HELSINKI UNIVERSITY OF TECHNOLOGY ABSTRACT OF LICENTIATE THESIS Department of Computer Science and Engineering Author Date Jari Vanhanen 27.05.2005 Pages 48 Title of thesis Effects of Pair Programming at the Development Team Level: An Experiment Professorship Professorship Code Software Engineering T-76 Supervisor Casper Lassenius Instructor Casper Lassenius Pair programming is an intensive form of programmer collaboration where two programmers design, code and test software collaboratively at one computer. Pair programming has been proposed to provide several benefits for software development. This work studied the effects of pair programming for productivity, defects counts, design quality, knowledge transfer, enjoyment of work, and effort estimation accuracy. The research consisted of an experiment with five four-person teams each doing a 400-hour project based on the same specifications, technologies and process guidelines. The only difference between the teams was that three of the teams used pair programming for all development work and the other teams used solo programming. In the experiment pair programming increased the development effort of the first few use cases, but after that there were almost no differences in the use case efforts compared to solo programming. Surprisingly, higher use case complexity did not favor pair programming. Due to the less productive learning time the pair programming teams had worse overall project productivity. However, in an industrial context the causes for the learning time are usually avoided, because developers already know each other and after the first pair programming project are already familiar with the practice. Even if there still were learning time involved, its effects become negligible in a large project. The pair programming teams had less pre-delivery but more post-delivery defects. Their attitude towards system testing might have been less careful due to an over-reliance on the peer review taking place during coding. Our efforts at contrasting the resulting design quality were inconclusive. Pair programming improved both the breadth and depth of knowledge transfer. In the pair programming teams each code package was understood well by more developers than in the solo programming teams. On the average developers in the pair programming teams also understood well more packages than developers in the solo programming teams. About half of the developers in the pair programming teams favored solo programming over pair programming, but still most developers liked working in the pair programming teams. Thus developers’ feelings toward pair programming should not hinder deploying pair programming. The pair programming teams were slightly better in estimating efforts required for implementing externally specified use cases early in the project. However, when updating the effort estimate just before the implementa- tion of a use case, solo programmers were accurate more often than pairs. These results certainly shed some more light on the topic, even though this experiment, like all the previous ones, contained many deficiencies such as the small sample size. Based on the results, it seems that the use of pair programming leads to fewer defects in code after coding and better knowledge transfer within the development team without requiring additional effort if the learning time can be avoided. These benefits are likely to decrease the further development costs of the system and increase an organization’s productivity due to improved competence of the developers. Keywords: pair programming, programming practices, software engineering experiment TEKNILLINEN KORKEAKOULU LISENSIAATINTUTKIMUKSEN Tietotekniikan osasto TIIVISTELMÄ Tekijä Päiväys Jari Vanhanen 27.05.2005 Sivumäärä 48 Työn nimi Koe pariohjelmoinnin vaikutuksista tiimikontekstissa Professuuri Professuurin koodi Ohjelmistotuotanto T-76 Työn valvoja Casper Lassenius Työn ohjaaja Casper Lassenius Pariohjelmointi on ohjelmoijien välistä intensiivistä yhteistyötä, jossa kaksi ohjelmoijaa suunnittelevat, koodaavat ja testaavat ohjelmistoa yhdessä yhden tietokoneen ääressä. Pariohjelmoinnin on esitetty tarjoavan useita hyötyjä ohjelmistokehitykselle. Tämä työ tutki pariohjelmoinnin vaikutuksia tuottavuuteen, virhemääriin, koodin rakenteen laatuun, tiedon siirtymiseen, työtyytyväisyyteen ja työmäärien arviointitarkkuuteen. Tutkimus koostui kokeesta, jossa viisi neljän hengen ryhmää tekivät kukin 400 tunnin projektin perustuen samoihin määrittelyihin, teknologioihin ja prosessiohjeisiin. Ainoa ero asetelmassa ryhmien välillä oli se, että kolme ryhmistä käytti pariohjelmointia kaikkeen kehitystyöhön, kun taas muut ryhmät käyttivät yksinohjelmointia. Kokeessa pariohjelmointi suurensi kehitykseen käytettyä työmäärää muutamien ensimmäisinä toteutettujen käyttötapauksien kohdalla, mutta sen jälkeen erot käyttötapauksiin käytetyissä työmäärissä verrattuna yksinohjelmointiin olivat mitättömiä. Yllättäen pariohjelmoinnin vaikutukset työmääriin eivät olleet suotuisampia monimutkaisempien käyttötapauksien kohdalla. Pariohjelmoinnin vaatiman tuottavuudeltaan tehottomamman opetteluajan takia pariohjelmointiryhmien projektitason tuottavuus oli huonompi. Kuitenkin teollisessa ympäristössä opetteluaika tavallisesti vältetään, koska kehittäjät tuntevat toisensa ja viimeistään ensimmäisen pariohjelmointiprojektin jälkeen osaavat myös pariohjelmointia. Vaikka opetteluaikaa ei voitaisiinkaan välttää, niin isossa projektissa sen vaikutukset tuottavuuteen ovat olemattomat. Verrattuna yksinohjelmointiryhmiin pariohjelmointiryhmien ohjelmissa oli vähemmän virheitä ennen toimitusta, mutta toimituksen jälkeen jäljelle jääneiden virheiden määrä oli suurempi. Pariohjelmointiryhmät mahdollisesti luottivat liikaa koodauksen aikana parin toimesta tapahtuvaan koodin katselmointiin ja olivat siksi järjestelmätestauksessaan huolimattomampia kuin yksinohjelmointiryhmät. Mahdollisiin eroihin designin laadussa eivät tuloksemme anna selkeää vastausta. Noin puolet kehittäjistä pariohjelmointiryhmissä sanoivat pitävänsä enemmän yksinohjelmoinnista kuin pariohjelmoinnista, mutta kuitenkin useimmat kehittäjät pitivät työskentelystä pariohjelmointiryhmissä. Siten kehittäjien tuntemuksien pariohjelmoinnista ei pitäisi olla pariohjelmoinnin käyttöönottoa estävä tekijä. Pariohjelmointiryhmät olivat hieman parempia arvioimaan ulkopuolisten kuvaamien käyttötapauksien vaatimia työmääriä projektin alussa. Kuitenkin, kun verrattiin juuri ennen toteutusta toteuttajan toimesta tehtyjä päivitettyjä työmääräarvioita, yksinohjelmoijat olivat tarkkoja arvioissaan useammin kuin parit. Nämä tulokset varmasti valaisevat aihetta hieman lisää, vaikka tämä koe kaikkien aikaisempien kokeiden tapaan sisälsi monia heikkouksia kuten otoksen pieni koko. Tulosten perusteella vaikuttaa siltä, että pariohjelmoinnin käyttö vähentää koodauksen jälkeen koodissa olevia virheitä ja lisää tiedon siirtymistä ryhmän sisällä vaatimatta enempää työtä, jos opetteluun kuluva aika saadaan vältettyä. Nämä hyödyt saattavat vähentää jatkokehityskustannuksia ja lisätä organisaation tuottavuutta kehittäjien parantuneen ymmärryksen myötä. Avainsanat: pariohjelmointi, ohjelmointikäytännöt, ohjelmistotuotannon koe Acknowledgements IV Acknowledgements This research was done at the Software Business and Engineering Institute (SoberIT) at the Helsinki University of Technology during the SEMS and SHAPE research projects. Many people participated in the planning, preparation and execution of the experiment reported in this thesis. Timo Jalonen and Matti Kokkola did great work in the prepara- tions for the course, where the experiment took place. They defined the requirements for the assignment project, developed the core architecture, and gave lectures about J2EE. Mikko Rusama familiarized himself with several development tools needed in the project and lectured about them. Several discussions about pair programming experiments with Asko Seeba and Priit Salumaa at the XP2003 conference were valuable for the initial planning of this experiment. Finally, the experiment could not have been conducted without the students, who participated in the course T-76.633 in the spring of 2004. I’m very grateful to all these people for their contribution. I also want to thank professor Casper Lassenius and all the other members of the Software Process Research Group at SoberIT for their support during this work. Especially Kristian Rautiainen gave important feedback through reviewing certain parts of the work in progress. Finally, I want to thank my wife Heidi for the constant love and support she has given me. Espoo 27.5.2005 Jari Vanhanen Contents V Contents 1 INTRODUCTION ....................................................................................................... 1 1.1 Motivation........................................................................................................................................1 1.2 Terminology.....................................................................................................................................1 1.3 Objectives and scope of the research..........................................................................................2

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    74 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us