kode24 har tidligere fortalt om NAV sitt Infotrygd-system, som ble bygd i Cobol mellom 1976 og 1978 - og fortsatt kjører.
- Vi jobber med en ny løsning for saksbehandling og utbetaling av sykepenger, i parallell med den eksisterende løsningen, forteller NAV-utvikler David Steinsland til kode24.
Siden 2019 har denne jobben i stor grad blitt løst gjennom parprogrammering. Nøyaktig hvor stor del av jobben har de ikke tall på, men anslagene strekker seg langt over 90 prosent.
- En betydelig del av jobben vært utført i par eller i mobber, kan i alle fall Steinsland slå fast.
NAV mener nemlig at dette ikke tar mer tid enn tradisjonell utvikling - tvert i mot. Bare man vet hvordan.
Dette NAV-systemet har vært i drift siden 1978
Pusher rett til master
Da NAV-utviklerne i 2019 bestemte seg for å utvikle sykepenge-løsningen med parprogrammering, hadde de først og fremst to mål: Deling av kompetanse og flere øyne på koden før produksjon.
- Nå får vi "alt i ett", hevder Steinsland i NAV.
- Når man jobber to-og-to så diskuterer man kode hele tiden, og det er ikke behov for å ha pull requests eller lignende. Dette lar oss skrive koden og pushe rett på master og ut i prod, som gir en veldig kort feedback loop på endringene vi gjør, i motsetning til når endringer må vente på at noen får tid til å se på en pull request og utvikleren har byttet kontekst til en annen oppgave innen endringen er i prod.
Filtrerer ut haterne
- Noen utviklere synes parprogrammering er et mareritt, blant annet fordi de føler de må være alene for å få konsentrert seg. Hva gjør dere om en utvikler sier dette?
- Vi har flere på teamet som trenger fred og ro og tid for seg selv inniblant, og det får man. Poenget er at det å pushe kode til master som hovedregel skal skje i par, forklarer Steinsland.
- Hos oss er parprogrammering den eneste formen for onboarding, og i kombinasjon med et komplisert domene og tilhørende løsning og arkitektur, ville det nok ikke ha vært så lett å klare seg på egenhånd, legger NAV-utvikler Jakob Havstein Eriksen til.
- Vi er åpne om at parprogrammering er måten vi jobber på når vi snakker med folk som muligvis skal inn på teamet, sånn sett blir vel de som er veldig skeptiske til parprogrammering filtrert ut i det trinnet.
«Når et par får besøk av noen andre i Zoom-rommet, pleier vi å skru av skjermdelingen.»
Zoom og Slack
Som de fleste andre utviklere, har også NAV-gjengen holdt seg på hjemmekontor det siste året. Uten at det har satt noen stopper for parprogrammeringen:
- NAV har prøvd seg på blant annet Discord, Teams og Slack, men falt ned på Zoom for video, lyd og skjermdeling, blant annet på grunn av lydkvalitet og skalering.
- Gjennom faste såkalte "break-out"-rom kan de hoppe fram og tilbake mellom parene om de har spørsmål.
- Utviklerne kan også stille spørsmål på Slack, hvor flere enn utviklerne får det med seg. Dermed kan for eksempel en produkteier, jurist eller designer hoppe inn i de åpne Zoom-rommene for å diskutere problemet.
- NAV bruker også JetBrain sin Code With Me når de trenger å jobbe på samme kode.
- Når et par får besøk av noen andre i Zoom-rommet, pleier vi å skru av skjermdelingen, på samme måte som man gjerne snur seg vekk fra skjermen i et fysisk lokale, forteller Havstein Eriksen til kode24.
Parprogrammering:
- Funker bedre på hjemmekontor
Tips for parprogrammering
Gjennom å nesten utelukkende jobbe gjennom parprogrammering, har NAV-utviklerne opparbeida seg masse erfaring med hva som funker og ikke.
- Steinsland oppfordrer til lave skuldre, høy takhøyde, mye humor og god tålmodighet. - Ingen skriver, leser og forstår kode i samme tempo, som han sier.
- NAV-utvikler Kevin Sillerud tipser om å ta seg nok pauser. - Når man jobber solo får man ofte naturlige pauser, dette kan være vanskeligere å få til når man er to, sier han til kode24.
- De oppfordrer også til å bytte på hvem som styrer tastaturet - og å la dette ofte være den som har minst erfaring med den aktuelle koden. En annen god løsning kan være at en person skriver testen, pusher den som disabled og en annen skriver koden for å gjøre testen grønn, tipser Sillerud.
- Havstein Eriksen forteller at noen av NAV-utviklerne bruker en algoritme for å bytte på hvem som jobber sammen. - Jevnlig rotasjon er med på å øke kompetansedelingen, og i hjemmekontor-settingen er det bra å henge med forskjellige folk over tid, mener han.
«Man trenger ikke å gå all-in på parprogrammering!»
Ikke et kappløp
- Tar det ikke dobbelt så lang tid å kode noe, om man koder alt i par?
- I starten, jo. Men jo mer man jobber sammen, jo mer “synkroniserte” blir man og ting går fortere. Men det er også noe som heter at hastverk er lastverk — er det dumt om vi bruker litt lengre tid? Det er tross alt ikke en konkurranse i hastighet her, men kvalitet i det vi lager, svarer Steinsland.
- Om vi ikke jobber i en parprogrammerings-kontekst, er det veldig vanlig med code-reviews. Det tar tid å sette seg inn i den andre personens problem, og hva man har tenkt da man skrev koden. Det kan for eksempel være ting som ser rart ut ved første øyekast, som kanskje har en god grunn bak seg. Ved parprogrammering plukker man ofte opp dette når man skriver koden, legger Sillerud til.
Slik koda NAV ny dagpenge-løsning på tre dager
- Er det ikke lett for dere i NAV, med så store ressurser, å snakke om hvor fortreffelig parprogrammering er, og kanskje glemme at enkelte utviklere jobber i langt mindre team hvor parprogrammering ikke er spesielt aktuelt?
- Man trenger ikke å gå all-in på parprogrammering! I det forrige prosjekt jeg jobbet på var vi to utviklere, vi satt ofte å jobbet med en oppgave sammen om det var noe som var uklart eller vanskelig, svarer Sillerud.
- Det er jo heller ikke slik at to utviklere på samme oppgave fører til en halvering i fart.