Teknisk gæld: hvorfor små ændringer pludselig tager uger

I beder om noget, der lyder simpelt: et ekstra felt på fakturaen, en ny rabattype i webshoppen, en eksport til regnskabet. Svaret fra udvikleren er tre uger og en advarsel om, at noget andet måske går i stykker undervejs. Sidste år tog den slags en eftermiddag. Det er det mest almindelige tegn på teknisk gæld, og det er et problem, som næsten alle virksomheder med software ældre end et par år kender. Den gode nyhed er, at gæld kan måles, prioriteres og betales af, præcis som den økonomiske slags.

Hvad er teknisk gæld? En forklaring uden fagsprog

Udtrykket blev opfundet af softwareudvikleren Ward Cunningham i begyndelsen af 1990’erne, og metaforen holder stadig. Når et system bygges med genveje for at nå en deadline, låner I tid. Lånet er hovedstolen: det arbejde, der skulle have været gjort ordentligt. Renten er den ekstra tid, I betaler på hver eneste ændring bagefter, fordi udvikleren skal arbejde rundt om genvejen. Så længe ingen rører systemet, mærker I intet. Så snart I vil videreudvikle, begynder renten at løbe, og den vokser med hver ny genvej, der lægges oven på den gamle.

Teknisk gæld opstår på to måder. Den bevidste gæld er et valg: I lancerer en enkel første version for at teste markedet og ved, at dele skal bygges om senere. Den er sund, når den er skrevet ned og har en plan. Den ubevidste gæld opstår af sig selv: uerfarne udviklere, skiftende leverandører, krav der ændrede sig undervejs, eller teknologi der blev forældet, mens systemet stod stille. Den farligste gæld er den, ingen ved, de har, fordi den først opdages, når noget haster.

Hvilke typer teknisk gæld findes der?

Afhængighedsgæld fortjener ekstra opmærksomhed, fordi den vokser, selv når ingen rører koden. Et framework, der var nyt for fire år siden, kan i dag mangle sikkerhedsopdateringer, og jo længere I venter, jo større bliver springet til den nyeste version. Vi har en separat tjekliste til IT-sikkerhed i software, der viser, hvad I skal holde øje med.

Hvordan ser I, at jeres software har teknisk gæld?

I behøver ikke kunne læse kode for at se tegnene. De viser sig i hverdagen, i tilbuddene fra leverandøren og i stemningen hos dem, der arbejder med systemet. Gå listen igennem, og sæt et kryds ved hvert punkt, I genkender. Tre eller flere kryds betyder, at det er tid til en gennemgang.

• Små ændringer bliver estimeret i uger, og estimaterne holder sjældent.
• Der kommer nye fejl efter næsten hver udgivelse, ofte steder, ingen har rørt.
• Udviklerne siger "det tør vi ikke røre ved" om dele af systemet.
• Kun én person, internt eller hos leverandøren, kan forklare, hvordan det hænger sammen.
• I har udskudt opdateringer af framework, server eller plugins i mere end et år.
• Systemet bliver langsommere, efterhånden som I får flere data og brugere.
• Nye udviklere skal bruge uger på at sætte sig ind i koden, før de kan bidrage.
• Der findes ingen automatiske tests, så alt skal klikkes igennem i hånden.
• Medarbejderne har opfundet manuelle omveje, fx regneark ved siden af systemet.
• Leverandøren foreslår en ny løsning, hver gang I spørger efter en ændring.

Det, vi ser i praksis, er, at punkt fire og fem oftest hænger sammen. Når én udvikler har bygget og passet systemet alene i flere år, bliver opdateringer udskudt, fordi der altid er noget mere presserende. Så forlader udvikleren projektet, og den næste overtager både koden og fem års udskudt vedligeholdelse. Det er ikke usædvanligt, at den første måned hos en ny leverandør går med at få systemet op på en version, der overhovedet kan opdateres sikkert.

Hvad koster teknisk gæld? Et regneeksempel

Forestil jer en intern webapp til ordrer og lager, bygget for fem år siden. I bruger cirka 300 udviklertimer om året på små og mellemstore ændringer, til en timepris på 1.100 kr. Fordi koden er sammenfiltret og uden tests, tager hver opgave i gennemsnit halvanden gang så lang tid, som den ville i et sundt system. Det er renten. Tabellen viser, hvad den koster, og regnestykket kan I lave med jeres egne tal.

De 165.000 kr. er kun den synlige del. Dertil kommer de funktioner, I valgte fra, fordi de var for dyre, fejl der rammer kunderne, medarbejdere der bruger tid på omveje, og risikoen for et sikkerhedsbrud i en forældet komponent. Hvis en målrettet oprydning koster 150.000–250.000 kr. og halverer renten, er den tjent hjem på få år. Det er den samlede regning, I skal holde op mod prisen for at gøre noget ved det. Læs også, hvordan vi regner den løbende drift af en hjemmeside eller app, for vedligeholdelse er det, der holder renten nede.

Er al teknisk gæld dårlig? Hvornår gæld er et fornuftigt valg

Nej. Gæld er et værktøj, og som i økonomien kan et lån være klogt. En startup, der vil teste, om kunderne vil betale, gør ret i at bygge en enkel MVP med genveje og vente med den perfekte arkitektur, til markedet har sagt ja. Det samme gælder en kampagneside, der kun skal leve i tre måneder. Gælden bliver først et problem, når den glemmes, når den vokser uden plan, eller når et midlertidigt system ender med at køre virksomheden i fem år.

Et nyt eksempel er prototyper lavet med AI-værktøjer som Lovable, Bolt eller Cursor. De er fantastiske til at vise en idé på få dage, men koden er sjældent bygget til tusindvis af brugere, persondata og betaling. Det er bevidst gæld i stor skala, og den skal håndteres, før produktet går i drift. Vi har skrevet en guide om at gå fra AI-prototype til produktion.

Hvordan betaler man teknisk gæld af? En plan i fem trin

Refaktorering, modernisering eller nyt system?

Den sidste række er den dyreste og den mest fristende. Et nyt system lover en ren start, men rummer en skjult risiko: alt det, det gamle system gør, som ingen har skrevet ned. Vi bygger derfor nye systemer i etaper, hvor én del ad gangen flyttes over og testes mod det gamle. Læs mere om, hvordan vi gør, under modernisering af ældre systemer.

Hvordan undgår I ny teknisk gæld fra starten?

Den billigste gæld er den, I aldrig optager. Det handler mest om de aftaler, I laver med jeres leverandør, før projektet går i gang. Kopiér spørgsmålene herunder ind i en mail til jeres nuværende eller kommende leverandør, og se, hvor konkrete svarene er.

1. Skriver I automatiske tests, og for hvilke dele af systemet?
2. Bliver al kode gennemgået af en anden udvikler, før den går i drift?
3. Hvor ofte opdaterer I framework, pakker og server, og er det med i den faste pris?
4. Hvordan dokumenterer I systemet, så en anden udvikler kan overtage det?
5. Skriver I det ned, når vi vælger en genvej for at nå en deadline?
6. Ejer vi koden, og ligger den i et repository, vi har adgang til?
7. Hvilken teknologi bygger I i, og hvor udbredt er den om fem år?

Spørgsmål seks er vigtigere, end det ser ud. Ejer I ikke koden, kan I ikke få en anden til at vurdere gælden, og så er I helt afhængige af leverandørens egen vurdering. Vi har samlet alt om rettigheder, repositories og konti i guiden hvem ejer koden.

Hvilke myter om teknisk gæld skal I passe på?

Hvordan holder Ceptiv teknisk gæld nede?

Vi bygger i React, Next.js og TypeScript, som er udbredte og godt vedligeholdte teknologier, og vi bygger fra bunden, så der ikke er en stak plugins at holde styr på. Vores faste månedlige drift dækker hosting, vedligeholdelse, opdateringer, support, sikkerhed og backup, så afhængighedsgælden ikke får lov at hobe sig op i et skuffeår. I ejer kode og data, og I kan følge projektet i vores kundepanel. Overtager vi et eksisterende system, starter vi med en gennemgang og en prioriteret liste, så I kan se gælden i kroner, før I beslutter noget.

Står I med et system, der er blevet tungt at arbejde med, så beskriv det kort, og få en fast pris på en gennemgang eller en afgrænset oprydning. I får et skriftligt tilbud inden for 24 timer.