Code Camp 09

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