Hvad er teknisk gæld, og hvordan undgår I den?

Hvad er teknisk gæld?

Teknisk gæld er det ekstra arbejde, I skal betale senere, fordi et system blev lavet hurtigt eller billigt nu. Ligesom almindelig gæld vokser den med renter, jo længere den får lov at stå.

Begrebet stammer fra softwareudvikleren Ward Cunningham, der sammenlignede visse beslutninger i udviklingen med et lån. En genvej giver hurtig værdi i dag. Til gengæld skal der betales tilbage senere, og indtil det sker, løber renterne. Renterne er i dette tilfælde ekstra arbejde, fejlrettelser, langsommere ændringer og i værste fald sikkerhedsrisici.

Gæld er i sig selv ikke forkert. Mange sunde virksomheder er startet på et lån, og mange gode systemer er startet som en hurtig løsning. Teknisk gæld i software bliver først et problem, når ingen ved, at gælden findes, eller når ingen har ansvaret for at betale af på den. Så vokser den stille, indtil den en dag bestemmer, hvad I kan og ikke kan. Det modsatte er et fleksibelt forretningssystem, der er bygget til at kunne ændres.

Sådan opstår teknisk gæld

Teknisk gæld opstår sjældent, fordi nogen sjusker. Den opstår af helt almindelige grunde, som de fleste virksomheder vil kunne genkende.

Hurtige beslutninger

Der skal bruges en løsning til på mandag, så den bygges til på mandag. Det er ofte den rigtige beslutning i øjeblikket. Gælden opstår, når genvejen bliver permanent, fordi der aldrig kommer en tirsdag, hvor den bliver lavet ordentligt.

Manglende erfaring

Den, der byggede systemet, gjorde sit bedste med den viden, der var. Senere viser det sig, at strukturen ikke kan bære flere brugere, flere data eller en ny type opgave, og hver ændring kræver et nyt lappeværk.

Krav, der ændrer sig

Forretningen vokser, og der kommer nye produkter, nye kunder og nye måder at gøre tingene på. Systemet blev designet til dengang. Hver gang det bøjes til noget, det aldrig var tænkt til, lægges der lidt mere gæld oveni.

Teknologi, der forælder

Selv et velbygget system står stille i en verden, der bevæger sig. Det, systemet bygger på, bliver med tiden forældet og skal opdateres. Bliver det ikke gjort, vokser afstanden, og til sidst er opdateringen et helt projekt i sig selv.

Hvor gemmer teknisk gæld sig i en mindre virksomhed?

Hos mindre virksomheder ligger gælden sjældent i et stort it-system. Den ligger i regneark, der er vokset sig store, i det hjemmebyggede system, som kun én person forstår, og i små løsninger, der fik lov at blive.

Tag regnearket. Det er et fremragende værktøj, og det var den helt rigtige start. Så kom der et ark mere til ordrerne, et til kalkulationerne og et til faktureringen. Jeres kollega Mette ved, hvilke celler der ikke må røres, og hvilket ark der er det nyeste. Den dag hun holder ferie, opdager resten af huset, hvor meget viden der kun ligger i hendes hoved.

Det samme gælder det lille system, som en dygtig medarbejder eller en bekendt skrev for nogle år siden. Det virker, og derfor har ingen set på det længe. Der findes ingen dokumentation, og den, der skrev det, er gået videre. Hver ændring bliver et forsøg, hvor ingen helt ved, hvad der går i stykker. Læs mere om, hvad der sker, når regnearket bliver brugt som database.

Hvad med kode, der er skrevet hurtigt med AI?

AI kan skrive kode, der virker, på meget kort tid, og det er et reelt fremskridt. Kode, som ingen har læst og forstår, er dog teknisk gæld fra første dag, uanset hvor godt den ser ud.

Det kaldes ofte vibe-coding: Man beskriver, hvad man vil have, og lader en AI skrive programmet, indtil det ser ud til at virke. Til en prototype eller et lille internt værktøj kan det være helt fint. Det bliver en risiko, når løsningen stille og roligt bliver det sted, hvor ordrer, kunder eller økonomi ligger.

Spørgsmålene er de samme som ved al anden kode. Hvem forstår, hvordan den hænger sammen? Hvem retter den, når noget går galt en fredag eftermiddag? Hvem sørger for, at den bliver opdateret? Transformio bruger også AI, til det trivielle, så tiden går til det, der kræver omtanke. Det afgørende er, at et menneske stadig står på mål for resultatet.

Platform eller egen kode: Hvem betaler renterne?

Begge veje har en pris. En platform betyder licens og binding til leverandøren. Egen kode betyder, at I selv har ansvaret for vedligeholdelse, opdateringer og sikkerhed, også om mange år.

Med en low-code-platform som Zoho Creator betaler I løbende for at bruge platformen, og jeres system lever inden for dens rammer. Til gengæld er det platformens leverandør, der holder selve platformen ved lige, mens jeres samarbejdspartner står for det, der er bygget ovenpå.

Med egen kode slipper I for licensen, og I ejer koden selv. Det lyder som frihed, og det kan det også være. Nogen skal dog holde koden opdateret, rette fejl og følge med, når det, koden bygger på, ændrer sig. Den regning forsvinder ikke, fordi der ingen licens er. Den er bare sværere at se, indtil den kommer.

Low-code fjerner heller ikke gælden af sig selv. Et system på en platform kan også blive rodet, hvis det bygges uden plan, uden test og uden dokumentation. Det rigtige spørgsmål er derfor, hvem der har ansvaret for helheden over tid, og om I kan leve med den binding, valget giver. Stil det spørgsmål, før I vælger.

Fire vaner, der holder teknisk gæld nede

Uanset om systemet er kodet fra bunden eller bygget på en platform, er det de samme vaner, der gør forskellen over tid.

Versionsstyring

Hver ændring gemmes, så det kan ses, hvad der blev ændret, og hvornår. Går noget galt, kan I vende tilbage til en version, der virkede. Det gør det trygt at forbedre systemet, fordi et fejltrin kan rulles tilbage.

Test før udrulning

Nye funktioner prøves af, før kollegerne får dem i hænderne. Det tager lidt tid hver gang og sparer meget tid senere, fordi fejlene bliver fundet, inden kunden eller jeres kollega på lageret støder på dem.

Dokumentation

Hvad gør systemet, hvorfor er det bygget sådan, og hvor hænger tingene sammen? Når det er skrevet ned, kan en ny udvikler tage over uden at starte forfra, og systemet hviler ikke længere på én persons hukommelse.

Én ansvarlig for helheden

Gæld vokser, hvor ingen har ansvaret. Sørg for, at én part ejer systemet over tid, kender det, holder det opdateret og siger til, når en genvej er ved at blive permanent. Det kan være en medarbejder eller en fast ekstern partner.

Ofte stillede spørgsmål