Teknisk skuld-inventering: Metrik, prioritering och 90-dagarsplan

Teknisk skuld ar ett av de mest missforstadda begreppen i branschen. Manga anvander det som ett skallsord for kod de inte gillar, men den ursprungliga liknelsen handlar om nagot mer nyanserat. Precis som ekonomisk skuld kan teknisk skuld vara helt rationell. Man tar en genvag nu for att hinna i tid, och betalar ranta i form av langsammare utveckling tills man betalar av den. Problemet ar inte skulden i sig, utan nar den ar omedveten och far vaxa okontrollerat. Har gar jag igenom hur jag tanker kring nar det faktiskt ar dags att betala av.

Vad teknisk skuld faktiskt ar

All kod man inte ar nojd med ar inte teknisk skuld. Skuld ar specifikt nar en tidigare genvag aktivt bromsar er nu. Det kan vara en hopknad losning som gor varje ny funktion langsammare att bygga, ett bibliotek sa gammalt att det inte langre far sakerhetsuppdateringar, eller en arkitektur som inte langre passar det produkten har blivit. Det gemensamma ar att den kostar er nagot lopande.

Kod som ar ful men fungerar, sallan andras och inte star i vagen for nagot ar daremot inte skuld vard att oroa sig for. Att stada den ger sallan nagot tillbaka. Den distinktionen ar viktig, for utan den hamnar man latt i att vilja skriva om allt, vilket nastan alltid ar fel.

Sa identifierar jag den skuld som gor ont

Nar jag granskar en kodbas letar jag inte efter det fula, utan efter det som kostar. Jag pratar med teamet om var det gor ont. Det finns nastan alltid nagra omraden alla bavar for att rora, dar enkla andringar tar oforklarligt lang tid eller dar buggar dyker upp gang pa gang.

• De omraden teamet undviker eller pratar om med en suck ar nastan alltid riktig skuld.
• Aterkommande buggar i samma del av systemet pekar pa nagot underliggande.
• Beroenden som inte langre far uppdateringar ar en risk som vaxer tyst over tid.

Det fina med att utga fran var det gor ont, snarare an fran en kanslomassig bedomning av koden, ar att man da prioriterar det som faktiskt paverkar arbetet och inte det som bara stor estetiskt.

Mat skulden sa att den gar att folja

For att en inventering ska bli mer an en kansla brukar jag satta nagra enkla matvarden pa skulden. Hur ofta aterkommer buggar i ett visst omrade, hur lang tid tar en typisk andring dar, och hur manga av beroendena ar omoderna eller utan sakerhetsuppdateringar. Det behover inte vara avancerat, poangen ar att kunna folja om skulden vaxer eller minskar over tid.

Med ett par sadana siffror pa plats blir det ocksa mojligt att se om avbetalningen faktiskt ger nagot. Om tiden for en andring i ett omrade sjunker efter en insats vet man att det var ratt prioritering. Utan matning blir det i stallet en evig diskussion om kanslor, dar den som later mest overtygande far ratt snarare an den som har data.

Prioritera som om det vore en lista risker

Nar skulden ar kartlagd kan man inte atgarda allt, sa man maste prioritera. Jag brukar vaga tva saker mot varandra: hur mycket den bromsar oss nu, och hur stor risken ar att den orsakar ett allvarligt problem. Nagot som bade bromsar dagligt arbete och utgor en sakerhetsrisk hamnar overst. Nagot som ar fult men ofarligt och stilla hamnar langst ner, kanske aldrig.

Den har vagningen gor ocksa att man slipper falla i fallan att atgarda det som ar roligast eller enklast i stallet for det som ger mest. En oberoende granskning hjalper ofta har, eftersom den som sitter mitt i koden latt blir hemmablind for var de storsta problemen egentligen finns.

Sa far du med dig verksamheten

Den svaraste delen ar sallan teknisk, utan att fa beslutsfattare att forsta varfor tid ska laggas pa nagot som inte ger en ny synlig funktion. Mitt rad ar att aldrig prata om teknisk skuld i tekniska termer infor verksamheten. Prata i stallet om konsekvenser: att nya funktioner tar langre tid att bygga, att risken for driftstopp okar, eller att det blir svarare att rekrytera nar koden ar otacksam att jobba i.

Liknelsen med ekonomisk skuld brukar landa bra. Alla forstar att man inte kan lana for evigt utan att betala ranta. Nar man kan visa att en viss del av systemet aktivt kostar i form av forsenade leveranser blir det ett affarsbeslut snarare an en teknisk onskan, och da ar det mycket lattare att fa gehor.

En 90-dagarsplan i stallet for ett stort omtag

Stora omskrivningsprojekt dar man pausar all ny utveckling for att stada misslyckas ofta. De drar over tid, verksamheten tapper talamodet och man star kvar med ett halvklart bygge. Jag foredrar att lagga upp arbetet som en plan over nittio dagar dar man betalar av skuld lite i taget, ofta i samband med att man anda ar inne och andrar i ett omrade. Da forbattras koden gradvis dar det faktiskt jobbas, och man slipper det stora riskfyllda omtaget.

Det handlar i grunden om att gora avbetalning till en vana snarare an en kris. En tydlig plan med fa men prioriterade poster per manad ger ocksa nagot konkret att folja upp mot, vilket haller bade teamet och ledningen lugna. Konkreta exempel pa hur sadant arbete kan laggas upp finns i var casebook.

Gor skulden synlig for hela teamet

En av de mest underskattade atgarderna ar helt enkelt att skriva ner skulden nagonstans dar alla kan se den. Sa lange den bara finns som en diffus kansla av att vissa delar ar jobbiga blir den aldrig prioriterad. Nar den i stallet ar en lista med konkreta poster, dar var och en beskriver vad den kostar och vilken risk den utgor, blir den mojlig att vaga mot annat arbete.

Jag brukar ocksa uppmuntra teamet att notera ny skuld i samma stund den tas, med en kort rad om varfor genvagen var ratt da. Det later trivialt, men det gor enorm skillnad. Da blir skulden ett medvetet val man kan omprova senare i stallet for nagot som smyger sig pa. Och nar nasta person, eller ni sjalva om ett halvar, undrar varfor en sak ser ut som den gor, finns svaret nedskrivet i stallet for borttappat.

Relaterat

• Web Performance Audit: 15 åtgärder som ger 90+ Lighthouse-poäng
• Database query-optimering: 12 mönster som eliminerar N+1-problem
• API-svarstid under 100 ms: Caching-strategier med Redis och CDN

Vill du ta det vidare?

Om du misstanker att teknisk skuld bromsar ert arbete men inte vet var den storsta finns kan vi ta ett forutsattningslost samtal. Las garna mer om hur jag jobbar med optimering eller titta i var casebook for konkreta exempel.