Du har sikkert hørt det: utviklere som snakker om teknisk gjeld, mens resten av prosjektet bare vil kjøre på for å få ting gjort raskere.
Teknisk gjeld er mer enn et buzzord for utviklere. Det er et problem som kan lamme hele virksomheten hvis det ignoreres.
Teknisk gjeld er ikke bare et begrep for IT-utvikling. Det er et universelt problem: de små snarveiene vi tar i dag som kan skape store problemer i morgen. Kanskje har du opplevd det selv? Du kaster deg over et prosjekt, tar noen raske valg for å komme i gang, og plutselig, et halvt år senere, sitter du fast i din egen labyrint.
Denne artikkelen er skrevet for å forklare teknisk gjeld på en enkel måte, slik at også de som ikke jobber med utvikling forstår alvoret. For teknisk gjeld handler ikke bare om kode. Når den får vokse, er det sjelden et isolert utviklerproblem. Ofte er det et ledelsesproblem.
Og det er kanskje ikke så rart. Ifølge Conway’s Law vil systemer speile kommunikasjonsstrukturene i organisasjonen som lager dem. Med andre ord: når vi jobber i siloer, bygger vi også siloer – i arkitektur, i brukeropplevelse og i kode.
Hva er teknisk gjeld?
Kort sagt handler teknisk gjeld om kortvarige løsninger som fører til langsiktige problemer. Akkurat som med finansiell gjeld kan det virke uskyldig i starten. Du låner tid og ressurser ved å velge en rask løsning for å komme videre, men på et tidspunkt må du betale tilbake – med renter.
Teknisk gjeld er i praksis umulig å unngå helt. Den oppstår når vi tar valg som prioriterer fart fremfor struktur, og noen ganger er det en bevisst og nødvendig prioritering. Men det endrer ikke det grunnleggende prinsippet: før eller siden må gjelden betales.
Vanlige årsaker til teknisk gjeld kan være:
- Tidsfrister som tvinger frem raske løsninger («Dette fikser vi senere!»)
- Kode som bygges uten tanke på fremtidig skalerbarhet
- Dokumentasjon og struktur som nedprioriteres
- Systemer som lappes sammen i stedet for å bygges riktig fra starten
Se gjerne på artikkelen om hva produktutvikling handler om hvis du vil dykke dypere.
Teknisk gjeld i praksis – fra blogg til business
La meg ta et eksempel fra min egen blogg. Da jeg startet, handlet alt om å få ut innhold, jo mer, jo bedre. Kategorier? Struktur? Det tar vi senere! Nå, et år senere, med over 300 artikler, sitter jeg i en jungel av innhold uten en tydelig vei gjennom det. Hver gang jeg prøver å rydde opp, møter jeg min egen tekniske gjeld: dårlige kategorier, uklare tagger, for lange artikler med flere budskap, og en struktur som føles som å flytte rundt på møblene i et allerede overfylt rom.
Hadde jeg planlagt bedre fra starten, ville jeg spart meg for timevis med rydding. Dette er et personlig prosjekt som har gitt meg noen muligheter og åpnet noen dører, uten at jeg er avhengig av det. Om jeg sluttet å rydde opp, eller til og med sluttet å blogge helt, ville konsekvensene vært minimale. Det eneste som ville skjedd, er at jeg fikk mer tid til andre ting.
Jeg kjenner igjen dette fra egne utviklingsprosjekter. Jeg er jo ingen utvikler, men kan jo kode litt når jeg MÅ. Når jeg koder selv, vet jeg at det nesten alltid følger med teknisk gjeld. Ikke nødvendigvis fordi jeg tar snarveier med vilje (litt det også), men fordi jeg mangler den dype erfaringen som trengs for å bygge robust og fremtidsrettet kode. Jeg lager løsninger som fungerer her og nå, og som løser en umiddelbar utfordring, men sjelden noe som skalerer eller tåler komplekse endringer.
Det er også grunnen til at jeg trives bedre i rollen som leder eller mellomleder enn som utvikler. Jeg har et godt blikk for helhet, ser koblinger mellom fagområder og mennesker, og er flink til å stille de riktige spørsmålene. Det gjør meg bedre egnet til å koordinere utvikling enn å utføre den alene.
I større systemer, spesielt i IT-utvikling, blir teknisk gjeld en helt annen historie. Da kan konsekvensene være langt mer alvorlige, både for videre utvikling, vekst og omdømme.
Her skriver jeg om hvorfor man bør ha en blogg, og hvordan min ble til.
Min verste erfaring med teknisk gjeld
Jeg har sett teknisk gjeld på sitt aller verste. I et tidligere prosjekt jobbet vi med et internt system som var hardkodet av en tidligere ansatt. Jo dypere vi gravde, desto verre ble det. Alt var hektet sammen på måter som ingen forsto, og hver minste endring var som å dra ut en stein fra bunnen av konstruksjonen. Før eller siden ville alt rase. Det var som om han hadde bygget en pyramide opp ned, der vi visste den en dag kom til å tippe over, bare ikke når.
Da vi endelig innså hvor ille det sto til, var valget egentlig enkelt. Vi kunne fortsette å lappe på systemet, og kanskje holde det gående en stund, så lenge kundeveksten var moderat. Men vi visste at hvis veksten plutselig tok av, ville alt kollapse. Og da ville ikke bare systemet ryke, men sette hele selskapets omdømme på spill.
Vi tok den eneste ansvarlige beslutningen. Vi rev alt.
Dessverre var prisen høy. Vi mistet ett helt år forsprang i markedet, fordi vi først måtte bygge opp de interne tjenestene fra bunnen av, før vi kunne begynne på de eksterne løsningene, altså de som faktisk ga oss inntekter. Hadde vi hatt ubegrensede midler og ressurser, kunne vi kanskje ha gjort begge deler samtidig. Men virkeligheten krevde prioriteringer, og teknisk gjeld hadde allerede spist opp den fleksibiliteten vi ellers kunne hatt.
Og det er nettopp dette som er den virkelige kostnaden ved teknisk gjeld. Det handler ikke bare om tapt tid eller penger. Det handler om tapte muligheter. Tapte forsprang. Tapte drømmer.
Men teknisk gjeld finnes dessverre overalt. Og Inga Strümke, en av Norges fremste AI-eksperter sier det så bra i en podcast:
«Vi sliter med å bygge en god digital grunnmur. Og den digitale grunnmuren må liksom komme før vi kan begynne å snakke om hva vi skal bruke kunstig intelligens til. Hvis datasystemene ikke fungerer, kan du heller ikke bygge noen gode AI-systemer. Det går bare ikke. Da blir det bare lappetepper.»
Jeg anbefaler å i alle fall se to minutter fremover av podcasten jeg hørte dette i på YouTube her, der hun snakker om nettopp utfordringene med å ikke bygge riktig fra starten.
Jeg har sagt det selv, mange ganger: «Det er bare å…». Men hver gang jeg hører noe som er «bare» nå, eller tar meg selv i å si det, kjenner jeg det strammer seg litt i magen. For det er sjelden så enkelt. Og det er ofte akkurat sånn teknisk gjeld starter.
Hvordan unngå teknisk gjeld?
Teknisk gjeld kan ikke alltid unngås, men den kan håndteres og begrenses. Her er noen gode prinsipper:
- Tenk fremover: Se på løsningen du bygger i dag, og spør deg selv: Hvordan vil dette fungere om 2–5 år?
- Prioriter kvalitet over hastighet: En solid løsning nå sparer deg for store problemer senere.
- Refaktorer jevnlig: Små vedlikeholdsjobber underveis er bedre enn en massiv opprydding om tre år.
- Dokumenter alt: Det kan føles unødvendig i øyeblikket, men det er som å skrive en bruksanvisning til ditt fremtidige jeg.
- Vær ærlig om når det er best å starte på nytt: Noen ganger er teknisk gjeld blitt så omfattende at det faktisk lønner seg å rive ned og bygge opp på nytt.
Metoder som faktisk fungerer
Å være bevisst på teknisk gjeld er én ting, men det er hvordan du håndterer det i praksis som betyr noe. Her er noen grep som virkelig hjelper:
- Skriv ren kode: Koden skal ikke bare fungere, den skal også være lett å lese, forstå og videreutvikle. Tenk på det som å rydde etter deg selv på kjøkkenet før du lager neste måltid.
- Refaktorer som en vane: Små forbedringer kontinuerlig gjør at du slipper å møte veggen senere. Ikke vent til rotet blir uoverkommelig.
- Bruk testdrevet utvikling (TDD): Skriv testen først, lag løsningen etterpå. Det føles kanskje tungvint i starten, men sparer deg for utallige feil og hodebry.
- Definer hva «ferdig» betyr: «Ferdig» handler ikke bare om at noe virker – det skal også være ryddig, dokumentert og klart for videreutvikling.
- Hold tekniske gjennomganger: Ta jevnlige stoppunkter hvor du ser på arkitektur, struktur og vedlikeholdbarhet, før små feil vokser seg store.
- Gjør teknisk gjeld synlig: I agile prosesser (som Scrum) kan du aktivt registrere teknisk gjeld som egne oppgaver i backloggen. Da blir den synlig for både utviklere og ledelse, og kan håndteres på linje med nye funksjoner.
Og kanskje viktigst av alt: Husk at perfeksjon heller ikke er målet. Litt teknisk gjeld kan være en bevisst prioritering. Men det krever at du vet hva du gjør og tar kontrollen selv.
En siste påminnelse
Unngå også å overoptimalisere for tidlig. Et altfor komplekst system kan bli en gjeldsbombe i seg selv, spesielt hvis behovene aldri blir så store som du trodde. Det handler om å løse dagens behov på en måte som holder dørene åpne for fremtiden, uten å utvikle den på forskudd.
I agile prosesser er dette en viktig del av tankegangen. Man bygger akkurat det man trenger nå, og forbedrer det etter hvert. Teknisk gjeld blir dermed en naturlig følgesvenn, men forskjellen ligger i bevisstheten. Når du ser gjelden, erkjenner den og håndterer den i tide, kan du vokse sunt uten å bli kvalt av fortiden.
Og det er nettopp her skillet mellom kompetanse og erfaring blir tydelig. Å skrive god kode er én ting, men å vite hvor mye som skal til for å holde mulighetene åpne uten å bygge unødvendig, krever erfaring. Det er en dømmekraft som først modnes med tid, og som verken en dyktig utvikler uten fartstid, eller en AI-hjelper, kan forutsi alene. For selv om AI er et kraftfullt verktøy, krever det erfaring å stille de riktige spørsmålene. Og visdom til å vite når svaret trenger en menneskelig vurdering.
Oppsummering
Teknisk gjeld er som et kredittkort med skyhøy rente. Jo lenger du ignorerer det, desto dyrere blir det.
Men teknisk gjeld finnes ikke bare i IT. Se for deg et veiprosjekt der man velger å bygge veien en halv meter smalere for å spare penger. Det fungerer fint, helt til trafikken øker og veien må utvides. Plutselig koster det mye mer enn om man hadde gjort det riktig fra starten.
Det samme skjer i byggeprosjekter, der man velger billige materialer for å holde budsjettet nede, bare for å oppdage at hele taket må skiftes etter ti år. Et klassisk eksempel på vedlikeholdsetterslep. Eller i bedrifter, som kutter hjørner i kundeservice for å spare tid, og senere må bruke enorme ressurser på å rette opp omdømmetap.
Les gjerne nest siste avsnitt i artikkelen min med en introduksjon til kunstig intelligens, som er veldig relevant for dette.
I helsevesenet kalles det behandlingsetterslep, når operasjoner utsettes til pasienten blir enda dårligere, noe som gjør behandlingen både mer omfattende og dyrere. I utdanning snakker man om kunnskapsgap eller kompetansegjeld, når elever eller ansatte ikke får nødvendig opplæring, og man senere må bruke tid og ressurser på å hente seg inn igjen.
Uansett bransje handler det om det samme: Snarveier i dag blir omveier i morgen.
Så neste gang du vurderer en rask løsning, spør deg selv: Er dette noe jeg må betale for senere? Hvis svaret er ja, kan det være verdt å ta den ekstra tiden nå, slik at du slipper å bruke ett år, og masse penger, på å rydde opp i rotet senere.
