Jag var själv en motståndare till parprogrammering från början, men är numera omvänd då jag av egen erfarenhet sett effekterna av det hela.
Om målet är att knacka ner så många rader kod man kan på en dag, gör två personer på varsitt håll detta snabbare än två personer vid samma dator. Men så går det inte till när man programmerar, även om många (programmerare också) tror att det är det de gör.
Ser man över en period, kommer en programmerare att vilja bolla idéer, göra design, få den konfirmerad av andra, diskutera vad kraven egentligen betyder, så småningom skriva kod, hitta buggar, rätta buggar, rätta fler buggar, osv. Bara en del av all tid går åt till att skriva själv koden. Det mesta är ju andra saker.
När man parprogrammerar gör man allt det här på en gång vid datorn i små små bitar. Det känns som man är mindre produktiv, eftersom man sitter längre tid (eventuellt) vid tangentbordet och dessutom är två, men räknat över en period sparar man tid, eftersom man gör design och förstår saker bättre när man är två, man kodar bättre och snabbare när man är två, man gör framförallt färre buggar när man är två, man gör snabbare felsökning och rättningar när man är två.
Frågan är då; går det dubbelt så fort när man är två med allt det här? Ja, faktiskt och ibland ännu fortare. Räknar man dessutom med den tid man sparar genom att andra inte drabbas av programmerarens misstag; felrapportmöten, testare, CMar, kunder m.fl. blir tidsbesparingen ännu större.
En kollega till mej (Mats Henricson) brukar påpeka att parprogrammering sprider kunskap om den kod som skrivs och vad som är sund programmering. Vill man ha ett företag där ett lite längre sjukdomsfall gör att en del av koden blir förlamad, eller ett företag där alla sitter på sin rum ensamma och skriver likadan halv-bra kod år efter år, ja då är parprogrammering fel grej. Vill man ha ett företag där alla lär sig hela tiden, och där man undviker att koden kollapsar för att någon blir sjuk eller säger upp sig, då är det parprogrammering som gäller.
Till sist får man dessutom ut en produkt av högre kvalitet. Om kvalitet är en nyckelegenskap borde det vara lätt att sälja in parprogrammering. Det går aldrig lika bra att testa in kvalitet i programkod (i efterhand) som att skriva kod med hög kvalitet från början. Det vet ju alla, inte minst testare och kunder.
Så om utvecklarna i en organisation känner sig oproduktiva när de parprogrammerar kanske man skall fråga dem hur de mäter produktivitet och koppla till detta. Man ska dock ha i minnet att antalet kod i sig självt inte är ett mått på produktivitet. I själva verket skriver man färre rader kod när man parprogrammerar eftersom man skriver bättre kod. Så man får titta på saker som är kopplade till det funktionsinnehåll man levererar (t.ex. velocity om man kör Scrum).
Till sist, parprogrammering är en vana man tillägnar sig. Det finns många saker som gör det svårt för en del att börja. Inte minst att du måste förklara vad du håller på med för den som sitter bredvid. För en del är det pinsamt, eftersom de helt enkelt provar sig fram (vilket inte behöver vara fel i alla lägen). Dessutom får man ju omedelbar kritik av den som sitter bredvid och alla kan inte ta det sådär direkt.
Innan man blir bra på parprogrammering tar det ett tag. Man kan inte köra att par dagar och sedan säga något om effekterna. Det tar ett par veckor innan man börjar bli en van parprogrammerare, men det är ju bara en halv sprint!
Dessutom är parprogrammering socialt – helt enkelt bra mycket roligare än att sitta ensam på sitt eget rum hela dagen.
Enda nackdelen jag tycker mig ha sett är att det är ansträngande. Man kan vara rätt utpumpad efter en dags intensiv parprogrammering.
Håller med om att man blir utpumpad. Om den ene slappnar av så är den andre redan på gång med nästa moment.
Har noterat en stor fördel i att man lär sig så mycket av den andre.
Det viktigaste är att komma bort från känslan av att det är genant att prova sig fram och göra fel. Lite självironi skadar inte.
En länk: http://edgehopper.com/pairing-for-quality/