Teknisk gæld forklaret for ledere: hvad det koster at vente

Teknisk gæld er de genveje, forældede valg og udskudte oprydninger i din software der gør hver ny ændring langsommere og mere risikabel end den behøver at være. Det fungerer som et lån: du fik noget hurtigere i hånden, og nu betaler du renter i form af ekstra udviklingstid og flere fejl indtil gælden bliver afdraget. At vente koster derfor penge hver måned, også selvom der aldrig kommer en regning med posten.

Jeg er freelanceudvikler, og en del af mit arbejde er at vedligeholde og videreudvikle eksisterende systemer, så jeg har en interesse i emnet. Målet med guiden er at du kan tale om teknisk gæld med din udvikler eller dit bureau uden at skulle læse en linje kode.

Den korte version

Den nemmeste måde at forstå teknisk gæld på er at holde den op mod et almindeligt banklån. Metaforen stammer fra udvikleren Ward Cunningham der præsenterede den i 1992, og den er stadig den bedste forklaring jeg kender.

Beslutningsreglen er enkel: du behøver ikke være gældfri, men du skal vide hvor gælden ligger, og du skal betale renten med vilje, ikke ved et uheld. Koster den samme slags opgave mærkbart mere i dag end for et år siden, løber der renter et sted. Teknisk gæld er én tråd i et større forløb, og hvordan den opstår og håndteres gennem et helt projekt, kan du se i guiden til hvordan et softwareprojekt foregår fra idé til drift.

Hvad teknisk gæld er, og hvad det ikke er

Martin Fowler, en kendt forfatter inden for softwaredesign, giver et eksempel jeg selv bruger meget. En ny funktion ville tage 4 dage i en ryddelig kodebase, men tager 6 dage fordi koden omkring den er rodet. De 2 ekstra dage er renten. At rydde op ville måske koste 5 dage, og det er ikke pengene værd for én funktion. Står der et par lignende funktioner mere på planen, ser regnestykket anderledes ud. Du kan læse hans egen forklaring i Fowlers artikel om technical debt.

Teknisk gæld er altså ikke et spørgsmål om pæn eller grim kode. Det er et økonomisk spørgsmål om hvad fremtidige ændringer kommer til at koste.

Fire slags gæld

Fowler deler gælden op efter to spørgsmål: blev den taget med vilje, og var det klogt? Det giver fire typer som han beskriver i sin gældskvadrant:

• Bevidst og klog: "Vi lancerer nu og rydder op bagefter." En god forretning hvis bagefter faktisk kommer.
• Bevidst og uklog: "Vi har ikke tid til at gøre det ordentligt." Ofte den dyreste slags fordi renterne løber hurtigere end man tror.
• Ubevidst og uklog: koden er skrevet af nogen der ikke vidste bedre, fx i et system der er bygget meget billigt eller af mange hænder.
• Ubevidst og klog: først efter noget tid i drift forstår man hvordan systemet burde være bygget. Den slags gæld er uundgåelig og helt normal.

Det forveksles ofte med teknisk gæld

• Fejl. En fejl er noget der virker forkert i dag. Gæld er noget der gør det dyrere at ændre i morgen, selvom gæld ofte fører til flere fejl.
• Gammel teknologi. Et ti år gammelt system kan være velbygget og billigt at vedligeholde. Alder er ikke gæld i sig selv, men manglende opdateringer er.
• Manglende funktioner. Det du gerne vil have, men ikke har, hører til på ønskelisten og ikke i gældsregnskabet.

Hvor gælden kommer fra

Gæld opstår sjældent fordi nogen er dovne. De typiske årsager er helt almindelige:

• Tidspres. En deadline eller en vigtig kunde der venter, og så vinder den hurtige løsning over den rigtige.
• Krav der ændrer sig. Systemet blev bygget til én måde at arbejde på, og nu arbejder I anderledes. Det er normalt, og det er en af grundene til at jeg foretrækker at bygge i små trin (mere om det i sammenligningen af agil udvikling og vandfald).
• Manglende tests. Uden automatiske tests tør ingen rydde op fordi ingen kan se om noget går i stykker.
• Forældede afhængigheder. Framework og pakker der ikke bliver opdateret, bliver sværere at løfte for hver version der udkommer. Det gennemgår jeg i hvad det koster at udskyde opdatering af framework og pakker.
• Mange hænder uden fælles retning. Har flere udviklere eller bureauer bygget videre efter hinanden, er der tit tre forskellige måder at løse det samme problem på.
• Manglende dokumentation. Viden der kun findes i én persons hoved, forfalder den dag personen stopper.

Sådan viser gælden sig i leveringstid og fejl

Som leder ser du sjældent koden, men du ser konsekvenserne. Det er de tegn jeg ville holde øje med:

• Estimaterne vokser for den samme slags opgave. Det der tog en uge sidste år, tager tre nu.
• Selve ændringen går hurtigt, men test og udgivelse trækker ud.
• En rettelse ét sted ødelægger noget et andet sted, og gamle fejl kommer igen.
• Udgivelser bliver sjældnere og mere nervøse, og der er uskrevne regler om aldrig at udgive om fredagen.
• Én udvikler er den eneste der tør røre et bestemt område, og nye udviklere skal bruge uger på at komme i gang.
• Du hører oftere "det kræver en større ombygning" om noget der lyder simpelt.

DORA, et forskningsprogram der undersøger hvordan softwareteams leverer, måler blandt andet hvor lang tid der går fra en ændring er skrevet til den er i drift, og hvor stor en andel af udgivelserne der kræver akut indgriben bagefter. Deres pointe er at hastighed og stabilitet ikke er modsætninger: de bedste teams er gode til begge dele (DORA's metrikker for softwarelevering). Teknisk gæld trækker begge tal den forkerte vej.

Hvor meget fylder det? I en undersøgelse som Stripe fik lavet i 2018 blandt mere end 1.000 udviklere, anslog udviklerne at en gennemsnitlig udvikler i deres virksomhed brugte 13,5 timer om ugen på teknisk gæld ud af en arbejdsuge på godt 41 timer (Stripe: The Developer Coefficient). Det er selvrapporterede tal, men størrelsesordenen siger noget: renten er ikke en afrundingsfejl.

Vil du selv vurdere hvor dit system står, kan du gå mine 12 tegn på en sund eller syg kodebase igennem uden teknisk baggrund.

Hvad det koster at vente

Det lumske ved teknisk gæld er at den ikke sender regninger. Den gør bare alt lidt langsommere, så gradvist at det ligner det normale.

Tag et tænkt regneeksempel. Du køber 40 udviklertimer om måneden, og en fjerdedel af dem går med at arbejde uden om gammel kode, rette fejl der kunne være undgået og teste manuelt. Så betaler du 10 timer om måneden i rente, altså 120 timer om året, før der er bygget noget nyt. Gang det med din timepris. Tallene er kun et eksempel, men regnestykket kan du lave med dine egne.

Og renten stiger over tid:

• Ny kode arver de gamle problemer. Fem nye funktioner på et rodet fundament giver fem steder der skal ryddes op i stedet for ét.
• Forældede dele bliver sværere at løfte for hver ny version, og på et tidspunkt får den gamle version ikke længere sikkerhedsrettelser.
• Viden forsvinder. Jo længere tid der går, jo færre husker hvorfor koden ser ud som den gør.

Derudover kan lånet blive opsagt: en betalingsudbyder udfaser en gammel integration, hostingudbyderen fjerner en gammel PHP-version, et sikkerhedshul bliver kendt, eller den udvikler der kendte systemet, siger op. Så skal arbejdet laves med det samme og under pres, og det er altid dyrere end at gøre det i ro og mag.

Den mest oversete pris er de muligheder du ikke tager. Spørger en kunde efter en integration, og svaret er "det tager tre måneder", siger du måske nej til forretning. Det står ikke i noget regnskab, men det er ofte den største post.

Sådan afdrager du gælden i 6 trin

Du behøver ikke stoppe udviklingen for at betale af. Tænk på det som et afdragslån: et fast beløb hver måned og ekstra afdrag når der er luft.

1. Gør gælden synlig. Bed din udvikler om en kort liste over de største gældsposter: hvilket område, hvad det koster i hverdagen, og et groft skøn over oprydningen. Et regneark er rigeligt, bare du også kan læse det.
2. Mål renten. Følg i et par måneder hvor meget de faktiske timer afviger fra estimaterne, og hvor mange fejl der dukker op efter hver udgivelse. Så har du noget at sammenligne med.
3. Prioritér efter rente, ikke efter hvor grimt det ser ud. Den dyreste gæld ligger der hvor systemet ændres tit, og der hvor fejl gør ondt, fx betaling, login og fakturering. Rodet kode som ingen rører, kan godt få lov at ligge. Det er også Fowlers råd.
4. Afdrag løbende. Min tommelfingerregel er at sætte en fast andel af udviklingstiden af til oprydning, typisk 10-20 %, og at rydde op i det område man alligevel arbejder i.
5. Byg sikkerhedsnettet først. Før større oprydninger skal de vigtigste flows være dækket af automatiske tests. Hvorfor det betaler sig også i små projekter, forklarer jeg i artiklen om automatiserede tests.
6. Stop ny gæld ved kilden. Når I bevidst tager en genvej, så skriv den ned sammen med en plan for hvornår den skal betales tilbage.

Ryd op, omskriv eller lev med det

Når gælden er blevet stor, kommer spørgsmålet om man skal starte forfra. Mit svar er næsten altid nej, i hvert fald ikke på én gang.

• Løbende oprydning (refaktorering) forbedrer koden uden at ændre hvad den gør. Det er standardvalget: systemet kører videre, og risikoen er lav.
• Udskiftning i bidder bruges når en del er for dårlig til at redde. Et nyt modul bygges ved siden af det gamle, og funktionerne flyttes over én ad gangen.
• En fuld omskrivning er sidste udvej, fx når teknologien er helt uddød, eller forretningen har ændret sig så meget at systemet løser det forkerte problem.

Nogle gange er det rigtige at leve med gælden: når systemet skal udfases inden for et år, når en første version skal vise om idéen holder (så længe du ved at regningen kommer hvis den holder), eller når den rodede del næsten aldrig bliver ændret og derfor ikke koster rente.

Hvornår du ikke skal hyre en udvikler til det

Den slags opgaver er en del af det jeg lever af, men du skal ikke hyre en som mig hvis:

• du har en intern udvikler med tid og erfaring. Giv hellere vedkommende plads til at afdrage end at hente en ny ind som først skal lære systemet at kende.
• gælden ligger i en teknologi jeg ikke arbejder med. Jeg arbejder med Laravel, PHP og JavaScript (React og Next.js), så til fx .NET eller Java skal du finde en specialist.
• problemet i virkeligheden er at ingen er enige om hvad systemet skal kunne. Så hjælper oprydning ikke.
• det er et færdigt system du betaler abonnement på. Så er det leverandørens gæld, og dit valg handler om at blive eller skifte.

Næste skridt

Start med at få gælden på papir. Tag spørgsmålene herunder med til næste møde med din udvikler, og bed om en liste med de fem største gældsposter og et groft skøn over renten på hver. Så har du det du skal bruge for at prioritere, uanset hvem der skal lave arbejdet.

Har du ingen fast udvikler i dag, eller vil du have et par friske øjne på systemet, kan du se hvordan jeg arbejder med vedligehold og videreudvikling af eksisterende systemer. Du får direkte kontakt med mig der skriver koden, koden er din fra første dag, og du får svar inden for én hverdag.

Ofte stillede spørgsmål

Kan man undgå teknisk gæld helt?+

Nej, og det bør du heller ikke forsøge. Selv et velbygget system får gæld når forretningen ændrer sig, og ofte forstår man først efter noget tid i drift hvordan det burde have været bygget. Målet er at holde gælden kendt og renten lav, ikke at nå nul. Et system helt uden gæld kan faktisk være et tegn på at der er brugt for meget tid på perfektion frem for at lære af rigtige brugere.

Skaber AI-genereret kode teknisk gæld?+

Det kan den, og ofte hurtigere end kode skrevet i hånden. AI-værktøjer er gode til at lave kode der virker her og nu, men de kender ikke resten af systemet og gentager gerne en løsning i stedet for at genbruge den der allerede findes. Uden tests og en udvikler der gennemgår koden, vokser gælden stille. Bruges værktøjerne af en erfaren udvikler med tests i ryggen, er de en stor hjælp.

Hvem har ansvaret for teknisk gæld, udvikleren eller mig?+

I deler det. Udvikleren har ansvaret for at gøre gælden synlig, forklare hvad den koster og sige fra når en genvej bliver for dyr. Du har ansvaret for prioriteringen fordi det er en forretningsbeslutning hvor meget tid der skal gå til oprydning frem for nye funktioner. Det fungerer dårligst når udvikleren rydder op i det skjulte, eller når oprydning bliver valgt fra hver eneste gang.

Kan man måle teknisk gæld med et værktøj?+

Delvist. Værktøjer til kodeanalyse kan finde kompleks kode, gentagelser og forældede pakker, og de er nyttige til at følge udviklingen over tid. Men de kan ikke se hvilke dele der koster dig penge fordi de ikke ved hvad der ændres tit eller hvad der er forretningskritisk. Brug dem som et termometer, ikke som en prioriteringsliste. De bedste mål er stadig leveringstid og antallet af fejl efter udgivelser.