Tidligt i min karriere som nyudnævnt associeret produktchef, da jeg første gang hørte om teknisk gæld (også kaldet teknisk gæld), var jeg ikke helt sikker på, hvad det betød. Ironisk nok troede jeg, at det henviste til et lån, vi havde optaget for at købe tredjepartssoftware, og jeg brugte selvsikkert udtrykket forkert i to eller tre uger. Forestil dig min forlegenhed, da mine udviklere tog mig til side efter statusmødet for forsigtigt at korrigere mig!

Så for at spare os alle for lidt rødmen på jobbet og hjælpe os med at opbygge anerkendelse blandt vores udviklere, lad os se nærmere på, hvad teknisk gæld er, og hvorfor vi som produktchefer bør interessere os for det.

Hvad er teknisk gæld, og hvornår er det et problem?

Softwareudvikling handler om at afbalancere bredden af produktets funktionalitet med kode af høj kvalitet. Undervejs tager vi nogle gange genveje for at fremskynde udviklingsprocessen – disse genveje kaldes teknisk gæld eller teknisk gæld.

Hvornår er det en god idé at påtage sig teknisk gæld, og hvornår bliver det en tikkende bombe? For at besvare dette spørgsmål ser vi først på den tekniske gælds historie.

Hvad er teknisk gæld?

Ward Cunningham, som opfandt udtrykket, sammenligner teknisk gæld med finansiel gæld – det er i orden at låne på bekostning af fremtidig hastighed og stabilitet, men vi skal betale gælden tilbage på et tidspunkt. Det er et koncept, som alle udviklingsteams bør forstå, og som alle produktchefer bør tage i betragtning, når de træffer produktbeslutninger.

Teknisk gæld hjælper os med at udgive produkter før tidsplanen og få produkterne hurtigere i hænderne på kunderne. Men vi er nødt til på et tidspunkt at “nedbringe gælden” ved at investere i kvaliteten af vores kodebase.

Ideelt set bør vi aktivt beslutte, om vi vil gøre brug af teknisk gæld, eller om vi vil undgå den. Ligesom med finansiel gæld ønsker vi ikke senere at blive overrasket af en uforudset omkostning!

En forenklet definition af teknisk gæld

Teknisk gæld (også kaldet kodegæld i nogle teams) henviser til de underforståede omkostninger ved det fremtidige omarbejde, der bliver nødvendigt, når man vælger en kortsigtet genvej frem for en bedre tilgang, som ville tage længere tid. Det svarer til at betale renter på et lån – omkostningerne ved teknisk gæld stiger over tid.

En analogi, jeg bruger, er at barbere skæg. Hvis jeg har travlt og barberer mig hurtigt, er det sandsynligvis ikke den mest grundige barbering nogensinde, og jeg er nødt til at vende tilbage senere for at få det gjort ordentligt.

Den tid og indsats, der kræves til begge barberinger – den første barbering og den efterfølgende oprydningsbarbering – vil samlet set være større, end hvis jeg havde foretaget en ordentlig barbering fra starten.

Men nogle gange, når vi er ved at løbe tør for tid, er vi nødt til at vælge den hurtige barbering!

Sammenligning af finansiel gæld og teknisk gæld

For at gøre dette koncept mere konkret kan vi se lidt nærmere på sammenligningen mellem finansiel gæld og teknisk gæld. Produktchefer er trods alt nødt til at forstå både forretningsmæssige finansbegreber og tekniske kodebegreber!

Fordele ved finansiel gæld: Finansiel gæld muliggør gearing. At låne penge kan give den kapital, der er nødvendig for at investere i vækstmuligheder. Finansiel gæld giver også øjeblikkelig adgang til ressourcer eller aktiver uden krav om forudbetaling.

Ulemper ved finansiel gæld: Finansiel gæld medfører mange forskellige former for omkostninger. Rentebetalinger på finansiel gæld kan ophobe sig over tid og reducere den samlede rentabilitet. Og manglende korrekt håndtering af finansiel gæld kan føre til økonomisk ustabilitet.

Desuden kan gæld begrænse den økonomiske fleksibilitet og forhindre os i at forfølge bestemte veje i fremtiden. Og misligholdelse af finansielle forpligtelser kan skade en organisations omdømme.

Fordele ved teknisk gæld: Teknisk gæld muliggør hurtigere indledende produktudvikling, hvilket hjælper med at overholde stramme tidsfrister eller udnytte markedsmuligheder. Og ligesom finansiel gearing kan det at påtage sig teknisk gæld reducere de indledende udviklingsomkostninger.

Ulemper ved teknisk gæld: Ligesom renter ophober sig på finansiel gæld, vokser den tekniske gæld, når yderligere funktioner eller ændringer bygges oven på de eksisterende genveje, hvilket gør den fremtidige udvikling mere kompleks og dyrere. Og teknisk gæld fører ofte til suboptimal kodekvalitet, hvilket med tiden medfører højere vedligeholdelsesomkostninger.

Teknisk gæld kan hæmme et produkts evne til at tilpasse sig ændrede markedsforhold eller indarbejde nye funktioner. Og teknisk gæld, der ikke håndteres, kan føre til systemfejl, sikkerhedssårbarheder eller problemer med ydeevnen, hvilket påvirker produktets levedygtighed.

Hvad betyder det for os? For både finansiel gæld og teknisk gæld er målet ikke at undgå gæld fuldstændigt. I stedet er forsigtig styring nøglen.

Selvom en vis gæld kan være strategisk for vækst, skal vi nøje overvåge og håndtere gælden for at minimere langsigtede negative konsekvenser.

Eksempler på teknisk gæld

Inden for softwareudvikling støder udviklingsteams regelmæssigt på teknisk gæld. Lad os gennemgå et par af de mest almindelige eksempler.

Forældet kode

Nogle teams bruger måske forældet ældre kode for hurtigt at få en funktion ud. Det kan give øjeblikkelig funktionalitet, men kan senere kræve omfattende refaktorering, især når der tilføjes nye funktioner. Ligesom et gammelt manuskript er ældre kode blevet videregivet gennem generationer af udviklere og har ophobet historiens tyngde.

Selvom den måske tjente sit formål beundringsværdigt i sin storhedstid, har tiden en måde at erodere dens tilpasningsevne og vedligeholdbarhed på. Nedetid og fejl i produktionen har en tendens til at dukke op, når vi stoler for meget på ældre kode!

Hårdkodning

Hårdkodning henviser til praksissen med at indlejre specifikke værdier eller konstanter direkte i koden i stedet for at bruge konfigurerbare indstillinger.

Selvom denne tilgang kan fremskynde udviklingen på kort sigt, fører den ofte til komplikationer senere hen. Forestil dig et scenarie, hvor en hårdkodet værdi, såsom en filsti eller en timeout-tærskel, skal ændres på tværs af en omfattende kodebase. Det kan hurtigt blive en tidskrævende og fejlbehæftet opgave, som bringer softwarens vedligeholdbarhed og fleksibilitet i fare.

For at undgå denne faldgrube bør udviklere vælge konfigurerbare indstillinger, som forbedrer kodens tilpasningsevne.

Kodeduplikering

Kodeduplikering forekommer, når lignende eller identiske kodestykker optræder flere steder i projektet. I begyndelsen kan det virke som en praktisk genvej, der sparer tid under udviklingen. Men efterhånden som softwaren udvikler sig, og kravene ændrer sig, bliver det en indviklet dans at bevare konsistensen og foretage opdateringer.

Kodeduplikering øger ikke kun risikoen for at introducere fejl, men mangedobler også den indsats, der kræves til fremtidige forbedringer og fejlrettelser. Stræben efter genbrug af kode og eliminering af overflødig kode er grundlæggende principper til at modvirke dette problem.

Manglende dokumentation

Dokumentation fungerer som den ledetråd, der oplyser vejen for nuværende og fremtidige udviklere. Fraværet af omfattende dokumentation svarer til at begive sig ud på en kompleks rejse uden et kort. Det kan begynde med mangel på indlejrede kommentarer, der forklarer begrundelsen bag bestemte kodevalg, eller udvikle sig til manglende brugervejledninger og dokumentation af systemarkitekturen.

Selvom den indledende udviklingsfase måske forløber problemfrit, kan de langsigtede konsekvenser være alvorlige. Fejlfinding bliver en kryptisk opgave, vidensoverførsel mellem teammedlemmer bliver vanskelig, og skalering af projektet minder ofte om at navigere gennem en labyrint i mørket. Grundig dokumentation er det fyrtårn, der oplyser vejen frem i softwareudvikling.

Manglende automatiserede tests

Fraværet af automatiserede tests svarer til at sejle en båd uden først at kontrollere, om den har lækager. Automatiserede tests (herunder enheds-, integrations- og regressionstests) er årvågne vogtere af kodekvalitet og stabilitet.

Når de udelades, er konsekvenserne måske ikke umiddelbart synlige. I begyndelsen kan udviklingen skride hurtigt frem, og softwaren kan se funktionel ud. Men efterhånden som kodebasen udvides og udvikler sig, begynder uforudsete problemer at dukke op. Regressionsfejl, hvor funktioner, der tidligere fungerede, går i stykker på grund af nye ændringer, bliver almindelige.

Uden automatiserede tests som sikkerhedsnet må udviklingsteamet stole på manuel testning, en tidskrævende og fejlbehæftet proces. Ved at indføre automatiseret testning fra starten sikres en stabil kurs på det stormfulde hav af softwareudvikling.

Hvilken rolle spiller teknisk gæld i agil udvikling?

Ah, agil udvikling! Dens scrum-metoder og principper fra det agile manifest omfavner forandring og hastighed. Men hvor passer teknisk gæld ind? Teknisk gæld omtales trods alt ikke specifikt i de grundlæggende dokumenter om agil udvikling.

Her er en analogi fra Star Wars: Millennium Falcon blev løbende vedligeholdt af Han Solo og Chewbacca for at holde den i topform til deres forehavender. På samme måde håndterer et agilt produktteam teknisk gæld for at opretholde softwarekvaliteten og muliggøre heroiske eventyr for deres kunder! 

Sådan anvendes og håndteres teknisk gæld

I agile teams er der en forståelse af, at man nogle gange pådrager sig teknisk gæld for hurtigt at imødekomme forretningsbehov. Husk, at det ikke altid er en dårlig ting at pådrage sig teknisk gæld. Martin Fowler, en førende tænker inden for agil softwareudvikling, påpeger, at det handler om afvejninger. Man kan acceptere en vis gæld tidligt i softwareproduktets livscyklus for at validere et koncept eller nå hurtigere ud på markedet.

Det afgørende er at håndtere den tekniske gæld. Teknisk gæld bør dokumenteres i backloggen, prioriteres og håndteres i fremtidige sprints. For at dette kan ske, skal produktchefer læne sig op ad en stærk projektstyring, og de skal have en god forståelse af omfanget af den tekniske gæld, der hidtil er blevet påtaget.

Hvornår er teknisk gæld et problem?

Når interessenter er uvidende om teknisk gæld, eller når udviklingsprocessen i høj grad er afhængig af nødløsninger, er det dér, alarmklokkerne bør begynde at ringe. Hvorfor?

1. Den er usynlig: Uden målepunkter eller regelmæssige kodegennemgange kan skjulte sårbarheder opstå.
2. Den påvirker brugeroplevelsen: Hvis underliggende problemer begynder at påvirke funktionaliteten, er det ikke kun udviklernes problem; det er et forretningsproblem.
3. Den hæmmer nye funktioner: Programmører, der sidder fast i dårlig kode, er mindre produktive, og kreativiteten falder.
4. Den er ikke på køreplanen: Teams bør være opmærksomme på teknisk gæld og have en strategi for den. Tøv ikke med at benytte eksterne webinarer og ressourcer til at lægge en handlingsplan.

Sådan måler du teknisk gæld

Ved hjælp af værktøjer som DevOps-praksisser og automatisering kan teams holde øje med deres kodebase og følge med i den tekniske gæld, der indtil videre er blevet opbygget. Nedenfor har jeg samlet tolv forskellige måder, du kan holde styr på teknisk gæld på.

Du behøver ikke bruge dem alle! Se i stedet denne liste som et udgangspunkt. Vælg én eller to, som du kan implementere i løbet af den næste måneds tid, og opbyg derefter gradvist teamets kunnen inden for at spore og løse teknisk gæld.

1) Statisk kodeanalyse: Værktøjer som SonarQube, ESLint eller FindBugs kan automatisk analysere kode for forskellige problemer, såsom kodekompleksitet, kodelugte og potentielle fejl. De leverer kvantitative målepunkter for kodekvalitet og teknisk gæld baseret på foruddefinerede regler og tærskelværdier.

2) Kodedækning: Vi kan vurdere, hvor stor en del af kodebasen der er dækket af automatiserede tests, ved at måle kodedækningen med værktøjer som JaCoCo eller Istanbul. Lavkode-dækning kan være tegn på manglende test og potentiel teknisk gæld.

3) Kodegennemgange blandt kolleger: Kodegennemgange blandt kolleger giver udviklere mulighed for at identificere og diskutere potentielle elementer af teknisk gæld. Og to hjerner er bedre end én – det er en god måde at undgå dårlige kodemønstre på! Teams kan bruge tjeklister eller retningslinjer til at vurdere kodekvaliteten og dokumentere identificerede problemer. Antallet og alvoren af de problemer, der findes under gennemgange, kan fungere som et kvalitativt mål for teknisk gæld.

4) Manuelle kodeinspektioner: Udviklere og teams kan udføre manuelle kodeinspektioner eller gennemgange for at identificere områder i kodebasen, der kan have gavn af refaktorering. Denne proces involverer ofte erfarne udviklere, der gennemgår kode og dokumenterer problemer, da de typisk har den bedste fornemmelse for teknisk designgæld. 

5) Backlog over teknisk gæld: Vedligeholdelse af en produktbacklog eller en liste over identificerede elementer af teknisk gæld er en almindelig praksis. Hvert element i backloggen bør indeholde en beskrivelse, en konsekvensvurdering og en prioritering. Størrelsen og prioriteten af elementerne i backloggen giver et kvalitativt mål for teknisk gæld.

6) Sporing af fejl og problemer: Analyse af processen for fejlprioritering kan afsløre hyppigheden og alvoren af problemer, der er relateret til teknisk gæld. Et stort antal fejlrapporter eller hyppige gentagelser af de samme problemer kan være tegn på underliggende teknisk gæld.

7) Estimering og historiepoint: Når udviklingsteams planlægger nyt arbejde eller brugerhistorier, kan de estimere den indsats, der kræves for at håndtere elementer af teknisk gæld. Denne indsatsestimering, ofte i form af historiepoint i Agile-metoder, kvantificerer det arbejde, der er nødvendigt for at løse teknisk gæld.

8) Målepunkter for kodekompleksitet: Målepunkter som cyklomatisk kompleksitet, antal kodelinjer og kodeændringer kan give indsigt i kodebasens kompleksitet og vedligeholdelsesvenlighed. Højere kompleksitet og omfattende ændringer i bestemte kodeområder kan være tegn på teknisk gæld.

9) Brugerfeedback: Brugerfeedback og supportanmodninger kan indirekte fremhæve teknisk gæld. Hyppige brugerklager over systemets ydeevne, pålidelighed eller uventede adfærd kan være tegn på underliggende problemer, der skal håndteres.

10) Målepunkter for automatiserede tests: Overvågning af målepunkter relateret til automatiserede tests, såsom testkørselstid, andelen af fejlslagne tests og ustabile tests, kan hjælpe med at vurdere testinfrastrukturens tilstand og identificere områder, der er påvirket af teknisk gæld.

11) Undersøgelser og interviews: Undersøgelser og interviews med udviklingsteams kan give kvalitative indsigter i det oplevede niveau af teknisk gæld og dens indvirkning på produktivitet og kodekvalitet. Og indsamling af feedback fra interessenter kan give indsigt i, hvor omarbejde kan være nødvendigt.

12) Kvadranten for teknisk gæld: Et særligt nyttigt værktøj er kvadranten for teknisk gæld, som blev introduceret af Martin Fowler. Den kategoriserer årsagerne til teknisk gæld som bevidste eller utilsigtede samt hensynsløse eller velovervejede og hjælper teams med at forstå afvejninger.

Ud over disse tolv måder at måle teknisk gæld på bør du ikke tøve med at bruge værktøjer til produktstyring til at hjælpe med at administrere dit teams sporing og håndtering af teknisk gæld!

Afvikling af teknisk gæld

Vi har talt meget om at pådrage sig teknisk gæld, men vi har endnu ikke gennemgået, hvordan man afvikler den. Som produktchefer er det vores ansvar at guide vores teams i at beslutte, hvornår gælden skal afvikles, og hvornår der skal pådrages yderligere teknisk gæld.

Vi afvikler teknisk gæld, når udviklere opdaterer kodebasen for at håndtere tidligere identificerede elementer af teknisk gæld. Det kan omfatte redesign af funktionalitet for at gøre den mere effektiv, implementering af automatiserede tests eller udarbejdelse af grundig dokumentation af koden.

En af de bedste måder at nedbringe den på er at afsætte tid i hvert sprint til at styrke kodebasen og afvikle gælden. Tænk på det som at betale et månedligt realkreditlån – jo hurtigere vi kan nedbringe lånet, desto mindre rente skal vi samlet set betale!

En god tommelfingerregel er 80/20-reglen. Det vil sige, at man bruger omkring 80 % af tiden i hvert sprint på at udvikle nye funktioner og 20 % af tiden på at prioritere tekniske investeringer og forbedringer.

Når du planlægger at nedbringe teknisk gæld, bør du integrere den i din produktkøreplan i overensstemmelse hermed.

Afsluttende tanker om teknisk gæld

For at samle det hele op er håndtering af teknisk gæld ikke kun udviklernes opgave. Produktchefer, agile teams og forretningsinteressenter spiller alle en rolle.

Det endelige mål? At levere et softwareprodukt af høj kvalitet, der opfylder forretningsmålene uden at pådrage sig uholdbar gæld.

Så uanset om du dykker ned i det dybe hav af softwareudvikling eller blot forsøger at forstå, hvorfor dit udviklingsteam bliver ved med at tale om refaktorering, er det at forstå og håndtere teknisk gæld det kompas, du har brug for.

Og uanset om du er tidligt i din produktkarriere, eller om du allerede er en erfaren veteran inden for produktstyring, vil du næsten altid have gavn af at uddybe din forståelse af teknisk fagsprog.

Jeg håber, du vil undgå at begå den samme fejl, som jeg begik tidligt i min karriere – stol ikke udelukkende på kontekstuelle ledetråde, når du skal gætte dig til ukendte tekniske begreber!

Tag dig i stedet tid til at lave research, se eksterne vejledninger som disse, og brug tid sammen med dine udviklere for at opfriske din værdifulde viden.

Hvis du vil have flere indsigter og vejledninger om produktstyring, så glem ikke at tilmelde dig vores nyhedsbrev!