Hvad koster teknisk gæld i praksis?
En almindelig tommelfingerregel er at teknisk gæld æder 20–40 procent af udviklingsteamets tid. For et team der koster 530.000 DKK om måneden, svarer det til 110.000–210.000 DKK hver måned der går til at håndtere gammel kode i stedet for at bygge nyt. Gælden ses som langsommere leverancer, flere fejl og højere estimater.
Teknisk gæld står aldrig som en linje på fakturaen, men den betales hver måned. Den ses som funktioner der tager tre uger i stedet for én, fejl der vender tilbage, og tilbud der bliver dyrere for hvert år. Sådan sætter du tal på gælden så den kan prioriteres som enhver anden udgift.
Hvad teknisk gæld er, på beslutningstagersprog
Teknisk gæld er summen af genveje i kode og arkitektur: løsninger der var hurtige at bygge dengang, men som gør hver kommende ændring langsommere nu. Sammenligningen med et lån er rammende. Genvejen er lånebeløbet, og renten er den ekstra tid teamet betaler hver gang det arbejder i den del af systemet. Ligesom med lån er problemet sjældent selve gælden, men at ingen holder øje med renten.
Så meget koster den: 20–40 procent af udviklingstiden
En almindelig tommelfingerregel i branchen er at 20–40 procent af udviklingstiden går til at håndtere teknisk gæld i stedet for at bygge nyt. Regn det om til penge for dit eget team:
| Udviklingsudgift pr. måned | Gældens udgift (20–40 %) | Pr. år |
|---|---|---|
| 270.000 DKK (lille team) | 53.000–110.000 DKK/md. | 640.000 DKK–1,3 mio. DKK |
| 530.000 DKK (mellemstort team) | 110.000–210.000 DKK/md. | 1,3–2,6 mio. DKK |
| 1,1 mio. DKK (flere teams) | 210.000–430.000 DKK/md. | 2,6–5,1 mio. DKK |
Tallene er spænd og varierer med kodebasens alder og tilstand, men selv den nedre grænse svarer til en fuldtidsudvikler der året rundt ikke laver andet end at betale renter.
Sådan ses gælden i tilbud og fakturaer
Gælden er usynlig i regnskabet, men fuldt synlig i mønstrene hvis du ved hvor du skal kigge:
- Langsommere leverancer. Ændringer der “burde være enkle”, tager uger. Gennemløbstiden for lignende opgaver vokser år for år.
- Flere fejl. En voksende andel af den fakturerede tid går til rettelser og akutte udrykninger i stedet for ny funktionalitet.
- Højere estimater. Leverandører der regner på en uoverskuelig kodebase, lægger et risikotillæg på: Du betaler for usikkerheden, ikke kun for arbejdet.
- Personafhængighed. Kun en eller to personer tør røre visse dele af systemet. Deres kalender bliver din flaskehals.
Regneeksempel: Hvornår kan en refaktorering betale sig?
Antag at en type funktion I ofte bygger, lad os sige nye integrationsflows, tager tre uger i den nuværende kodebase og at en refaktorering til 320.000 DKK ville få det ned på to uger. En udvikleruge hos et bureau koster groft sagt 43.000–58.000 DKK.
Bygger I ti sådanne funktioner i løbet af året, sparer refaktoreringen ti udvikleruger, altså 430.000–580.000 DKK. Investeringen er tjent hjem inden for året, og derefter er besparelsen ren gevinst. Oven i det når hver funktion ud til brugerne en uge tidligere. Samme regnestykke kan vendes om: Bygges der kun to sådanne funktioner om året, er refaktoreringen endnu ikke berettiget. Sådan skal gæld prioriteres: post for post, holdt op mod den faktiske brug. Lav regnestykket pr. gældspost, ikke for “gælden” som helhed; det er forskellen på et beslutningsgrundlag og et generelt suk.
Gør gælden synlig og styrbar
Gælden forsvinder ikke af at blive ignoreret, men den behøver heller ikke at blive “betalt af” i ét stort stopprojekt. Tre vaner rækker langt:
- List gælden. Bed teamet rangordne de ti dyreste gældsposter med anslået rente. Nu er gælden et beslutningsgrundlag, ikke en fornemmelse.
- Afsæt en fast andel. Et almindeligt pejlemærke er 10–20 procent af hver sprint til afdrag på gælden, først og fremmest i de dele af koden der ændres oftest.
- Mål gennemløbstiden. Følg hvor lang tid lignende ændringer tager over året. Falder gennemløbstiden, virker refaktoreringen; stiger den, vokser gælden hurtigere end I betaler af.
Hos Weapp arbejder vi dagligt i både nye og overtagne kodebaser, og mønstret er tydeligt: De teams der budgetterer med gælden, leverer hurtigere over tid end dem der skubber den foran sig. Vil du have en second opinion på hvad gælden koster i jeres system? Kontakt os.
Ofte stillede spørgsmål
Er al teknisk gæld dårlig?
Nej. Bevidst optaget gæld kan være den helt rigtige beslutning: En første produktversion der tager genveje for hurtigt at nå ud på markedet, er en klassisk og sund afvejning. Problemet er ubevidst eller uhåndteret gæld: genveje som ingen husker, som ingen budgetterer med, og som vokser med renter.
Hvordan ved jeg hvor meget teknisk gæld vi har?
Se på symptomerne snarere end på koden: Gennemløbstiden for små ændringer stiger, fejlrettelser tager en voksende andel af tiden, estimaterne for lignende opgaver bliver højere for hvert år, og flere og flere ændringer kræver en bestemt person. Bed teamet liste de ti dyreste gældsposter med anslået udgift. Det plejer at være nok som beslutningsgrundlag.
Skal vi hellere skrive systemet om fra bunden?
Sjældent som første valg. En total omskrivning er dyr, tager lang tid og fastfryser ofte videreudviklingen imens. Trinvis refaktorering, hvor man forbedrer de dele der ændres oftest, giver afkast tidligere og med lavere risiko. En omskrivning er først berettiget når platformen aktivt står i vejen for forretningen.
Hvorfor bliver tilbud dyrere når kodebasen har meget gæld?
Leverandører prissætter usikkerhed. En svært læselig kodebase uden tests gør hvert estimat mere usikkert, og den usikkerhed ender som et risikotillæg i tilbuddet. Gælden betyder desuden at færre leverandører vil regne på opgaven, og det svækker din forhandlingsposition.
Kan AI-værktøjer mindske udgiften til teknisk gæld?
Delvis. AI-assisteret udvikling kan gøre refaktorering, testskrivning og dokumentation af gammel kode hurtigere, og det sænker prisen pr. afviklet gældspost. Men værktøjerne ændrer ikke behovet for prioritering: Hvilken gæld der skal betales af, og hvornår, er stadig en forretningsbeslutning.