Code Camp 09

Tilbake til hverdagen. Tilbake til Corollaen, regn og novembermørke. Får en feilmelding om at batteriet på MacBooken er i ferd med å ta kvelden, og det ligger en regning på piggdekkgebyr i posten … Stemningen på jobben bærer derimot preg av alt annet enn en deprimerende årstid. Jeg er heldig som har slike positive, smarte og småsprø kolleger. Kommer du på jobb med en sur mine blir det kjapt tatt hånd om av noen frekke bemerkninger, et uflatterende bilde på internbloggen og 5 hoder på 5 minutter bortom arbeidsplassen for å jabbe …

(Noen har nettopp brukket bygget til Kent)

Lærdommen fra vår uke sammen med Kent begynner dessuten å synke inn. Vi har et lite forsprang på gutta boyz og the girl power på kontoret nå, men det varer ikke lenge. Vi er ivrige på å bringe kunnskapen videre, og våre kolleger plukker kjapt opp poengene.

Iterate har et større prosjekt på trappene og selv klør jeg i fingrene etter å komme igang og anvende ny kunnskap. Dette er med en kunde som ikke driver med IT-utvikling selv, men som på andre områder har fokus på arbeidsprosesser, verdiskapning og riktig bruk av mennesker. Vi har hatt et oppdrag for dem tidligere og opplevde svært raskt at et felles tankesett er en stor fordel for begge parter: “Hvorfor jobber ikke alle på denne måten?” var deres første kommentar da vi foreslo en smidig metodikk for gjennomføringen av prosjektet.

“Våre folk er svært kompetente, og derfor tror vi det er lurere å la dem finne den beste måten å jobbe på selv, fremfor utførlige prosessbeskrivelser”. Vi la diplomatisk frem vårt budskap, og det ble mottatt litt på samme måte som om man gir noen en paraply i kraftig regnvær. Det er herlig med slike kunder. Ikke minst fordi vi vet så inderlig godt at det er dette som gir dem mest verdi for pengene.

Dette med felles tankesett – og det motsatte – var også noe som opptok Kent. Jeg var innom temaet i innlegget om fremtidens IT-prosjekter. Her spør Kent hvorfor det er så vanskelig for fagfolk fra den tradisjonelle skolen å forholde seg til smidige fagfolk. Og vice versa. Han tror svaret ligger i verktøy, teknologier, metoder og andre aspekter ved vår arbeidsmåte. De verktøyene man trenger i et tradisjonelt prosjekt er kanskje unødvendige i et smidig prosjekt, og omvendt. Og så videre.

I denne øvelsen har Kent kategorisert metodikkene etter lengden på leveransesyklene. Et tradisjonelt prosjekt har én syklus. Et intenst, XP-drevet prosjekt leverer flere ganger om dagen. Mellom disse ytterpunktene finner vi mer kjente metoder som Scrum, RUP og andre iterative tilnærminger. For å komme nærmere spørsmålet om hva som skaper den ofte følte avgrunnen mellom tradisjonell tankegang og smidig, stilte jeg Kent spørsmålet om det var noe de to ytterpunktene hadde til felles. Han hadde ikke noe svar. Før idag.

Kent er en ivrig tilhenger av det som kalles Appreciative Inquiry. “Når vi ingeniører skal løse en vanskelig situasjon, skal vi alltid begynne med å ramse opp og kategorisere alle problemene vi har sett”. Det var tydelig at han hadde gått frem på denne måten mange ganger. “Så skal vi prioritere alle problemene og deretter gå for å løse de vi anser som viktigst. Det vi i praksis gjør i en slik situasjon er å be alle i rommet tenke hardt på hvordan vi har gjort idiotiske ting, tenkt dumt og feilet – Hvor gode løsninger tror dere vi finner i en slik sammenheng?” Appreciative Inquiry dreier seg om å jobbe seg frem til gode løsninger gjennom å fokusere på det som har vært positivt. Ved første tanke høres det kanskje unnvikende og feigt ut. Men som Kent påpeker kan AI være vel så tøft som klassisk problemløsning. Poenget er i all hovedsak å finne løsninger, fremfor å grave frem problemer man kanskje hadde lagt bak seg.

Det var altså AI som satte meg på sporet av spørsmålet Kent ikke kunne svare på. I et forsøk på å gå ut av skyttergraven og tenke positivt om tradisjonell prosjektmetodikk (du er herved utfordret!), prøvde å jeg finne områder vi har til felles. Kanskje dette kan være veien til stadig bedre måter å jobbe med programvareutvikling på?

Snart starter vi forøvrig opp ukentlig coaching med Kent. Dagboken fortsetter fra det vi behandler i disse sesjonene.

Anders Kent Beck, Problemløsning

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