Parprogrammering – Kan To Hoder Skrive Bedre Kode(r)?  

21. august 2024

Parprogrammering er en teknikk i programvareutvikling hvor to programmerere jobber sammen på én maskin eller editor for å skrive kode. Dette er en velkjent smidig metodikk som kanskje ikke blir brukt så ofte som det burde. Tradisjonelt har det vært vanlig at den ene parten skriver koden mens den andre parten overvåker og tenker høyt, og at rollene byttes på jevnlig. Nå til dags finnes det verktøy som kan gjøre denne prosessen enklere, slik at flere kan redigere samtidig. Dette gjør også at rollene er mindre definerte, i og med at «rollebyttet» skjer mye hyppigere. Det er litt uenighet i hvilke tilfeller parprogrammering skal brukes. I dette blogginnlegget tar jeg for meg noen fordeler og ulemper ved bruk av denne teknikken.  

Fordeler ved parprogrammering:  

Deling av kunnskap
Det jeg personlig mener er det viktigste punktet i parprogrammering er deling av teknisk kunnskap. Å observere og samhandle med andre i en jobb vil naturlig gi god innsikt i andres arbeidsmetoder, problemløsningsstrategier, snarveier og generell teknisk kunnskap.

Kanskje enda viktigere er delingen av domenekunnskap. Det er naturlig at to som parprogrammerer sammen har litt ulik kunnskap man tar i bruk i selve prosjektet. Mye av gevinsten ligger ikke bare i deling av hva man kan fra før, men det at flere enn én person får kunnskap om den nye koden som produseres. Flere i teamet vil ha kjennskap til mange deler av kodebasen. Dette vil gjøre det enklere i fremtiden hvis man skal håndtere koden, om det så skulle være en ny integrasjon, erstatning, feil eller endringer. Dette øker fleksibiliteten i hvem som kan jobbe med hva, og man er ikke avhengig av den ene personen som kanskje er syk, på ferie eller som har sluttet i teamet. Det blir også lettere å diskutere og sparre med noen dersom man skal jobbe med koden senere.  

Særlig nyttig er kunnskapsdelingen for dem som er nye i teamet eller i jobben. Dette gjelder teknisk kunnskap, men også særlig deling av domenekunnskap. Jeg tror et resultat av dette vil være en mye raskere onboardingsprosess. Den nyansatte får god innsikt i hvordan teamet jobber, hvilke tekniske løsninger som brukes og det blir lavere terskel for å stille spørsmål. Av egen erfaring er det lettere å få oversikt når man begynner å jobbe, lete og skrive i kodebasen. Å kun få en teoretisk innføring i prosjektet i form av powerpoint-presentasjoner eller lenker til sider på Wiki kan fort bli mye abstrakt informasjon når man er ny. Jeg tror tiden man bruker på å sitte med en som er ny i teamet vil være godt tjent inn senere.  

Standardisering og kodekvalitet
Tett samarbeid fører til at man utvikler en felles forståelse og praksis. Kodebasen vil være mer lettleselig da begge partene som deltar i produksjonen skal ha det klart for seg og man kontinuerlig tilpasser så partneren forstår. Ved å rotere partnere i forskjellige oppgaver vil man alltid kunne føre best praksis videre og alle vil lære litt av hverandre. 

Det at noen overvåker koden som skrives vil øke kodekvaliteten betraktelig. Dette kan også føre til at testfasen blir enklere, da feil vil oppdages tidligere. En studie fra NASA (1) fant at koden som ble skrevet under parprogrammering var mer lettleselig og bestod av omtrent halvparten så mange linjer som koden som ble skrevet uten parprogrammering. Dette skyldes effekten av kontinuerlig refaktorering og kodegjennomgang som naturlig oppstår når man er to.  

Sosialt samspill
Parprogrammeringen kan fremme bedre kommunikasjon mellom utviklerne i teamet. Særlig med mye hjemmekontor vil det sette terskelen lavere for å ta kontakt. Det sosiale aspektet er viktig for mange i arbeidet. I jobben som utvikler hører det med at man sitter mye for seg selv i egne tanker. Det er velkjent at sosial interaksjon er viktig for psyken og velvære. Det er også studier som viser direkte korrelasjon mellom sosial interaksjon og et teams ytelse (2). Sterkere relasjoner og bedre kjennskap til medarbeideres styrker og svakheter gjør det lettere å samarbeide og løse problemer. 

Økt fokus
Samarbeid i parprogrammering kan bidra til økt fokus. Når man diskuterer og løser et problem aktivt sammen er man ofte mer engasjert. Særlig i hjemmekontormiljøer tror jeg dette kan hjelpe til å redusere distraksjoner. Når man jobber tett med noen er det mindre sannsynlig at man blir fristet til å sjekke nyheter, lyden som plinget på telefonen eller e-posten som du kanskje ikke trengte å svare på akkurat nå.

 

Ulemper ved Parprogrammering:  

Lavere produktivitet
Parprogrammering kan redusere produktiviteten målt i linjer kode produsert per time. Dette gjelder i stor grad på kort sikt, da det er mer tidkrevende diskusjoner, forklaringer og refaktoreringer. I situasjoner hvor rask koding og utrulling er kritisk, kan det være langt mer effektivt å jobbe alene, til tross for at koden sannsynligvis vil ha lavere kvalitet. 

Begrenset selvstendig tenkning
Det kan være at man begrenser seg selv når noen andre sitter og ser på, som kanskje har mer erfaring. En mer erfaren utvikler kan fort ta for mye kontroll og bestemme ting uten at den andre parten får tid til å tenke seg om. Dette kan hemme personlige problemløsningsevner. Personlig lærer jeg mye av å stange på et problem til jeg finner ut av det selv. Dette gir ofte en dypere forståelse av hvorfor ting fungerer som det gjør, enn at man bare vet at noe fungerer. Det er viktig å gi begge parter tid til å tenke og bidra, slik at man kan lære og vokse. Dette er ikke alltid like lett.

Mentalt krevende
Å jobbe tett med en annen person krever konstant fokus og kommunikasjon, noe som kan være mer mentalt slitsomt enn å jobbe alene. Folk trenger ulik tid til å prosessere informasjon. Konstant prat, høyt fokus og forklaringer kan være krevende, og kan føre til kortere utholdenhet. 

Tidskoordinering
Det kan i tillegg være utfordrende å synkronisere tidsplaner, spesielt når utviklere har ulike møter, private forpliktelser eller jobber på forskjellige prosjekter og tider på dagen. Dette kan føre til ineffektivitet og vanskeligheter med å finne passende tidspunkter for parprogrammering. Det kan også være viktig å ha noe annet å kunne jobbe med mellom øktene. Dessverre kan det fort bli sporadisk og ujevn tidsfordeling på de andre oppgavene du har påtatt deg. Om du for eksempel er midt i et prosjekt hvor du har parprogrammert og partneren blir syk i to dager, kan det være du må finne noe annet å gjøre. Når partneren din kommer tilbake har du da to prosjekter du er halvveis i, og må sette soloprosjektet på vent igjen. Slike koordineringsproblemer kan gjøre parprogrammering vanskelig i større skala. 

Ikke feilfritt
Selv om parprogrammering kan fjerne mange feil og heve kodekvaliteten, kan det også skape en falsk trygghet. Det er fort gjort å bli mindre kritisk til koden når man vet at den er sett over av en annen underveis. Hvis ikke partneren/observatøren har sagt noe, så stoler man kanskje på at alt er riktig. I motsetning til hvis man står ansvarlig for koden helt alene, hvor man kanskje har mindre tiltro til at alt er OK. Parprogrammering brukes i noen tilfeller som en erstatning for kodegjennomgang, men uansett hvor mange som har utviklet noe sammen tror jeg at det alltid er lurt å ha en kodegjennomgang med eksterne ferske øyne. 

Konklusjon  

Parprogrammering har både betydelige fordeler og ulemper. Det fremmer kunnskapsdeling, bedre kodekvalitet og samarbeid, men kan også være mentalt krevende og redusere produktiviteten på kort sikt. For å lykkes med parprogrammering er det viktig med god planlegging og tilrettelegging. Det viktigste er å se på det som et verktøy, ikke en «be-all end-all» universalløsning som skal tvinges gjennom i hver kodeblokk som skal produseres. Jeg tror tre gode steder å bruke parprogrammering er i produksjon av nye komponenter, i opplæring og ved endring av eksisterende komponenter hvor den ene parten ikke er kjent med domenet. Hvis man klarer å bruke parprogrammering der det er hensiktsmessig tror jeg et man kan oppnå et mer effektivt og kunnskapsrikt team. Jeg tror det er viktig å legge parprogrammeringen til sesjoner som ikke er for lange, for å unngå tapt fokus og gi rom for egen tenking.  

Men ellers er mitt svar ja. To hoder skrive bedre kode(r).  

 

(1) https://fun3d.larc.nasa.gov/papers/exploring_xp.pdf
(2) https://mpra.ub.uni-muenchen.de/117042/1/20230412WP.pdf