Tidlig i karrieren min som nyutnevnt produktleder, da jeg først hørte om teknisk gjeld (også kalt teknisk gjeld), var jeg ikke helt sikker på hva det betydde. Det er ganske morsomt, men jeg trodde det handlet om et lån vi hadde tatt opp for å kjøpe programvare fra tredjeparter, og jeg brukte dette begrepet feil med stor selvtillit i to eller tre uker. Forestill deg hvor flau jeg ble da utviklerne mine tok meg til side etter det daglige statusmøtet for å korrigere meg på en vennlig måte!

Så for å spare oss alle for litt rødming på jobben og hjelpe oss med å bygge troverdighet hos utviklerne våre, la oss se nærmere på hva teknisk gjeld er, og hvorfor vi som produktledere bør bry oss.

Hva er teknisk gjeld, og når er det et problem?

Programvareutvikling handler om å balansere bredden i produktfunksjonaliteten mot kode av høy kvalitet. Underveis tar vi noen ganger snarveier for å fremskynde utviklingsprosessen – disse snarveiene kalles teknisk gjeld.

Når er det en god idé å pådra seg teknisk gjeld, og når blir det en tikkende bombe? For å svare på dette spørsmålet skal vi først se på historien til teknisk gjeld.

Hva er teknisk gjeld?

Ward Cunningham, personen som fant på begrepet, sammenligner teknisk gjeld med finansiell gjeld – det er greit å låne mot fremtidig utviklingshastighet og stabilitet, men vi må betale tilbake gjelden til slutt. Det er et konsept alle utviklingsteam bør forstå, og alle produktledere bør ta hensyn til når de tar produktbeslutninger.

Teknisk gjeld hjelper oss med å lansere produkter før tidsplanen og få produktene raskere i hendene på kundene. Men vi må til slutt «betale ned gjelden» ved å investere i kvaliteten på kodebasen vår.

Ideelt sett bør vi aktivt beslutte om vi ønsker å benytte oss av teknisk gjeld, eller om vi ønsker å unngå den. I likhet med finansiell gjeld ønsker vi ikke å bli overrasket av en uforutsett kostnad senere!

En forenklet definisjon av teknisk gjeld

Teknisk gjeld (også kalt kodegjeld i enkelte team) viser til den underforståtte kostnaden ved fremtidig omarbeiding som blir nødvendig når du velger en kortsiktig snarvei fremfor en bedre tilnærming som ville tatt lengre tid. Det er som å betale renter på et lån – kostnaden ved teknisk gjeld øker over tid.

En sammenligning jeg bruker, er å barbere seg. Hvis jeg har dårlig tid og barberer meg raskt, blir det sannsynligvis ikke den glatteste barberingen noensinne, og jeg må komme tilbake senere for å gjøre det ordentlig.

Tiden og innsatsen som kreves for begge barberingene – den første barberingen og den andre oppryddingsbarberingen – blir totalt sett større enn om jeg hadde gjort en ordentlig barbering med én gang.

Men noen ganger, når vi begynner å gå tom for tid, må vi velge den raske barberingen!

Sammenligning av finansiell gjeld og teknisk gjeld

For å gjøre dette konseptet mer konkret skal vi se litt nærmere på sammenligningen mellom finansiell gjeld og teknisk gjeld. Produktledere må tross alt forstå både konsepter innen bedriftsøkonomi og tekniske konsepter innen programmering!

Fordeler med finansiell gjeld: Finansiell gjeld muliggjør belåning. Å låne penger kan gi kapitalen som trengs for å investere i vekstmuligheter. Finansiell gjeld gir også umiddelbar tilgang til ressurser eller eiendeler uten at det kreves betaling på forhånd.

Ulemper med finansiell gjeld: Finansiell gjeld medfører mange ulike typer kostnader. Rentebetalinger på finansiell gjeld kan hope seg opp over tid og redusere den samlede lønnsomheten. Hvis finansiell gjeld ikke håndteres riktig, kan det dessuten føre til økonomisk ustabilitet.

Gjeld kan dessuten begrense den økonomiske fleksibiliteten og hindre oss i å følge bestemte veier i fremtiden. Og hvis vi misligholder økonomiske forpliktelser, kan det skade organisasjonens omdømme.

Fordeler med teknisk gjeld: Teknisk gjeld muliggjør raskere innledende produktutvikling, noe som hjelper oss med å overholde stramme tidsfrister eller utnytte markedsmuligheter. I likhet med finansiell belåning kan det å pådra seg teknisk gjeld redusere de innledende utviklingskostnadene.

Ulemper med teknisk gjeld: På samme måte som renter samler seg opp på finansiell gjeld, vokser den tekniske gjelden når flere funksjoner eller endringer bygges på de eksisterende snarveiene, noe som gjør fremtidig utvikling mer kompleks og kostbar. Teknisk gjeld fører dessuten ofte til kode av lavere kvalitet enn optimalt, noe som gir høyere vedlikeholdskostnader over tid.

Teknisk gjeld kan hindre et produkt i å tilpasse seg endrede markedsforhold eller ta inn nye funksjoner. Teknisk gjeld som ikke håndteres, kan føre til systemfeil, sikkerhetssårbarheter eller ytelsesproblemer, noe som påvirker produktets levedyktighet.

Hva betyr dette for oss? For både finansiell gjeld og teknisk gjeld er målet altså ikke å unngå gjeld fullstendig. I stedet er forsvarlig håndtering nøkkelen.

Selv om et visst gjeldsnivå kan være strategisk for vekst, må vi overvåke og håndtere gjelden nøye for å minimere langsiktige negative konsekvenser.

Eksempler på teknisk gjeld

Innen programvareutvikling møter utviklingsteam regelmessig på teknisk gjeld. La oss se på et par av de vanligste eksemplene.

Arvekode

Noen team kan bruke utdatert eldre kode for å få lansert en funksjon raskt. Dette kan gi umiddelbar funksjonalitet, men kan kreve omfattende refaktorering senere, særlig når nye funksjoner legges til. På samme måte som et gammelt manuskript har eldre kode blitt overlevert gjennom generasjoner av utviklere og samlet på seg historiens tyngde.

Selv om den kan ha tjent formålet sitt på en utmerket måte i sin storhetstid, har tiden en tendens til å svekke tilpasningsevnen og vedlikeholdbarheten. Driftsavbrudd og feil i produksjon dukker ofte opp når vi stoler for mye på eldre kode!

Hardkoding

Hardkoding viser til praksisen med å bygge inn spesifikke verdier eller konstanter direkte i koden i stedet for å bruke konfigurerbare innstillinger.

Selv om denne tilnærmingen kan gi raskere utvikling på kort sikt, fører den ofte til komplikasjoner på lengre sikt. Se for deg et scenario der en hardkodet verdi, for eksempel en filbane eller en tidsavbruddsgrense, må endres i en omfattende kodebase. Dette kan raskt bli en tidkrevende og feilutsatt oppgave som setter vedlikeholdbarheten og fleksibiliteten til programvaren i fare.

For å unngå denne fallgruven bør utviklere velge konfigurerbare alternativer, noe som gjør koden mer tilpasningsdyktig.

Kodeduplisering

Kodeduplisering oppstår når lignende eller identiske kodebiter forekommer flere steder i prosjektet. Til å begynne med kan det virke som en praktisk snarvei som sparer tid under utviklingen. Etter hvert som programvaren utvikler seg og kravene endres, blir det imidlertid en innviklet dans å opprettholde konsistens og gjøre oppdateringer.

Kodeduplisering øker ikke bare risikoen for å introdusere feil, men mangedobler også innsatsen som kreves for fremtidige forbedringer og feilrettinger. Jakten på gjenbrukbar kode og fjerning av overflødig kode er grunnleggende prinsipper for å motvirke dette problemet.

Manglende dokumentasjon

Dokumentasjon fungerer som den ledende tråden som lyser opp veien for nåværende og fremtidige utviklere. Fraværet av omfattende dokumentasjon kan sammenlignes med å begi seg ut på en kompleks reise uten kart. Det kan begynne med mangel på kommentarer i koden som forklarer begrunnelsen bak bestemte kodevalg, eller eskalere til manglende brukerhåndbøker og dokumentasjon av systemarkitekturen.

Selv om den innledende utviklingsfasen kan gå problemfritt, kan konsekvensene på lang sikt bli alvorlige. Feilsøking blir en kryptisk oppgave, kunnskapsoverføring mellom teammedlemmer blir utfordrende, og skalering av prosjektet ligner ofte på å navigere i en labyrint i mørket. Grundig dokumentasjon er ledestjernen som lyser opp veien videre i programvareutvikling.

Manglende automatiserte tester

Fraværet av automatiserte tester kan sammenlignes med å seile en båt uten først å kontrollere om den lekker. Automatiserte tester (inkludert enhetstester, integrasjonstester og regresjonstester) er årvåkne voktere av kodekvalitet og stabilitet.

Når de utelates, er konsekvensene kanskje ikke umiddelbart synlige. Til å begynne med kan utviklingen gå raskt, og programvaren kan virke funksjonell. Etter hvert som kodebasen utvides og utvikler seg, begynner imidlertid uforutsette problemer å dukke opp. Regresjonsfeil, der funksjoner som tidligere virket, slutter å fungere etter nye endringer, blir vanlige.

Uten automatiserte tester som sikkerhetsnett må utviklingsteamet stole på manuell testing, en tidkrevende og feilutsatt prosess. Ved å ta i bruk automatisert testing fra starten av sikrer man stø kurs i det turbulente havet av programvareutvikling.

Hvilken rolle spiller teknisk gjeld i smidig utvikling?

Ah, smidig utvikling! Scrum-metodene og prinsippene fra manifestet for smidig utvikling omfavner endring og hastighet. Men hvor passer teknisk gjeld inn? Teknisk gjeld blir tross alt ikke omtalt spesifikt i grunnlagsdokumentene for smidig utvikling.

Her er en analogi fra Star Wars: Millennium Falcon ble kontinuerlig vedlikeholdt av Han Solo og Chewbacca for å holde seg i toppform til oppdragene deres. På samme måte håndterer et smidig produktteam teknisk gjeld for å opprettholde programvarekvaliteten og legge til rette for heroiske eventyr for kundene sine! 

Slik bruker og håndterer du teknisk gjeld

I smidige team er det en forståelse av at man noen ganger pådrar seg teknisk gjeld for å møte forretningsbehov raskt. Husk at det å pådra seg slik gjeld ikke alltid er negativt. Martin Fowler, en meningsdanner innen smidig programvareutvikling, påpeker at det handler om avveininger. Man kan godta noe gjeld tidlig i programvareproduktets livssyklus for å validere et konsept eller nå markedet raskere.

Nøkkelen er å håndtere den tekniske gjelden. Teknisk gjeld bør dokumenteres i backloggen, prioriteres og håndteres i fremtidige sprinter. For at dette skal skje, må produktledere støtte seg på god prosjektstyring, og de må ha en god forståelse av hvor mye teknisk gjeld som er pådratt så langt.

Når er teknisk gjeld et problem?

Når interessenter er uvitende om teknisk gjeld, eller når utviklingsprosessen i stor grad baserer seg på omveier, er det da alarmklokkene bør begynne å ringe. Hvorfor?

1. Den er usynlig: Uten måledata eller regelmessige kodegjennomganger kan skjulte sårbarheter oppstå.
2. Den påvirker brukeropplevelsen: Hvis underliggende problemer begynner å påvirke funksjonaliteten, er det ikke bare et utviklerproblem, men også et forretningsproblem.
3. Den hindrer nye funksjoner: Programmerere som sitter fast i dårlig kode, er mindre produktive, og kreativiteten avtar.
4. Den står ikke på veikartet: Teamene bør være oppmerksomme på teknisk gjeld og ha en strategi for den. Ikke nøl med å benytte eksterne webinarer og ressurser for å utarbeide en handlingsplan.

Slik måler du teknisk gjeld

Ved å bruke verktøy som DevOps-praksis og automatisering kan team følge med på kodebasen og holde oversikt over den tekniske gjelden som har hopet seg opp så langt. Nedenfor har jeg samlet tolv ulike måter du kan spore teknisk gjeld på.

Du trenger ikke å bruke alle! Se heller på denne listen som et utgangspunkt. Velg én eller to metoder å implementere i løpet av den neste måneden eller så, og bygg deretter gradvis opp teamets modenhet når det gjelder å spore og løse teknisk gjeld.

1) Statisk kodeanalyse: Verktøy som SonarQube, ESLint eller FindBugs kan automatisk analysere kode for ulike problemer, for eksempel kodekompleksitet, kodelukt og potensielle feil. De gir kvantitative måledata for kodekvalitet og teknisk gjeld basert på forhåndsdefinerte regler og terskelverdier.

2) Kodedekning: Vi kan vurdere hvor stor del av kodebasen som dekkes av automatiserte tester, ved å måle kodedekningen med verktøy som JaCoCo eller Istanbul. Lavkode-dekning kan indikere mangel på testing og potensiell teknisk gjeld.

3) Fagfellevurdering av kode: Fagfellevurdering av kode gjør det mulig for utviklere å identifisere og diskutere potensielle tilfeller av teknisk gjeld. Og to hoder er bedre enn ett – det er en god måte å unngå dårlige kodemønstre på! Team kan bruke sjekklister eller retningslinjer for å vurdere kodekvaliteten og dokumentere identifiserte problemer. Antallet og alvorlighetsgraden til problemene som oppdages i gjennomgangene, kan fungere som et kvalitativt mål på teknisk gjeld.

4) Manuelle kodeinspeksjoner: Utviklere og team kan gjennomføre manuelle kodeinspeksjoner eller kodegjennomganger for å identifisere områder i kodebasen som kan ha nytte av refaktorering. Denne prosessen innebærer ofte at erfarne utviklere gjennomgår kode og dokumenterer problemer, ettersom de vanligvis har best forståelse av teknisk designgjeld. 

5) Etterslep for teknisk gjeld: Å vedlikeholde et produktetterslep eller en liste over identifiserte tilfeller av teknisk gjeld er vanlig praksis. Hvert element i etterslepet bør inneholde en beskrivelse, en konsekvensvurdering og en prioritering. Størrelsen og prioriteten til elementene i etterslepet gir et kvalitativt mål på teknisk gjeld.

6) Sporing av feil og problemer: Analyse av prosessen for feiltriage kan avdekke hyppigheten og alvorlighetsgraden til problemer knyttet til teknisk gjeld. Et høyt antall feilrapporter eller hyppige gjentakelser av de samme problemene kan indikere underliggende teknisk gjeld.

7) Estimering og brukerhistoriepoeng: Når utviklingsteam planlegger nytt arbeid eller brukerhistorier, kan de anslå innsatsen som kreves for å håndtere tilfeller av teknisk gjeld. Denne innsatsestimeringen, ofte i form av brukerhistoriepoeng i smidige metoder, kvantifiserer arbeidet som kreves for å løse teknisk gjeld.

8) Måledata for kodekompleksitet: Måledata som syklomatisk kompleksitet, antall kodelinjer og kodeendringer kan gi innsikt i kodebasens kompleksitet og vedlikeholdbarhet. Høyere kompleksitet og omfattende endringer i bestemte kodeområder kan indikere teknisk gjeld.

9) Tilbakemeldinger fra brukere: Tilbakemeldinger fra brukere og forespørsler til brukerstøtten kan indirekte fremheve teknisk gjeld. Hyppige brukerklager på systemets ytelse, pålitelighet eller uventede atferd kan signalisere underliggende problemer som må håndteres.

10) Måledata for automatisert testing: Overvåking av måledata knyttet til automatisert testing, for eksempel testkjøringstid, andel mislykkede tester og ustabile tester, kan bidra til å vurdere tilstanden til testinfrastrukturen og identifisere områder som påvirkes av teknisk gjeld.

11) Undersøkelser og intervjuer: Undersøkelser og intervjuer med utviklingsteam kan gi kvalitativ innsikt i det opplevde nivået av teknisk gjeld og dens innvirkning på produktivitet og kodekvalitet. I tillegg kan innhenting av tilbakemeldinger fra interessenter bidra til å avdekke hvor omarbeiding kan være nødvendig.

12) Kvadranten for teknisk gjeld: Et spesielt nyttig verktøy er kvadranten for teknisk gjeld, introdusert av Martin Fowler. Den kategoriserer årsakene til teknisk gjeld etter bevisste kontra utilsiktede og hensynsløse kontra fornuftige valg, og hjelper team med å forstå avveininger.

Utover disse tolv måtene å måle teknisk gjeld på, ikke nøl med å bruke produktstyringsverktøy for å hjelpe med å administrere teamets sporing av og løsning på teknisk gjeld!

Nedbetaling av teknisk gjeld

Vi har snakket mye om å pådra seg teknisk gjeld, men vi har ennå ikke tatt for oss hvordan den skal betales ned. Som produktledere er det vårt ansvar å veilede teamene våre når de skal avgjøre når gjelden skal betales ned, og når det er riktig å pådra seg mer teknisk gjeld.

Vi betaler ned teknisk gjeld når utviklere oppdaterer kodebasen for å håndtere tidligere identifiserte poster med teknisk gjeld. Dette kan innebære å redesigne funksjonalitet slik at den blir mer effektiv, implementere automatiserte tester eller utarbeide grundig dokumentasjon av koden.

En av de beste måtene å betale den ned på er å sette av tid i hver sprint til å styrke kodebasen og betale ned gjelden. Tenk på dette som månedlige boliglånsbetalinger – jo raskere vi kan betale ned boliglånet, desto mindre renter må vi betale totalt!

En god tommelfingerregel er 80/20-regelen. Det vil si at man bruker omtrent 80 % av tiden i hver sprint på å bygge nye funksjoner, og 20 % av tiden på å prioritere tekniske investeringer og forbedringer.

Når du planlegger å betale ned teknisk gjeld, bør du vurdere å innarbeide den i produktveikartet ditt.

Avsluttende tanker om teknisk gjeld

For å oppsummere: Håndtering av teknisk gjeld er ikke bare utviklernes oppgave. Produktledere, smidige team og interessenter fra virksomheten spiller alle en rolle.

Det endelige målet? Å levere et programvareprodukt av høy kvalitet som oppfyller virksomhetens mål uten å pådra seg uholdbar gjeld.

Så enten du dykker ned i det dype havet av programvareutvikling eller bare prøver å forstå hvorfor utviklingsteamet ditt stadig snakker om refaktorering, er det å forstå og håndtere teknisk gjeld kompasset du trenger.

Og enten du er tidlig i produktkarrieren din, eller allerede er en erfaren veteran innen produktledelse, vil du nesten alltid ha nytte av å fordype forståelsen din av teknisk terminologi.

Jeg håper du vil unngå å gjøre den samme feilen som jeg gjorde tidlig i karrieren – ikke stol utelukkende på kontekstuelle ledetråder for å gjette deg frem til ukjente tekniske konsepter!

Ta deg i stedet tid til å undersøke, se i eksterne veiledninger som disse, og tilbring tid sammen med utviklerne dine for å friske opp verdifull kunnskap.

Hvis du vil ha mer innsikt og flere veiledninger om produktledelse, må du ikke glemme å abonnere på nyhetsbrevet vårt!