European Software Control Metrics ESCOM 01 Experimental Evaluation

European Software Control & Metrics ESCOM’ 01 Experimental Evaluation of Pair Programming Jerzy Nawrocki, Adam Wojciechowski Poznan University of Technology Poznan, Poland J. Nawrocki, Experimental Evaluation. . Copyright, 2001 © Jerzy R. Nawrocki

Plan of the lecture Introduction Personal Software Process e. Xtremme Programming Description of the experiment Results Conclusions J. Nawrocki, Experimental

Introduction Pair programming Must be x==y if (x=y) z=0; Creator J. Nawrocki, Experimental Quality assurer

Introduction After some time. . How to test it? x-=y; else Quality assurer J. Nawrocki, Experimental Creator

Introduction Nosek’s experiment Write a script that performs a database consistency check. J. Nawrocki, Experimental

Introduction Nosek’s experiment Completion time (aver. ) 42 minutes 30 minutes J. Nawrocki, Experimental

Introduction Nosek’s experiment Completion time J. Nawrocki, Experimental Effort 100 % 71 % 143 %

Introduction Main weakness Only one short assignment (45’). ‘If several tasks each take an hour, combine them to form a larger task. ’ Kent Beck Extreme Programming Explained J. Nawrocki, Experimental

Introduction The Utah experiment 1 4 programming assignments 2 6 weeks 3 1 2 3 Completion time 100% . . . 50% - 60% 14 J. Nawrocki, Experimental . . . 14

Introduction Weak points 2 2 What was the process? What were the sizes? 3. . . 14 1 What were the assignments about? 1 What was the time in hours? What was the deviation in time and size? J. Nawrocki, Experimental 3. . . 14

Introduction About our experiment Aim: experimental evaluation of pair programming. XP-like process PSP-like process Fall semester 1999/2000; Poznan University of Technology, Poznan, Poland J. Nawrocki, Experimental

Plan of the lecture Introduction Personal Software Process e. Xtremme Programming Description of the experiment Results Conclusions J. Nawrocki, Experimental

Personal Software Process Incremental approach Design templates. Code & design reviews. Task planning. Schedule planning. Software size estimation. Test reports. Coding standard. Size measurement. Process Improvement Proposal. Time and defects are recorded. Defect type standard. J. Nawrocki, Experimental 3 2. 1 2 1. 1 1 0

Personal Software Process Requirements Planning Designing Coding Compiling Testing Postmortem J. Nawrocki, Experimental Product + data

Plan of the lecture Introduction Personal Software Process e. Xtremme Programming Description of the experiment Results Conclusions J. Nawrocki, Experimental

e. Xtreme Programming (XP) We applied: We didn’t apply: Pair programming. User stories. Test-centred quality assurance. An on-site customer representative. Simple solution. Planning game. Spike solutions. CRC cards. Keep moving. Continuous integration J. Nawrocki, Experimental

Plan of the lecture Introduction Personal Software Process e. Xtremme Programming Description of the experiment Results Conclusions J. Nawrocki, Experimental

Description of the experiment XP 2 XP 1 PSP XP-like pair programming Test-centred QA, Spike solutions PSP 0. 1 (time, defect & size measurement) J. Nawrocki, Experimental

Description of the experiment Programming assignments 1. Estimate the mean and standard deviation of a sample of n real numbers. 2. Calculate the linear regression parameters. 3. Count the logical lines in a program, omitting comments and blank lines. 4. Count the total program LOC, the total LOC in each object the program contains, and the number of methods in each object. C/C++ J. Nawrocki, Experimental

Plan of the lecture Introduction Personal Software Process e. Xtremme Programming Description of the experiment Results Conclusions J. Nawrocki, Experimental

Results Prog 1 Prog 2 Prog 3 Prog 4 There is almost no difference between XP 2 and XP 1. J. Nawrocki, Experimental

Results Prog 1 Prog 2 Prog 3 Prog 4 Pair programming is more predictable than individual one. J. Nawrocki, Experimental

Results Prog 1 Prog 2 J. Nawrocki, Experimental Prog 3 Prog 4

Results Prog 1 Prog 2 Prog 3 Prog 4 Pair programming leads to more stable solutions. J. Nawrocki, Experimental

Conclusions • XP-like pair programming appears less efficient than it is reported by J. T. Nosek and L. Williams et al. • Pair programming is more predictable one than individual one both in completion time and program size. • The experiment was restricted to relatively small programs (150 - 400 LOC). J. Nawrocki, Experimental