Teknisk gæld (også kendt som kodningsgæld ) er en metafor for softwareudvikling, der refererer til de akkumulerede problemer i softwarekoden eller arkitekturen , der er forbundet med forsømmelse af kvalitet i softwareudvikling og forårsager yderligere arbejdsomkostninger i fremtiden. Teknisk gæld er normalt usynlig for slutbrugerne af produktet, men er forbundet med mangler i vedligeholdelse , testbarhed, forståelighed, modificerbarhed, portabilitet . I analogi med finansiel gæld kan teknisk gæld vokse til med " renter " - hvilket gør det sværere (eller endda umuligt) at fortsætte udviklingen, yderligere tid som udviklere bruger på at ændre et softwareprodukt, rette fejl, vedligeholde osv. Selvom en stigning i teknisk gæld er normalt negativ påvirker fremtiden for projektet, det kan også være en bevidst, kompromis beslutning dikteret af omstændighederne.
I sig selv er dårlig kode ikke altid teknisk gæld, da skaden ("renter på gælden") kommer fra behovet for at ændre koden over tid [1] .
Begrebet teknisk gæld bruges primært i relation til softwareudvikling, men det kan også anvendes på andre ingeniørområder.
Nogle gange bruges udtrykket forkert, hvilket angiver ældre kode , der ikke længere understøttes , som er af dårlig kvalitet og er skrevet af en anden [1] .
Almindelige årsager til teknisk gæld (der kan være flere) [2] :
"Rentebetalinger" vises både under lokal udvikling og i mangel af teknisk support fra andre projektudviklere. Fortsat udvikling af projektet kan øge omkostningerne ved "gælds tilbagebetaling" arbejde i fremtiden. Teknisk gæld tilbagebetales ved blot at afslutte igangværende arbejde.
Ophobningen af teknisk gæld er en væsentlig årsag til projektforsinkelser. Det er svært at vurdere præcist, hvor meget arbejde der skal til for at betale af på gælden. En ubestemt mængde igangværende arbejde tilføres projektet ved hver ændring. Deadlines "brænder", når projektet forstår, at der stadig er meget mere arbejde i gang (gæld) end tid til at færdiggøre det. For at have forudsigelige frigivelsesplaner skal udviklingsteamet begrænse mængden af arbejde, der udføres, til et niveau, der minimerer mængden af igangværende arbejde (teknisk gæld).
Mens Manny Lehmans lov om stigende kompleksitet allerede havde bevist, at den konstante udvikling af programmer øger deres kompleksitet og forringer deres design, mens de arbejdes på, lavede Ward Cunningham først sammenligningen mellem teknisk kompleksitet og gæld i en rapport fra 1992:
I sin artikel "Refactoring with Patterns" fra 2004 argumenterer Joshua Kerievsky for en sammenligning af omkostningerne ved at adressere arkitektonisk fejlbehandling, som han beskriver som "strukturel gæld" [5] .
Handlinger, der kan forsinkes, omfatter dokumentation, skrivning af tests, opmærksomhed på kommentarer mærket "TODO", bekæmpelse af compileren og advarsler om statisk kodeanalyse . Andre sager om teknisk gæld omfatter en videnbase, der ikke deles inden for en organisation, og kode, der er for kompleks til let at kunne ændres.
I open source-software er det teknisk gæld at forsinke indsendelse af lokale ændringer til hovedprojektet. .