Hva koster teknisk gjeld i praksis?

Teknisk gjeld står aldri som en linje på fakturaen, men den betales hver måned. Den viser seg i funksjoner som tar tre uker i stedet for én, i tilbakevendende feil og i tilbud som blir dyrere for hvert år. Her ser du hvordan du setter tall på gjelden slik at den kan prioriteres på linje med alle andre kostnader.

Hva teknisk gjeld er, forklart for beslutningstakere

Teknisk gjeld er summen av snarveier i kode og arkitektur: løsninger som var raske å bygge den gang, men som gjør hver kommende endring tregere nå. Sammenligningen med et lån er treffende. Snarveien er lånebeløpet, og renten er den ekstra tiden teamet betaler hver gang utviklerne jobber i den delen av systemet. Akkurat som med lån er problemet sjelden gjelden i seg selv, men at ingen holder oversikt over renten.

Så mye koster den: 20–40 prosent av utviklingstiden

En vanlig tommelfingerregel i bransjen er at 20–40 prosent av utviklingstiden går med til å håndtere teknisk gjeld i stedet for å bygge nytt. Regn det om til kroner for ditt eget team:

Tallene er spenn og varierer med kodebasens alder og tilstand, men selv den nedre grensen tilsvarer mesteparten av lønnen til en heltidsutvikler som året rundt ikke gjør annet enn å betale renter.

Slik vises gjelden i tilbud og fakturaer

Gjelden er usynlig i regnskapet, men godt synlig i mønstrene hvis du vet hvor du skal se:

• Tregere leveranser. Endringer som «burde være enkle», tar uker. Ledetiden for lignende oppgaver øker år for år.
• Flere feil. En stadig større andel av den fakturerte tiden går til feilretting og akutte utrykninger i stedet for ny funksjonalitet.
• Høyere estimater. Leverandører som regner på en uoversiktlig kodebase, legger på et risikopåslag. Du betaler for usikkerheten, ikke bare for arbeidet.
• Personavhengighet. Bare én eller to personer tør å røre visse deler av systemet. Kalenderen deres blir flaskehalsen din.

Regneeksempel: Når lønner refaktorering seg?

Anta at en type funksjon dere ofte bygger, for eksempel nye integrasjoner, tar tre uker i dagens kodebase, og at en refaktorering til 370 000 kr ville få det ned til to uker. En utvikleruke hos et byrå koster grovt regnet 50 000–68 000 kr.

Bygger dere ti slike funksjoner i løpet av året, sparer refaktoreringen ti utvikleruker, altså 500 000–680 000 kr. Investeringen er tjent inn i løpet av året, og deretter er besparelsen ren gevinst. I tillegg når hver funksjon brukerne en uke tidligere. Samme regnestykke kan snus: Bygges bare to slike funksjoner per år, er refaktoreringen ikke berettiget ennå. Slik bør gjeld prioriteres: post for post, opp mot faktisk bruk. Gjør regnestykket per gjeldspost, ikke for «gjelden» som helhet. Det er forskjellen på et beslutningsgrunnlag og et generelt sukk.

Gjør gjelden synlig og styrbar

Gjelden forsvinner ikke av å bli ignorert, men den trenger heller ikke å «betales ned» i ett stort prosjekt der all annen utvikling står stille. Med tre vaner kommer du langt:

1. List opp gjelden. Be teamet rangere de ti dyreste gjeldspostene med anslått rente. Da er gjelden et beslutningsgrunnlag, ikke en følelse.
2. Sett av en fast andel. En vanlig rettesnor er 10–20 prosent av hver sprint til nedbetaling av gjeld, først og fremst i de delene av koden som endres oftest.
3. Mål ledetiden. Følg hvor lang tid lignende endringer tar gjennom året. Synker ledetiden, har refaktoreringen effekt; stiger den, vokser gjelden raskere enn dere betaler ned.

Hos Weapp jobber vi daglig i både nye og arvede kodebaser, og mønsteret er tydelig: De teamene som budsjetterer for gjelden, leverer raskere over tid enn de som skyver den foran seg. Vil dere ha en second opinion på hva gjelden koster i systemet deres? Ta kontakt.