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.

Hvorfor tager vi emnet op?

Vores motivation for at skrive om emnet bunder i en konstatering af at mange ikke forstår fænomenet, hvor meget det hindrer videreudvikling og savner viden om teknisk gæld problematikken 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 teknisk gæld som begreb og metafor bør bredes ud til flere organisationsniveauer såvel som til andre roller.

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).