Utdaterte arkitekter koster din bedrift penger

I anledning Software 2009 skal jeg holde en lyntale hvor jeg tar opp et tema jeg, og veldig mange andre jeg har snakket med, føler smerten til på daglig basis:

Programvare arkitekter som ikke jevnlig utfører praktisk utvikling påfører sine bedrifter enorme kostnader

Hvordan kan jeg påstå noe slik når det jo er de beste som får det store ansvaret av å være arkitekter? Årsaken mener jeg ikke er manglende kompetanse, men snarere en gradvis fjerning fra der hvor den faktiske produksjonen skjer. Denne distansen gjør at man i stadig mindre grad er i stand til å gjøre gode vurderinger på enkelt saker.

Gjennom å i stadig mindre grad ta del i det daglige arbeidet havner arkitektene i en situasjon hvor man stort sett kan beslutte på generelt grunnlag og gammel kompetanse. Konsekvensen for bedriftene er at man ofte får en teknisk infrastruktur som stagnerer og som tilslutt må byttes ut til enorme kostnader. I stedet for at man har gradvis forbedret og oppdatert infrastrukturen har man hele tiden kjørt “safe” og med det man kan godt fra før.

Kontinuerlig forbedring

Hvordan unngår du så at de som tar beslutninger har detaljkunnskap og praktisk erfaring nok til å kunne holde seg oppdatert? Arkitekter må plasseres ut i praktisk arbeid. Dette heter eat your own dog food eller Pain Driven Development. Gjennom å la arkitektene føle på kroppen hvordan det er å utføre vanlige systemutviklingsoppgaver etter retningslinjer de selv har lagt vil også de føle på kroppen behovet for kontinuerlig forbedring av arkitektur og infrastruktur. Gjennom å skape en kultur for endring og kontinuerlig forbedring vil bedriften spare store summer gjennom at de slipper store prosjekter for oppdatering av utdatert arkitektur.

Hvis du synes dette høres spennende ut, så kom på Dataforeningens Software 2009.

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.