Code Camp 09

Det blir alltid litt småprat med gjester og ansatte under frokosten på overnattingsstedet vårt. Alle synes tydeligvis det er artig å ha tre systemutviklere fra Norge på besøk i Oregons dype skoger, og tonen begynner å bli spøkefull. “Yesterday we were hunting cougards with our bare hands!”. Det blir stille etter at Kjell Arne har svart på spørsmålet fra en av gjestene om hva vi hadde gjort kvelden før.  “Cougar” betyr Puma og det finnes mange av dem i dette området. Det virker allikevel som om Kjell Arnes forsøk på en åpenbar jaktskrøne ikke blir helt forstått. Hvorfor alle blir helt stille skjønner vi først etter at vi har satt oss i bilen. Det viser seg at Cougar også kan ha en helt annen betydning på engelsk.

Kent ler høyt, hikster og slår seg på låret når vi forteller historien. “That’s not lost in translation – that’s found in translation” sier han mens vi lader opp til avslutningsdag med nykvernet kaffe under brygging. Er det noe Kent tar seriøst, så er det kaffe og programmering. Og gitaren. “Jeg skulle egentlig bli musiker og studerte klassisk gitar på underversitetet i flere omganger. Plutselig en dag var kjæresten min blitt gravid, og spørsmålet om hva jeg skulle gjøre ble mye enklere.” Vi ler og tenker inni oss at det var enda godt hun ble gravid …

“Så, har dere tenkt på hvordan dere vil tilbringe siste dag?” spør Kent. Målet med turen var å lære mest mulig om systemutviklingsfaget, gjennom å ha et reelt utviklingsprosjekt å jobbe på. Vi har vært gjennom en rekke øvelser, parprogrammeringsrunder og diskusjoner og føler selv vi har begynt å få god forståelse av Individuell Plan, produktet vi skulle jobbe med. Med denne fremgangen i mente foreslår Kent at vi bruker siste dag på programmeringsmessige utfordringer.

Først ut er gjennomgang av JUnit – rammeverket for testdrevet utvikling, skrevet av Kent sammen med Erich Gamma og David Saff. Erich Gamma er også en av hovedpersonene bak begrepet Design Patterns og det enormt populære utviklingsverktøyet Eclipse. Vi er i godt selskap.

Kent begynner med å påpeke forskjellene under panseret på versjon 3 og versjon 4 av JUnit. Oppbygningen av versjon 3 er forøvrig beskrevet i deres Cook’s tour av systemet (“Cooks tour” henspeiler på den omvisningen man gir kokken på på et kjøkken – altså der hvor detaljer og bakenforliggende ting står i fokus). Driver du med programmering til daglig kommer du garantert til å lære noe av å lese denne. Han forklarte hvilke konsekvenser de hadde sett av sitt opprinnelige design, og hvorfor de hadde skrevet om viktige deler av systemet. Det var krevende stoff, spesielt når han kom inn på enhetstester til et rammeverk for enhetstester.. Og dette var også en viktig brikke for å bygge vår egen helhetsforståelse: Å dykke ned i bits and pieces og forstå kompleks programkode, som har utviklet seg over lengre tid og kontinuerlig har blitt justert og forbedret.

En av tingene som har blitt stående som et begrep i denne uken var funksjonen ved navn “xxx”. Man trenger ikke være programmerer for å forstå at dette er et forferdelig dårlig navn på en funksjon. Allikevel skrev jeg den på et tidspunkt sammen med Kent, som foreslo dette navnet fordi vi var usikre på hva den burde hete. Det var et fantastisk frigjørende øyeblikk. Med ambisjoner om å alltid skrive den perfekte kildekode konfronterte Kent oss med det han så på som uønsket optimalisering. Han kaller det for mikrooptimalisering, og i vår verden er den ustoppelige jakten på perfekte kildekoden en av de vanligste. Vi programmerere elsker å måle hverandre på hvor stilig kode vi skriver. Selv når vi skriver prototyper (slik vi har gjort med Kent nå) eller andre programsnutter der helt andre aspekter som hurtig tilbakemelding fra sluttbruker, eksperimenter eller utprøvninger står i fokus. Hvem tør vel å sjekke inn grisete kode til versjonskontroll?

Jeg påpeker for Kent at dette er et kontroversielt syn for mange og han responderer kontant: “I don’t look for controversy. I tell the truth and become controversial”. Som systemutvikler er det en del av jobben å forstå når det er riktig å bruke tid på detaljene, som f.eks. leselig kildekode som følger kjente anbefalinger, og når det er riktig å fokusere på andre aspekter. En utvikler som alltid kritiserer kildekode han ikke liker, uten først å forhøre seg om hva som var avveiningene bak koden, risikerer å skape mye unødvendig støy. På samme måte som en utvikler som alltid skriver grisete programkode. Og dette gjelder ikke bare programkode; det kan generaliseres til alt vi lager og gjør. Overdreven programvarearkitektur, som gjerne designes tidlig i prosjektløpet, er også noe å være oppmerksom på sier Kent, og henviser til sin artikkel Patterns Generate Architectures.

Når man begynner å tenke på det, ser man mikrooptimalisering overalt rundt seg, både på personlig plan, i jobbsammenheng og på samfunnsnivå. Hvorfor måler mange selskaper utviklingsavdelingens produktivitet ved å se på antall linjer kildekoder de har skrevet? Vi vet jo alle at det motsatte – minst mulig kildekode – er det beste for helheten. Hvorfor måler mange kunder antall timer en konsulent har jobbet når man egentlig er ute etter mest mulig effektivt arbeid? Hvorfor leverer mange programvare i en slik hastighet at de trenger et eget system til å registrere alle feilene som oppstår under utviklingen?

Det er makro-optimalisering som gir konkurransekraft. Og da må man forstå helheten. Ledere uten erfaring fra felten, systemutviklere uten forretningsforståelse, sluttbrukere uten overordnede målsetninger. Ingen av disse vil være i stand til å makro-optimalisere.

Det krever mye erfaring å identifisere mikrooptimalisering. Noen ganger er det nettopp blankpolert, perfekt kildekode vi trenger. Andre ganger er det helt andre mål for det vi holder på med. “Men hvordan skal man forklare dette til en som skal lære seg å programmere? Blir de ikke bare totalt forvirret av at man noen ganger skal skrive den perfekte koden og at det andre ganger er greit å legge igjen løse tråder?” spør vi forundret. Kent humrer: “Welcome to programming!”

Det er altså siste dag på Code Camp og Kent er i storform. Vi begynner å kjenne hverandre nå, og de diplomatiske og høflige kommentarene har gått over i direkte tale. “Get rid of those d$%&! brackets, Morten!”,  gliser Kent mens han forfekter en annen programmeringsstil enn den vi er vant med. Vi tillatter oss så smått noen frekke kommentarer i retur, og det resulterer i konstruktivt munnhuggeri og alltid til slutt med at vi blir parkert trygt og godt tilbake i stolen..

Det har vært en intens uke, og vi kommer nok til å trenge tid på å fordøye alt. Det best av alt har nok vært følelsen av å se eXtreme Programming og Kent Beck fra innsiden. Vi har ikke fått med oss en eneste sjekkliste, ingen oppskrifter og ingen “best practices”. Akkurat nå sitter vi med flere spørsmål enn svar, og det føles også litt skummelt å ha fått røsket opp så mange etablerte sannheter.

Nå er det på tide å komme seg tilbake i hverdagen og anvende det vi har lært på den måten som passer best for oss i enhver situasjon. Kent er en klok mann med mange erfaringer å lære fra, og på samme måte som han blir vår egen vei også til underveis.

It all depends.

Anders Extreme Programming, Kent Beck