Begrepet teknisk gjeld er mye brukt innenfor systemutvikling. De fleste har en forståelse av hva det å ha gjeld innebærer, også personer som ikke jobber med IT. Derfor er det enkelt å omtale diverse utfordringer man har i prosjektet sitt som teknisk gjeld ovenfor resten av organisasjonen. Teknisk gjeld blir gjerne assosiert med noe som senker leveranseevnen og er kostbart i det lange løp. Dette er ofte også ensbetydende med at man tar opp en gjeld for å raskt kunne komme videre, men at dette medfører en ekstra kostnad som senere må betales tilbake. Helst tenker nok en del at dette er noe man ønsker å bli helt kvitt. Det er med andre ord ikke assosiert med noe positivt, men gir det egentlig mening at vi utviklere bruker begrepet oss i mellom?

Slik fungerer gjeld

De fleste vet hvordan finansiell gjeld fungerer. Når man skal kjøpe en bolig vil mange måtte ta opp et boliglån. Lånet vil ha en rentesats som gjenspeiler den årlige kostnaden for å låne pengene. Si at du skal kjøpe en bolig og du låner tre millioner kroner av banken. Gitt at renten er på seks prosent, må du da betale 180000 kr i året i renter. La oss for enkelhets skyld se bort fra skattefradraget. Dersom du i tillegg ønsker å betale ned på lånet betaler du noe mer. Alt du betaler utover disse 180000 kronene betyr at du betaler ned på gjelden.

Om du så i tillegg ønsker å kjøpe deg bil, og tar opp 300000 kr mer i billån med syv prosent rente, vil bare rentene på dette lånet tilsvare 21000 kr årlig. Har man i tillegg andre lån som forbrukslån eller kredittkortgjeld, så er gjerne renten mye høyere, men forhåpentligvis er også lånebeløpet lavere. Poenget er at på tross av mange uavhengige lån så er det enkel matematikk å summere nøyaktig hvor mye det koster deg tilsammen å ha disse lånene. I et lengre perspektiv blir det dermed fort tydelig at man bør prioritere å betale lån med høyere rente før man eksempelvis betaler ekstra avdrag på annen gjeld.

Så er spørsmålene:

  • Er finansiell gjeld sammenlignbart med teknisk gjeld i systemutvikling?
  • Gir det egentlig mening at tekniske ressurser er enige om at teamet har mye teknisk gjeld?

Hvor trykker skoen egentlig?

Heldigvis vil jeg si, så er ikke systemutvikling bare et enkelt mattestykke. Likevel bruker utviklere begrepet teknisk gjeld i øst og vest, og man unngår dermed å diskutere konkrete utfordringer. Hva mener utviklerne er kredittkortgjelden i ditt prosjektet? Og dersom man bare snakker om teknisk gjeld uten å bli konkret, diskuterer man da i det hele tatt hvor skoen trykker?

I mange prosjekter jeg har jobbet har det blitt snakket om teknisk gjeld. Ofte er alle i teamet enig om at man har teknisk gjeld i noen grad. Dersom man imidlertid i stedet begynner å diskutere konkrete utfordringer, så blir det fort tydelig at folk har helt forskjellig mening om hva den faktiske tekniske gjelden består av.

Et team-medlem vil i et møte for å diskutere dette kanskje starte med å påpeke at man bør prioritere å fikse modul X, fordi den er alt for ustabil. Han sier at den både skaper ustabilitet og nedetid for kundene. Ved å si dette vil de andre i teamet faktisk kunne ha en forutsetning for å diskutere problemstillingen videre. En annen i teamet anerkjenner problemstillingen, men kontrer med at det ikke er modul X som er det egentlige problemet. Hun mener i stedet at man må endre hvordan dataene hentes inn, siden denne koden i stor grad er ansvarlig for de dårlige dataene som er rotårsaken til at modul X blir ustabil. En tredje person sier at han forstår begge problemstillingene, men akkurat nå har teamet andre utfordringer som er enda viktigere. Han mener at bygget nå er så tregt at det knapt er mulig å få inn nye endringer i kodebasen. Neste person kaster seg inn med en helt annen utfordring som teamet må ta stilling til.

Problemstillingene over er nok satt litt på spissen og vitner kanskje vel så mye om manglende kommunikasjon internt i teamet. Samtidig er det mest ment som om et eksempel på at man må dykke ned i de konkrete utfordringene for å faktisk få til en fruktbar diskusjon. Dersom du skal gjøre en slik øvelse, så pass på at hele teamet involveres, og vær tydelig på at dette ikke handler om å finne syndebukker. Dette bør være en positiv øvelse der teamet sammen finner ut av ting. Vær nysgjerrig, kanskje lærer dere alle noe nytt om applikasjonene dere er ansvarlig for.

Vær konkret

Det viktige er altså at man går fra at alle i teamet er enig om at man har teknisk gjeld, til at man faktisk diskuterer de konkrete utfordringene teamet sliter med. Dette vil neppe føre til at alle i teamet blir enige om alt. Det er heller ikke målet. Noen ting vil sannsynligvis også måtte forbli uendret, men teamet tvinges til å diskutere konkrete problemstillinger som vil føre til håndfaste tiltak. Teamet blir med andre ord mer bevisst på hvilke lån som har høyest rente. Kanskje er det også slik at noen av problemene ikke krever all verdens innsats å løse, og dermed kan redusere gjelden betraktelig med liten innsats. Her er det ikke sikkert man treffer hver gang på det viktigste problemet, men man diskuterer om ikke annet konkrete løsninger fremfor å være enig om at man har utfordringer.

Et annet moment hvor man bør skille finansiell gjeld fra teknisk gjeld er mulighetene for fullstendig tilbakebetaling. De fleste boligeiere håper på et tidspunkt på å kunne bli gjeldfri, og for mange vil det gjennom et langt liv med jevne avdrag kunne bli en realitet. Teknisk gjeld blir man imidlertid i overordnet forstand aldri helt kvitt. Så sant da ikke prosjektet legges ned. Et levende IT systemet med nyutvikling og vedlikehold vil alltid måtte forbedres og flikkes på. Selv de mest ferdige IT systemer bør få nye sikkerhetspatcher, samt justeres for å overholde nye standarder innen for eksempel universell utforming. Sånn sett kan man si at man aldri blir helt gjeldfri, og det er også helt greit.

Kontinuerlig vedlikehold

La oss i stedet sammenligne det å ha teknisk gjeld med å ta vare på boligen du kjøper. Akkurat som i et IT prosjekt må man jevnlig gjøre vedlikehold på boligen. Kanskje vil man på sikt også gjøre større ting som å sette opp mindre bygg rundt på tomten, bygge ut eller lage nye fine uteplasser. Dersom man imidlertid ikke gjør helt grunnleggende vedlikehold underveis ender man gjerne med både vannlekkasje og råte i huset. Om man imidlertid fikser problemer fortløpende, så er det ikke så mye som skal til. Totalt sett blir det billigere. Er du heldig slipper du gjerne også å bygge nytt hus fra grunnen av hver fjerde år, noe som ofte er tilfellet for IT systemer. Man trenger imidlertid ikke overdrive. Det er unødvendig å male hele huset om igjen hvert år. Javisst, huset får en veldig flott glans, men her får man gjerne mer igjen for å gjøre andre og billigere tiltak. Som regel blir man enige om slike ting når man vurderer konkrete tiltak opp mot hverandre. Akkurat på samme måte som at utviklere i teamet faktisk identifiserer utfordringene internt ved å være konkrete fremfor å være enige om at teamet har teknisk gjeld.

Bruk gjerne begrepet teknisk gjeld ut mot resten av organisasjonen. Det er lett forståelig og gir en gjenkjennelsesfaktor på et overordnet nivå. Det kommuniserer til andre deler av organisasjonen at det trengs noe vedlikehold parallelt med at det gjøres nyutvikling. Pass dere imidlertid for å bruke det intern i teamet, det vil sannsynligvis ikke bidra til annet enn at dere hopper over viktige og konkrete diskusjoner.