Hvad er teknisk gæld, og hvorfor er det værd at beskæftige sig med?

Den overordnede problemstilling

I de seneste årtier har der været et generelt fokus på, at organisationer gennemgår en digital transformation, således at der efterhånden er sket en (grad af) digitalisering af samtlige brancher. Som samfund er vi afhængige af den digitale infrastruktur og de digitale løsninger, der er blevet stillet til rådighed. Det skaber et stigende behov for at sikre, at disse systemer til stadighed er velfungerende. Der er risiko for, at der bliver taget smutveje og lavet midlertidige løsninger til nye såvel som eksisterende it-systemer. Dette fænomen kaldes teknisk gæld. Hvis ikke den tekniske gæld bliver håndteret, kan det lamme organisationen, således de ikke kan lave nyudvikling og bliver tvunget til at rydde op i deres tekniske gæld.

Hvem er jeg, og hvorfor udtaler jeg mig om emnet?

Jeg forsvarede min Ph.d. ’styring af teknisk gæld i den offentlige sektor’ i august 2022. Min baggrund for at skrive om netop dette emne bundede i en frustration over (1) ikke at forstå fænomenet, (2) hvor meget den hindrede videreudvikling og (3a) savne viden om teknisk gæld problematikken (3b) herunder hvordan man håndterer teknisk gæld. Opfattelsen af teknisk gæld har historisk set været begrænset til softwareudviklerne, og den kode de skrev. Men jeg mener, at teknisk gæld som begreb og metafor sagtens kan bredes ud til flere organisationsniveauer såvel som til andre roller. Jeg er nemlig ikke softwareudvikler, jeg har en uddannelse inden for digitale medier og design, digital innovation og management. Derudover har jeg primært arbejdet som applikation manager – med alle de dertilhørende kasketter. 

Hvad er teknisk gæld? Hvilke fordele og ulemper er der ved teknisk gæld?

Kort fortalt er teknisk gæld de genveje man tager under it-udviklingen, hvilket kan være smart, fordi man på kort sigt sparer tid og ressourcer ved at introducere teknisk gæld i it-systemerne. Det kan både være deadlines, som er kritiske at nå eller quick-fixes, som er nødvendige at lave. Derfor kan det være, at ledelsen tager en strategisk beslutning om at lave teknisk gæld, og dermed er teknisk gæld ikke længere kun udviklerens problem eller skyld. På længere sigt kan teknisk gæld forårsage fejl og problemer, hvilket gør, at det samlet set kan blive dyrere at sikre velfungerende it-systemer. Derfor er det essentielt, at man håndterer den tekniske gæld og minimerer risikoen for, at kvaliteten i it-systemerne bliver forringet. Dog er det ikke al teknisk gæld, som skal løses, det kan være gæld, som har minimal indflydelse eller risiko, så man vælger at lade den være og prioriterer andre opgaver over gælden. Alternativt, at gælden er så kompleks og dyr, at man simpelthen ikke har råd til at håndtere den. Alligevel er det vigtigt at identificere og erkende gældens eksistens og at tage stilling til, hvornår (tidspunkt eller event) den tekniske gæld bliver kritisk. 

Mere nørderi om definitionen 

Teknisk gæld som begreb blev første gang beskrevet af Ward Cunningham i 1992. Siden da har flere forskere forsøgt at komme med en definition, men de bliver ved med at vende tilbage til Cunninghams oprindelige beskrivelse af fænomenet. Cunningham forklarer teknisk gæld som noget, der opstår i det øjeblik, man trykker ’deploy’, fordi verden omkring koden hele tiden er i forandring (inklusive forretningsbehov og teknologiske muligheder). Oprindeligt er teknisk gæld primært blevet forbundet til kildekode og den enkelte udviklers evner og beslutninger. Dermed har tilbagebetalingen af den tekniske gæld hvilet på softwareudviklernes skuldre. Men teknisk gæld eksisterer på flere niveauer, og baggrunden for at det bliver skabt, er sjældent kun en softwareudvikler med begrænsede egenskaber og viden. Dermed lægger jeg i dette indlæg op til en dialog, som man med fordel kan starte på i it-afdelingen. 

Charles Kettering: “A problem well stated is a problem half solved”

Du kan læse mere om teknisk gæld kategoriseringer i det andet blogindlæg og om brugen af måleværktøjer i det tredje blogindlæg.

Kilder

Fairbanks, G. (2020). Ur-technical debt. IEEE Software, 37(4), 95-98.
Cunningham, W. (1992). The WyCash portfolio management system. ACM SIGPLAN OOPS Messenger, 4(2), 29-30.
Nielsen, M., & Skaarup, S. (2021, October). IT Portfolio management as a framework for managing Technical Debt: Theoretical framework applied on a case study. In 14th International Conference on Theory and Practice of Electronic Governance (pp. 89-96).