Teknisk gæld er ikke nødvendigvis et problem

Alle systemer får teknisk gæld. Også de gode. Det afgørende er ikke at undgå gælden, men at vide hvor den ligger, og hvornår den begynder at koste mere end den sparede tid.

Nogle tekniske kompromiser er helt bevidste. Måske skal en løsning hurtigt i markedet. Måske er et område midlertidigt. Måske giver det simpelthen ikke mening at bygge den perfekte arkitektur til en funktion, der bruges to gange om året.

Hvornår bliver gælden dyr?

Vi reagerer især, når gælden kan mærkes uden for udviklingsteamet. Det kan være, at selv små ændringer pludselig tager uger, at releases skaber uforudsigelige fejl, eller at sikkerhedsopdateringer ikke længere kan installeres uden risiko for at noget andet går i stykker.

Et andet klassisk tegn er, at alle ved, hvilken del af systemet man helst ikke skal røre ved. Hvis et modul kun kan ændres af én bestemt udvikler, er det ikke længere kun et kodeproblem. Det er en forretningsrisiko.

Skal man så skrive det hele om?

Som regel nej. En total omskrivning lyder tiltalende, fordi man slipper for den gamle kode. Til gengæld skal mange års forretningslogik genopdages, og man bytter kendte problemer ud med nye.

Vi foretrækker næsten altid at begynde med de områder, hvor gælden har størst konsekvens: høj ændringsfrekvens, høj driftsrisiko, sikkerhedsproblemer eller konkrete blokeringer for nye forretningsbehov.

En god gæld kan godt få lov at blive

Hvis gammel kode fungerer stabilt, sjældent ændres og ikke udgør en sikkerhedsrisiko, er det ikke sikkert, at det er pengene værd at modernisere den nu. Teknisk oprydning er ikke et mål i sig selv.

Sådan starter vi en oprydning

En teknisk gennemgang bør ende i en prioriteret plan, ikke i 200 Jira-tickets med kodeproblemer. Vi kobler derfor arkitektur, afhængigheder og kodekvalitet sammen med systemets forretningsmæssige betydning. Så kan gælden betales tilbage dér, hvor renterne faktisk gør ondt.