Teknisk gæld er de genveje og forældede løsninger i et softwareprodukt, der gør hver ny ændring langsommere og mere risikabel. Som ved gæld i banken får I noget nu og betaler senere, og renten er den ekstra tid, som alt fremtidigt arbejde tager. Gæld er et normalt redskab, når den optages med åbne øjne. Problemet opstår, når ingen ved, hvor stor den er, og når alt salg og al udvikling bygger ovenpå den. For en direktør er det vigtigste at forstå, at gælden viser sig som langsommere leveringer og flere fejl, længe før nogen kalder det teknisk gæld.
Hvordan gælden opstår
Der er tre kilder, og de skal håndteres forskelligt.
- Bevidste genveje. I skulle nå en vigtig kunde eller teste en idé på markedet, og teamet valgte en hurtig løsning. Det kan være en god beslutning, når nogen skriver den ned og ved, at den skal betales tilbage.
- Læring undervejs. Da produktet blev bygget, vidste I mindre om kunderne, end I gør i dag. Koden afspejler gamle antagelser, selv om den var fin på det tidspunkt.
- Aldring. Biblioteker, sprogversioner og platforme ældes, også selv om ingen rører koden. Det gælder særligt produkter i gammel teknologi.
Hvad gælden koster
Gælden kan mærkes tre steder, selv om regnskabet ikke viser den.
Tid. En ændring, der burde tage en dag, tager en uge, fordi udvikleren først skal forstå koden, og fordi ændringen rammer noget andet. Når en direktør spørger hvorfor udviklingen går langsommere, er gælden ofte en stor del af svaret.
Risiko. Ingen tør ændre bestemte dele, fejl dukker op i moduler, der ikke blev rørt, og hver udgivelse føles som et væddemål. På et tidspunkt rammer det kunderne.
Mennesker. Dygtige udviklere vil løse nye problemer. Bruger de dagene på at slås med det gamle, søger de væk, og tilbage står dem, der kender koden og ikke kan undværes.
Et tænkt eksempel: En mellemstor kunde ønsker en ny rabatmodel. Salget forventer et par dages arbejde. Prisberegningen ligger imidlertid fire forskellige steder i koden, fordi den er kopieret ved hver særaftale, så teamet bruger tre uger og finder fejl i to af de andre kundeopsætninger undervejs. Den ekstra tid er renten på fire gamle genveje.
Hvorfor den ikke forsvinder af sig selv
Gæld vokser, fordi ny kode bygges oven på den gamle. Hver funktion, der lægges på en dårlig løsning, gør løsningen sværere at ændre. Samtidig vinder nye funktioner næsten altid prioriteringen, for de har en kunde og en dato, og oprydningen har ingen af delene.
Det er her, ledelsen kommer ind. Teamet kan ikke selv tage tiden, hvis alle mål handler om nye funktioner. Gælden ender altså på ledelsens bord, uanset hvor den opstod.
Ikke al gæld skal betales
Det er en udbredt misforståelse, at målet er nul gæld. Gammel kode, som ingen behøver ændre, koster stort set ingen rente, selv om den er grim. Prioritér gælden efter to spørgsmål: Hvor ofte skal denne del ændres? Og hvad sker der, hvis den fejler?
Dele, der ændres ofte, og som kunderne er afhængige af, er stedet at starte. Dele, der ligger stille, kan vente. Sådan bliver “vi skal bruge tid på oprydning” til en konkret prioritering, og hvordan listen bygges op, står i sådan gør I teknisk gæld synlig.
Fem spørgsmål til teamet
Stil disse på næste møde. Svarene behøver ikke være præcise.
- Hvilken del af produktet undgår I helst at røre, og hvorfor?
- Hvad ville blive markant hurtigere, hvis én ting blev rettet?
- Hvilke genveje tog vi bevidst det seneste år, og er de betalt tilbage?
- Hvilke komponenter er ikke længere understøttet af dem, der laver dem?
- Hvad er det seneste, der gik galt, fordi noget var gammelt eller uoverskueligt?
Bliver svarene vage, eller er der uenighed i teamet, er det i sig selv en oplysning. Det betyder, at ingen ejer overblikket.
Det, ledelsen skal beslutte
Tre beslutninger er ledelsens. Hvor stor en del af kapaciteten går fast til at holde produktet sundt? Hvem må sige nej til en ny funktion, fordi fundamentet skal rettes først? Og hvad skal gæld stå på ved den faste status? Svarene hører hjemme i den tekniske køreplan, så platformsarbejdet får samme synlighed som funktionerne. Er gælden så stor, at spørgsmålet om en større ombygning melder sig, er det næste skridt valget mellem at skrive om og forbedre gradvist.
Det skal I lade være med
- At bruge teknisk gæld som samlebetegnelse for alt, udviklerne ikke kan lide · bed om konsekvensen i tid eller risiko.
- At aftale en stor oprydning én gang for alle · gælden kommer igen, hvis der ikke er plads til den i det faste arbejde.
- At bebrejde dem, der tog genvejene · de fleste blev taget af gode grunde på det tidspunkt.
Det skal I kræve af den eksterne
- ☐ Et overblik over gælden, forklaret som tid og risiko og uden fagord.
- ☐ En prioritering efter, hvad der ændres oftest, og hvad kunderne er afhængige af.
- ☐ Forslag til, hvor meget af kapaciteten der skal gå til sundhed, med begrundelse.
- ☐ En fast måde at følge gælden på ved ledelsesmøderne.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Skal produktet skrives om? · Gennemgang af produktet
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
