Code Camp 09

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