Om teknisk gjeld

Core Group fikk nylig en interessant artikkel om IT-systemenes tekniske gjeld inn i Finansavisen kalt “Norges ukjente gjeldsberg“. På høy tid at blårussen får en vekker her! En god artikkel som oppsummerer problemet helt fint, men (selvsagt) litt tabloid.

Dette problemet er jo helt trivielt og grunnleggende; Det er mulig å spare tid å penger ved å gjøre dårlig håndtverk. På en eller annen måte vil dette hastverksarbeidet føre til kostnader senere en gang. Mitt favoritteksempel går på utvendig husmaling: Du skal skrape godt, vaske huset, det skal tørke, du skal ha på soppdreper, før to lag maling påføres. Når jeg skulle sette bort dette arbeidet hadde ikke de med det laveste tilbudet (6000 kr) tenkt å gjøre annet enn å kline på maling. Dette ville sett helt fint ut i et par år, men så ville det vært nødvendig med en ny runde  og nye kostnader.

Akkurat som for husmaling vet vi i dag mye om hva som er “godt håndtverk” i programvareutvikling, men det selvsagt langt mer komplekst og rom for langt flere nyanser. Den beste referanser er nok fremdeles boka til Uncle Bob kalt Clean Code. Ren kode er omtrent som i et profesjonelt kjøkken. En fredag kveld på en stor, god restaurant vil kjøkkene syde av aktivitet og for en utenforstående vil det fortone seg fullstendig kaotisk. Men studerer man det hele kan man finne ut at det råder en fantastisk orden og disiplin og at alle kokkene tar seg tid til å vaske benker, skylle kniver og ikke minst sørge for at all redskapen er å finne på sin faste plass. Dette “ekstraarbeidet” er helt nødvendig for å klare å være effektive i en kompleks setting! På samme måte sørger de beste programmererne og teamene for at koden de etterlater seg til enhver tid er vel strukturert, følger logiske navnekonvensjoner, er kommentert og ikke minst inneholder tester. Test Driven Development synes å ha etablert seg som en “best practice” i store deler av programvarebransjen. Man gjør rutinemessig re-factoring og code reviews.

Så spørsmålet blir da selvsagt: “Når vi har denne kunnskapen, hvorfor skjer det da ikke?” Vi har berørt dette temaet mange ganger som for eksempel herher og her. Dan Vigeland kommenterer det i artikkelen i Finansavisen, men berører ikke alle aspektene.

 

Teknisk gjeld er økte endringskostnader

Vi må akseptere at etter hvert som IT-systemene utvikles vil det koste noe mer å gjøre en endring (Cost of Change – CoC). Denne utvik

lingen er nærmest lineær og fullt ut håndterbar, om man hele tiden sørger for å systemet er velstrukturet, lettfattelig og inneholder automatiske tester, mao det som ansees som “godt håndtverk”.

Det er når man ikke tar seg tid til å gjøre det gode håndtverket at endringskostnadene skyter i været. Dette blir fort en ikke-lineær kurve – om endringskostnadene øker kan man regne det som sikkert at man ikke klarer å holde det man lover og tidspresset blir enda større enn tidligere; “Man har det gående”.

 

Årsaker til at vi bygger opp teknisk gjeld

Utviklerne bryr seg ikke. Det er desverre slik at mange utviklere og testere fremdeles ikke har særlig sterkt eierskap til produktet de lager. De er ikke med på å utforme kravene og de er heller ikke informert om visjonen – selve hensikten med jobben de gjør. De blir styrt av prosjektledere som forteller dem hva de skal gjøre. De blir målt etter KPI-er som ikke adresserer sluttproduktet. Og de får omtrent ikke reell feedback på jobben de gjør. De er ferdig med jobben når ting er utviklet, etter dette er det driftsavdelingen som “eier problemet”.

Om ikke utviklerne bryr seg, vil de – selv om de har kunnskap om “Clean Code” – gi opp å argumentere for å jobbe saktere en stund for å rydde opp i spaghettikoden. De venner seg fort til at “tid er det som betyr noe her”.

Forretningssiden / kunden undervurderer problemet. Dette dreier seg selvsagt om (mangel på) kunnskap hos de som sitter med styringen. Når jeg skulle ha huset mitt malt – og skulle velge leverandør og pris – forsto jeg fort at det var lurt å sette meg inn i hva som et godt håndtverk, slik at jeg unngikk å bli sittende med et stort problem om noen få år. Jeg forsto at jeg kunne velge mellom billigløsningen (6000 kroner og null forarbeid) og “Rolls Royce” (60.000 kroner der alle malerne hadde erfaring og fagbrev). Jeg valgte noe i mellom, men forvisset meg om at de skulle følge alle prosedyrene. På samme måte må de som definerer kravene og forplikter leveranser ha en viss grunnleggende forståelse for programvareutviklingens særegenheter og ikke minst konsekvensene av å “kutte hjørner”.

Vi har her et vanskelig og grunnleggende problem. Hvor høy rente har egentlig denne gjelda? Er det mulig å si noe generelt om dette? Det er ekte vanskelig å måle “vedlikeholdsvennligheten” til systemer. Når da tilliten mellom IT-avdelingen og forretningssiden (som vanlig) er frynsete, hjelper det ikke så mye om utviklerne eller de på drift roper høyt. “Det kan da umulig være så ille, de bare misliker å bli presset på tid!”

De som har makt blir målt kortsiktig. Jeg har jobbet tett med mange organisasjoner og blir stadig overrasket over at selv om “alle” forstår teknisk gjeld så går de fremdeles i fella! Kall det gjerne “luksusfellen”. Man forstår det innerst inne, men som vi ser på TV3 evner vi ikke å ta det inn over oss. Det kan være ulike grunner til at vi havner der, men hodesakelig kommer det nok av at de som bestemmer ikke kommer seg ut av gamle tankemønstere og strukturer.

Noen steder er det salg som er for dominerende. De styres tradisjonelt med provisjoner og de lover rutinemessig litt mer enn de kan stå inne for. Hele organisasjonen kommer “på hæla” og man venner seg til at man må ofre det gode håndtverket på tidspressets alter. Andre steder er ikke salgsdrevet, men snarere budsjettdrevet. I forbindelse med budsjettering eller anbud “selger” interessentene/leverandørene inn ideene og planene sine og i denne prosessen faller man for fristelsen til å “bråestimere” omfang og å låse en løsning. Deretter blir oppgaven å forsøke å holde det man på sviktende grunnlag har lovet. Prosjektets deadline blir styrende og når dette punktet nærmer seg blir alt annet enn framdrift lett ofret. Det tragiske er at i dette scenarioet kan Prosjektet være en suksess, målt på sluttermin. Men om man måler vedlikeholdsvennligheten til dette systemet et år etterpå vil svaret ofte være noe annet – den tekniske gjelda er stor. Det burde være unødvendig å påpeke at dagbøter i forbindelse med IT-kontrakter er selve oppskriften på å pådra seg teknisk gjeld.

Hva kan vi gjøre?

Teknisk gjeld adresseres implisitt på veldig mange måter gjennom Smidig programvareutvikling. For det første kan vi benytte omfang (scope) som variabel når vi styrer mot en tidsfrist. Jeg har beskrevet hvordan her. Ved å betrakte omfanget som åpent, der vi forplikter oss til løsning og funksjonalitet i “siste ansvarlige tidspunkt” synliggjør vi framdriften på en helt annen måte og får fokus vekk fra tid.

Vi kan gi utviklerne langt større myndighet og ikke minst ansvar for selve produktet, slik at de virkelig begynner å bry seg. De kan også eie visjonen og kravene – sammen med forretningssiden.

Forretningssiden/kunden og IT-siden må forstå – og respektere – hverandre bedre. De må rett og slett jobbe langt tettere sammen, slik man gjør i Scrum (om man følger “boka”).

Unngå de store “big-bang” leveransene – om man leverer i små inkrementer vil også kvalitetene bli satt på prøve tidligere og utviklerne få feedback på den jobben de gjør. Dette er uslåelig om man ønsker å lære – og det er vel det dette til syvende og sist dreier seg om.

 

Posted on June 20, 2013 at 10:29 am by gamsjo · Permalink
In: Kvalitet · Tagged with: , ,

2 Responses

Subscribe to comments via RSS

  1. […] at når vi måler vellykketheten, må vi i tillegg ta vedlikeholdsbarheten, eller graden av teknisk gjeld med i regnestykket. Så de store, tidkrevende leveransene er per definisjon langt mer risikable enn […]

  2. […] ofres til fordel for framdrift. Det er jo tross alt det prosjektet og leverandøren blir målt på. Vi kaller dette akkumulert teknisk gjeld. The Project Management Triangle (kostnad – framdrift – omfang) representerer kanskje […]

Subscribe to comments via RSS

Leave a Reply