Code Camp 09

Det har vært stille her på Code Camp-bloggen en stund nå. Det skyldes delvis at jeg den senere tiden har jobbet mye med et web-rammeverk for Java, der jeg prøver å innarbeide tanker og idéer som har oppstått som følge av samarbeidet med Kent.

Det er snart et halvt år siden Code Camp med Kent Beck i Oregon, og jeg har nå ukentlig coaching med Kent over Skype, iChat og andre medier for deling av skjerm, utviklingsmiljø, lyd, bilde, mm.

Mye av det Kent sier er sunn fornuft, og poengene hans kan fremstå nesten banale. Men følelse av banalitet forsvinner like fort som den kommer: En av Kent sine styrker er å sette det han sier, de almengyldige, generelle prinsippene, inn i en sammenheng som gjør at mottageren forstår. Det gjør han til en mester i å skape positiv endring.

Jeg har sett mange prosjektledere som forteller utviklerne sine at de skal gjøre tingene “godt nok”. Som juniorprogrammerer mislikte jeg denne beskjeden sterkt. Senere har jeg begynt å forstå hva de egentlig prøver å formidle. Godt ingeniørarbeid er drevet av behov, og ikke løsning. Overdesignede systemer oppstår når behovene glemmes. Prosjektlederene kaller dette “godt nok”, et uttrykk som svært lett kan misforstås.

Behovsdrevet utvikling er essensielt og uavhengig av metodikk. Agile og lean dreier seg i all hovedsak om å bli enda bedre på dette området. Det er noe vi alle vet. Allikevel er det er noe vi alle hele tiden glemmer. Iallefall gjør jeg det.

Kent sitt rammeverk for testdrevet utvikling, JUnit, er en god studie i hva som skjer når behov står i fokus. Han har millioner av brukere, noe som i seg selv gjør rammeverket og tankene bak interessante. Selv har jeg brukt JUnit lenge, men jeg ble enda mer interessert i tankene bak etter Code Camp med Kent. “Vårt mål for rammeverket er å gjøre det så enkelt som mulig for en programmerer å skrive sin første automatiserte enhetstest”, fortalte Kent oss den gang.

Vi systemutviklere lager mange løsninger med web-baserte brukergrensesnitt. Det finnes mange web-rammeverk som skal gjøre oss mer produktive, og i norske IT-bransjen er nok  Java og .Net, de “profesjonelle plattformene”, mest brukt i dag. De er omfattende, og konkurrerer fortløpende om å ha best ytelse, mest funksjonalitet og mest innbydende utviklingsmiljø.

Med prosjekterfaring fra begge leire har jeg allikevel lenge gått med en følelse av overdesign av dagens “enterprise”-rammeverk. For mye fokus på løsning, for lite fokus på behov. Hva gjør en utvikler produktiv? Er det hensiktsmessig å kontinuerlig hoppe mellom forskjellige programmeringsparadigmer, lese dokumentasjon, Google feilmeldinger og finne på stadig mer kreative former for å løse automatisert testing? Listen over mine frustrasjoner er lenger, og kunne sikkert blitt et eget blogg-innlegg.

Med enkelheten og renheten til Kent Beck sitt JUnit-rammeverk som inspirasjonskilde begynte jeg for en stund tilbake å fundere på hvordan et behovsdrevet rammeverk for å lage web-applikasjoner kunne være. Dårlig vær, et par inneklemte fridager, en solid mengde morgenkaffe og noen andre tilfeldigheter satte meg igang med et eksperiment.

Min ukentlige coaching med Kent dreier seg nå stadig mer om Snowflake, mitt eksperiment for hvordan anerkjenne behovene til utviklere av web-applikasjoner. I mine møter om dette med Kent, møter jeg først og fremst meg selv – i døren – fra første stund.

Kort og greit mener Kent at jeg antageligvis har overdesignet deler av systemet allerede, til tross for at det etter mitt skjønn er så enkelt at jeg vil få problemer med å skaffe brukere. Men Kent mestrer nok en gang å sette sin grunnleggende, ingeniørmessige fornuft inn i sammenheng.

Ærlig og brutalt forteller han meg at mitt ingeniør-ego vil at jeg skal lage noe som er usannsynlig imponerende før noen som helst får høre om det. Jeg vegrer meg for å skaffe brukere tidlig i prosessen, fordi dette er det samme som å legge hodet på blokken og risikere at noen kaller meg en idiot.

“Dersom du får noen til å kalle deg en idiot, har du kommet langt”, mener Kent. Jeg har skapt engasjement, og fått et bevis for at jeg er inne på noe. Kanskje har jeg funnet det viktigste behovet – den verste smerten – som jeg skal fokusere på å løse?

Coachingen fremover vil nok dreie seg om både design av rammeverk, og hvordan lande sitt ego i møte med markedet. Fortsettelse følger

Anders Extreme Programming, Kent Beck, Snowflake

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

Recap: Vi nærmer oss slutten av vår uke sammen med Kent Beck. Så langt har Code Camp 09  vært lærerikt, utmattende og svært inspirerende. Vi dro hit for å lære å bli gode seniorutviklere. Programmering, kundedialog, planlegging, ledelse, teamarbeid. You name it. Vi har vært gjennom alt fra øvelser knyttet til kundeforståelse, produktutvikling og innovasjon til gårsdagens høydepunkt: Timer med intens parprogrammering i krevende programkode, for anledningen fra et at våre prosjekter innen regnskap og booking-løsninger hjemme i Norge.

Nå gjenstår én dag og vi merker hvordan vi begynner å komme under huden på ekstremprogrammering. Noe av det som fascinerer oss er hvor forskjellig vi opplever vår egen forståelse av denne tankegangen nå, sammenliknet med da vi hadde lest bøkene. Mange lærebøker er dogmatiske og ensidige. Kurs er ofte på samme måten. Drar man på Scrum Master-kurs med Ken Schwaber så er det ikke mye “på den ene siden” og “på den andre siden”. Riktignok er Kent sine bøker verken dikterende eller dogmatiske, men vi ser allikvel det han skriver med helt nye øyne nå: Det er måten å resonnere på og måten å angripe problemer på som er kruttet. Som Kent sier selv så er det første svaret på ethvert ikke-trivielt spørsmål: “Det kommer an på”.

På slutten av gårsdagen tok opplegget en ny vending: Kent holder på å forberede et nytt foredrag og ville ha våre innspill. Han forklarte at temaet er  trendene vi ser med måten IT-prosjekter gjennomføres på. Hvilke utviklingsorganisasjoner er konkurransedyktige om 5 og 10 år, og hvem faller fra? Hva  gjør de organisasjonene som har suksess om 5 år idag?

Kent tegner først en graf som tar utgangspunkt i leveransesykler: Fra årlig til kvartalsvis, månedlig, ukentlig, daglig og til slutt på timebasis. Annual, Quarterly, Monthly, Weekly, Daily og Hourly, som indikert med forbokstav i bildet over. Den horisontale aksen viser bruksprosent. De tre grafene viser hvordan vi holdt på med systemutvikling tidligere, hva som skjer mange steder idag og hva vi tror kommer til å skje i fremtiden. Synsingen om fremtidsgrafen tar inn over seg hvilke krav kunder og markedet generelt stiller til tilpasningsdyktighet. For Kent er det liten tvil om at vi beveger oss mot stadig kortere leveransesykler. Det er naturlig å spørre seg selv hvor dette skal ende.

“Det er fascinerende hvor vanskelig det er for folk som jobber i tradisjonelle vannfallsprosjekter med årlige leveransesykler å prate med noen i den andre enden av skalaen – de som leverer programvare daglig eller flere ganger om dagen”. Kent blar til en blank side i sin enorme A2-tegneblokk. “I Tyskland er de forøvrig veldig glad i noe som heter V-modell. Har dere hørt om det?”. Vi skal til å bekrefte at også noen i landet vårt holder på med dette, men blir raskt avfeid. “La oss snakke om noe mer interessant” .

Han lager en ny graf, denne gangen med leveransesyklene vertikalt. Horisontalt legger han ut forskjellige teknikker, verktøy, prosesser og andre elementer av det å utvikle programvare. Test-drevet utvikling, automatiserte byggesystemer, dokumentasjon, QA-avdeling, endringshåndtering, og masse mer. Så begynte å han å plotte: Trenger vi en QA-avdeling når vi leverer programvare én gang i året? Ja, uten tvil. Her vil det samle seg opp masse programvare som inneholder feil fordi utviklerne får et annet syn på det å levere. Ugjennomtestet halvfabrikata er gjennomgående og man trenger egne ressurser dedikert til å teste og melde tilbake feil.

Hva med de som leverer programvare daglig? Eller enda mer ekstremt: De veldig få bedriftene som er i stand til å levere ny funksjonalitet på timesbasis? Trenger de en QA-avdeling? Neppe. Her må man jobbe på en måte der feil fanges opp kontinuerlig. En mekanisme kan være å monitorere feilmeldinger som oppstår når de ruller ut ny programvare. Dersom feilmeldingsraten går opp med en ny versjon, vil systemet automatisk rulle tilbake. Dette stiller på sin side store krav til migreringer av data, og dermed blir “Migreringer” en ny kategori på Kent sin plansje. “Trenger et selskap som leverer programvare årlig migreringer?” Antageligvis ikke. Her blir det heller store konverteringsprosjekter som først og fremst er smertefult for kunden. Kent smiler lurt. “Hva hadde skjedd om de hadde brukt XP?”

Slik satt vi med Kent i over en time. Alskens idéer ble kastet frem. Hva med daglige statusmøter? Scrum? Trenger man Scrum når man leverer ny funksjonalitet på timesbasis? Spørsmålene svirrer fortsatt i hodene våre. Vi har begynt å få perspektiv.

Imorgen er siste dag. Diskusjonene har begynt om hva vi skal gjøre. Få mest mulig ut av siste dagen – det blir lenge til neste gang vi har mulighet! Det er tilfredsstillende å merke hvordan vi begynner å forstå Kent Beck. Fra tid til annen klarer vi å forutse hva han svarer på vanskelige spørsmål. Ikke fordi han gir oss detaljerte sjekklister, oppsummeringer, og fasitsvar. Tvertimot fordi han lærer oss å resonnere, se sammenhenger og veie for og imot. Her ligger løsningen til ethvert komplekst problem.

Imorgen planlegger vi å be han presentere kodebasen i JUnit, Java-rammeverket han har skapt for testdrevet utvikling. Oppdatering kommer

Anders Extreme Programming, Kent Beck

Da Kent Beck ble hyret inn hos Chrysler for å gjøre noen ytelsesforbedringer i lønnssystemet, visste de lite om hvilken påvirkning han kom til å ha på selskapet. Ansett som “nok en” systemutvikler så han raskt hvilke problemer som eksisterte i IT-avdelingen. De var etter hans skjønn så fundamentale at det å optimalisere programvarekoden ble underordnet. Istedenfor tok han seg tid til å prate med alle ansatte i avdelingen jevnlig, og i hver samtale foreslo han små forbedringer. “Hva om vi tar et kjapt statusmøte hver morgen der alle forteller hva de planlegger å gjøre denne dagen?”, foreslo han. “Tja, hvorfor ikke?” var svaret. “Kanskje vi skal skrive små tester av vår egen programvare, slik at vi slipper å manuelt teste funksjonaliteten gang på gang?” Neste forslag ble også godt mottatt. Slik gikk dagene.

Idag kjenner vi kombinasjonen av disse tiltakene som eXtreme Programming – ekstremprogrammering. En metodikk som til tross for sin merittliste over vellykkede IT-prosjekter er kontroversiell i mange miljøer. Kanskje spesielt blant akademia og bedriftsledelse – de som ikke er på frontlinjen og ser de daglige utfordringer med systemutvikling.

“Jeg hadde en guru-periode i mitt liv. Det var veldig ødeleggende”. Kent Beck svarer pragmatisk på vårt spørsmål om hans forhold til en av sine motstandere. “Du kan dra rundt på konferanser og holde inspirerende taler og messe om prinsipper, fremgangsmåter, og absolutte sannheter … Men et absolutt svar på et vanskelig spørsmål fremstår kun meningsfylt idet spørsmålet besvares”. Han ser spørrende på oss og venter på en reaksjon. Forvisser seg om at vi følger med; her er det et viktig poeng som skal frem: “Idet du går ut døren og drar hjem for dagen kommer skuffelsen. Du innser at jeg bare ga deg et fancy, overbevisende svar, som i virkeligheten er hult og almenngyldig”.

Han er på ingen måte bitter. Han er ganske enkelt en person som lærer av sine erfaringer. Og det første svaret på ethvert godt spørsmål er i følge Kent “it depends”. Hva er målet med oppgaven din? Levere raskt? Fikse dyptgående kvalitetsproblemer? Forholde deg til et miljø i stadig endring, eller et statisk miljø?

Kent måtte tilbake til programmeringen. Slutte å skrive bøker og snakke på konferanser, og dykke ned i de problemstillingene han ble utfordet på. Og han lærte å sette pris på “ambiguity” – tvetydighet. Det å holde mulighetsrommet åpent så lenge du kan: Unngå ledende ja/nei-spørsmål. Vær åpen, og vær forberedt på å utforske muligheter du ikke hadde forutsett.

Etter dagens telefonkonferanse med vår ekspertbruker for Individuell Plan, systemet Iterate skal utvikle, ble vi sittende med et overveldende mulighetsrom. Tankekart ble løsningen:

En av utfordringene våre ble utgangspunktet for de tankene som skal føre til et fungerende IT-system. Konseptet for Individuell Plan er at pasienten, eller brukeren, er i sentrum. Dette er ikke et støttesystem for leger eller annet helsepersonell. Dette er et system for en person som trenger hjelp til å komme seg ut av en uønsket situasjon.

Allikevel fokuserte vi lenge på selve planen. Som utviklere så vi for oss den fremtidige databasen, som helt sikkert kom til å ha en entitet med navnet “Plan”. Det var helt natulig å sentrere tankene våre rundt dette konseptet, helt til Kent spurte: “Hva skjer med tankekartet deres om dere setter brukeren i midten?”

Plutselig gikk gardinen opp: Hvis konseptet for individuell plan er å ha brukeren i sentrum, så må også vi som systemutviklere tenke på samme måte. Produktet må reflektere konseptet. Med vårt neste tankekart falt alt plutselig på plass:

Vi kunne forenkle uten å miste detaljene og vi kunne mye enklere se for oss de tekniske aspektene: Vi holdt mulighetsrommet åpent og verdsatte den tvetydigheten som ligger rundt ethvert sammensatt problem.

“Jeg har sett programvarearkitektur som er så kompleks og fancy at det oppstår egne sermonier i bedriften hver gang noe skal endres” forteller Kent over lunsjen. Vi systemutviklere elsker å bygge lag på lag med stilig kode, som følger alle mulige tips & triks, best practices, kule ting vi hørte om på en konferanse, eller ikke minst: Det “alle” gjør for tiden. “Slike ting oppstår fordi man ikke har tatt seg tid til å utforske løsningsrommet og forstå hvilke problemer man skal løse. Selv de mest erfarne utviklere går i denne fellen, og det koster millioner”. Kent smiler lurt idet han ber oss gjøre klar til å komme igang med neste utfordring.

Endelig var vi igang med det vi hadde sett frem til med skrekkblandet fryd: Å programmere sammen med Kent Beck.

Fortsettelse følger

Anders Extreme Programming, Kent Beck

“Spesifikasjoner av krav er ikke bare uhensiktsmessig, det er helt galt”. Kent spiller orgelkantater av Bach mens han varmer hendene på tekoppen. Kontorveggene er kledd fra gulv til tak med en imponerende samling og nesten surrealistisk blanding av faglitteratur. Shakespeares samlede verker – illustrated version, en bok om flykrasj gjennom historien – og hva man lærte fra dem, kompilatordesign, logikkprogrammering, design patterns, optimalisering av Java-kode, hvordan være en god far …

Vi har funnet oss hver vår stol i et kontor tydelig innredet etter Kents måte å jobbe på: 2 pulter, 2 skjermer, 4 stoler. Her jobber man i par, ingen tvil. “Men i store, komplekse prosjekter må vi jo ha en avsjekk fra kunden på hva som skal utvikles”. Jeg tar meg selv i argumentere imot. En smule ambisiøst til å være tidlig på morgenkvisten. Har ikke lyst til å gjøre han sint heller.

Han smiler og forklarer med tålmodig stemme: En kravspesifikasjon har en aura av noe absolutt over seg. Og det til tross for at vi driver med utvikling. Ville du stilt detaljerte krav til piloten når du gikk ombord i flyet? Take-off-hastighet, marsjhøyde, rutevalg? Nei, du sier istedenfor at du er invitert på fest i Trondheim og vil gjerne komme deg dit i en fei.

Slik er det med programvareutvikling også, sier Kent. Det er historiene bak funksjonaliteten som inneholder kruttet. Det som får oss til å utvikle. Ikke bare grave oss ned i gudsjammelig kjedelige matriser, tabeller og punktlister.

For å kjenne på kroppen Kents måte å tenke på har vi bestemt oss for å utvikle et helt reelt system. IT-støtte for Individuell Plan, et regime for å gjøre samarbeidet enklere mellom pasienter med komplekse sykdomsbilder og alle involverte funksjoner. Leger, fysioterapeuter, ergoterapeuter osv. “Tenk på den historien Alice forteller sin betrodde venninne når hun har brukt systemet deres for første gang!” messer Kent. “Før måtte jeg ringe rundt og ingen hadde oversikt. Avtaler med de som behandlet meg kom i feil rekkefølge og alt var bare fullstendig ukoordinert! Nå bruker vi dette systemet der alle kan logge seg på og se hva som skjer”.

Det dreier seg om å finne smerte. Hva er det som plager brukerne så mye at de nesten har problemer med å snakke om det? Hva er det de vil oppleve som en stor forbedring av sin hverdag? Det er disse historiene vi er ute etter.

Fremgangsmåten kan være enkel:

1. Finn ut hvor det gjør “vondt” for brukerne dine. Hva er upraktisk og tidkrevende i deres arbeidsprosesser?
2. Verifiser at de faktisk er klar over disse problemene. Vet de at det smerter?
3. Hva er “workarounds”? Hva gjør de for å komme rundt problemene?
4. Hva slags budsjett har de mulighet til å bruke på et system?

“Det er typisk for oss systemuviklere å tenke på systemutvikling” fortsetter han mens han vandrer filosofisk frem og tilbake foran bokhyllen. Av og til plukker han ut bøker vi skal lese. Alltid et spørsmål om vi allerede har lest den. Gang på gang innrømmer vi med en viss flauhet at “den boken der var nok også ny for meg”. Kent har lest dem alle, fra perm til perm. Han er som en bibliotekar som kan hele samlingen sin utenat.

“Før dere får lov til å programmere noe som helst skal dere vise meg at dere kan tre ut av rollen som systemutviklere”. Vi ser på hverandre. Ingeniørene i oss sitrer etter å komme igang med håndtverket, og få se Kentern “in action”. Men vi må gjøre som Kent, og ile langsomt. Gå inn i hodet til sluttbrukeren og kunden og tenke på hva de trenger. Og ikke nok med det: Vi får også krevende spørsmål om forretningsmodeller og kommersielle betingelser. “Hvordan skal dere ta betalt for dette systemet? Jeg lager aldri noe som helst, før jeg har bestemt meg for betalingsmodell. Det styrer hele produktet” sier han mens vi ligger under benken og prøver å koble laptoppene våre til amerikanske stikk-kontakter.

Dette har vi heldigvis tenkt på, og han synes vi er på riktig spor. Hvis du tar betalt for et system én gang og deretter overlater det til kunden, havner du fort i et dilemma når en ny kunde dukker opp. Den nye kunden vil ha funksjonalitet X, som du mangler, mens den eksisterende kunden vil ha funksjonalitet Y, som du også mangler. Med denne betalingsmodellen vil du favorisere den nye kunden. Du vil rett og slett nedprioritere en eksisterende kunde, selvom alle vet at dette er idiotisk. Jeg vil aldri havne i en slik situasjon sier han og peker på abonnementsordninger istedenfor. Da er alle kundene “nye” i den forstand at de når som helst kan kansellere abonnementet. Du ender opp med å prioritere bedre, og kundene dine får en bedre tjeneste.

Imorgen får vi forhåpentligvis lov til å begynne programmeringen …

Anders Extreme Programming, Kent Beck

Vi har et frynsete rykte i IT-bransjen. Kvalitetsproblemer, sprengte budsjetter, sikkerhetshull, overarbeidede systemutviklere, skuffede kunder …  Vi tar for mange snarveier, bruker for mye tid på feil type planlegging – og leverandør og kunde snakker for ofte forbi hverandre. Det er ikke nødvendigvis noe galt med våre hensikter, men middelet trenger sårt forbedring. Code Camp 09 er et forsøk på å finne frem til ingeniørpraksiser som passer sammen med de forventninger kundene og brukerne har til kvalitet, forretningsfokus og inntjening.

Det er tross alt en grunn til at vi lager all denne programvaren.

Jeg møtte Kent Beck første gang en kald februardag i år. Jeg og min kollega Kim Leskovsky satte oss på bussen på Oslo S og suste nedover til Göteborg, der vi via kortfattet mailkorrespondanse hadde avtalt et møte. Kent Beck får hundrevis av mail daglig fra fans over hele kloden. Gudene vet hvordan han endte opp med å ta vår henvendelse seriøst. Var det virkelig “The Kent Beck” vi hadde mailet med? “Det kan ha vært en navnebror, som driver med hundeoppdrett eller am-car” mumlet Kim mens han nervøst slurpet i seg Nescafé. Selv var jeg ikke noe mer høy i hatten, der jeg satt og lagde en presentasjon av opplegget vi ville foreslå. Fallhøyden føltes stor.

Han kom presis til møtet i følge med sin partner Cynthia Andres, som også har vært medforfatter på bøkene hans om Extreme Programming. Vi fant tonen og nervøsiteten forsvant fort. Det var heller ingen tvil om at vi satt der med selveste Kent Beck. De neste to timene hadde vi en svært lærerik, krevende og inspirerende samtale. Gullkorn og innsiktsfulle bemerkninger kom på løpende bånd og vi merket godt hvilken bredde og dybde denne mannen hadde. Han hoppet uanstrengt mellom temaer fra intrikate optimaliseringsteknikker i Java-kildekode til forretningsmuligheter, pedagogiske prinsipper og gruppeprosesser og team-building. Det krevde sin mann å henge på.

Det skjer noe med deg som fagperson når du møter noen som overbeviser deg om at du kan lære å jobbe dobbelt så fort uten å kompromittere kvaliteten på det du leverer. Det dreier seg ikke nødvendigvis om å jobbe hardt; poenget er å jobbe smart.

Kontra-intuitivt mener Kent Beck at programmerere skal jobbe i par: To personer med ett tastatur. Den ene skriver, den andre følger med. Tastaturet skal kastes frem og tilbake. Ingen er overlegen den andre, og alt dreier seg om grundig, ærlig og åpen ingeniørpraksis. Ved første øyekast tenker de fleste at dette må ta dobbelt så lang tid. Kanskje mer. Jo flere kokker desto mer søl. Eller? Erfaringene med denne teknikken viser det motsatte. Og dette omfatter mer enn parprogrammering. Alt fra smarte programmeringsteknikker til det Kent mener er det aller vanskeligste med systemutvikling: Sosiale ferdigheter.

Nå satt vi altså der med kilden selv, og fikk høre hvordan han hadde kommet frem til sin utviklingsmetodikk. Hvordan han hadde snudd en dysfunksjonell IT-avdeling i et stort amerikansk selskap til å bli i verdenseliten innen effektiv utvikling av virksomhetskritisk programvare. Og deretter generalisert metodikken til det vi i dag kjenner som Extreme Programming.

Målet vårt med møtet var å finne ut hvordan Kent Beck kan styrke oss i Iterate teknologisk og metodisk. Kim fortalte om vår idé: Vi sender tre av våre mest erfarne systemutviklere til å sitte sammen med deg på ditt gårdsbruk på landsbygda i Oregon, USA og programmere intenst en uke. Mål: Forstå hvordan du jobber, bli utfordret og ta med oss erfaringene tilbake til våre kolleger. Vi kaller opplegget ”Code Camp”.

Kent bor altså sammen med familien på et gårdsbruk på landsbygda i Oregon. Inne i gårdsboligen har han sitt kontor med en beskjeden bredbåndslinje, og mellom vanlige gårdsaktiviteter, som pløying av jorder, melking av geiter, ysting, med mere, jobber han utrettelig med å produsere programvare, artikler, blogginnlegg og bøker om programvareutvikling og gode ingeniørpraksiser.

Og nå sitter vi her, på en jakthytte langt ute villmarken i Oregon og venter spent på oppstart. Vi har pløyd oss grundig gjennom bøkene og bloggen hans. Vi er ivrige på å komme igang. Noe av det vi lurer aller mest på er selvfølgelig hvordan det blir å se han “in action”. Mannen som av mange regnes som kanskje verdens dyktigste systemutvikler.

Mandag braker det løs ..

Anders Extreme Programming, Kent Beck