Ønskereprise på XP Meetup

Lyntalen “Agile sier du? frAgile sier jeg” jeg holdt på Smidig 2008 er en del av ønskereprisene fra konferansen på XP Meetup den 17. November. Dette er en ypperlig anledning til å få med seg det beste av det du ikke fikk sett under konferransen eller for deg som ikke kom deg dit er det en anledning til å se hva du gikk glipp av.

Detaljene om hvordan du kan delta finner du på Oslo XP November Meetup. Vi ses!

Oppdatering: Presentasjonen min fra møtet ligger nå ute, sammen med alle de andre presentasjonene, så du kan se dem dersom du lurer på hva jeg snakket om.

Dette var første gang jeg var på XP Meetup i Oslo og jeg må si det ga mer smak. Utrolig mange folk, veldig bra foredrag og ikke minst gode diskusjoner etter foredragene. Hvis du ikke var der så burde du angre, for dette er et community som er av de beste på planeten når det gjelder smidige metoder.

Gro applikasjonen din som en åker

Jeg har vokst opp på en gård i fjellbygda Folldal og er dermed veldig mottagelig for analogier og eksempler som tar utgangspunkt i gårdsdrift. Overraskelsen min var stor da jeg leste en artikkel av XP-guru Kent Beck som nettopp bruker bøndenes metode for å dyrke åkeren for å vise hvordan man kan gjøre det samme i applikasjons design.

Artikkelen First One, Then Many tar for seg et klassisk dilemma innen systemutvikling. Du skal lage et system som skal håndtere en transaksjon i første omgang, men man antar at det vil måtte håndtere mer enn en senere.  Klassisk systemutviklings litteratur sier da at du må ta høyde for dette i ditt design. Kent forklarer i sin artikkel hvorfor dette ikke er en god ide og han bruker bonden som utgangspunkt.

Bønder dyrker ikke åkeren sin for at den skal være komplett fra dag en, han dyrker den for at den skal være perfekt når det er tid for innhøsting. Derfor bruker bonden ikke bare en sort frø, han bruker gjerne flere sorter frø for å oppnå best resultat. Bonden bruker en frø type som gror raskt for å stabilisere jordsmonnet i tillegg til den egentlige sorten frø som gror litt saktere. På denne måten sørger han for at åkeren over tid blir utnyttet optimalt.

Jeg er veldig enig i Kent sin måte å tilnærme seg applikasjons design. Gjennom å gjøre “smarte” antagelser og å “ta høyde for” ting så skaper man problemer for den som kommer senere. Det er langt bedre å ha en kodebase som reflekterer det som systemet faktisk gjøre, enn en kodebase som inneholder halvveis implementert funksjonalitet. I Lean Software Development kalles dette søppel (eller waste (eller ennå mer trendy kalles det muda)). Søppel har en tendens til å skape ubehag dersom det opptrer i større mengder og blir liggende over tid. Derfor er jeg helt enig med Kent sine tanker om å la kodebasen reflektere hvordan virkeligheten faktisk er. Det gjør det enklere å både vedlikeholde og videreutvikle en løsning.

Hvis du tenker på Kent sin artikkel neste gang du sitter å forsøker være kreativ når du spesifiserer et grensesnitt så vil du, kunden og systemet nok takke deg til slutt.