Vad kostar teknisk skuld i praktiken?

Teknisk skuld står aldrig som en rad på fakturan – men den betalas varje månad. Den syns som funktioner som tar tre veckor i stället för en, buggar som återkommer och offerter som blir dyrare för varje år. Här är hur du sätter siffror på skulden, så att den går att prioritera som vilken kostnad som helst.

Vad teknisk skuld är – på beslutsfattarspråk

Teknisk skuld är summan av genvägar i kod och arkitektur: lösningar som var snabba att bygga då, men som gör varje kommande ändring långsammare nu. Liknelsen med ett lån är träffande. Genvägen är lånebeloppet, och räntan är den extra tid teamet betalar varje gång de arbetar i den delen av systemet. Precis som med lån är problemet sällan skulden i sig – utan att ingen håller koll på räntan.

Så mycket kostar den: 20–40 procent av utvecklingstiden

En vanlig tumregel i branschen är att 20–40 procent av utvecklingstiden går åt till att hantera teknisk skuld i stället för att bygga nytt. Räkna om det till kronor för ditt eget team:

Siffrorna är spann och varierar med kodbasens ålder och skick – men även den nedre kanten motsvarar en heltidsutvecklare som året runt gör ingenting annat än att betala ränta.

Så syns skulden i offerter och fakturor

Skulden är osynlig i bokföringen men fullt synlig i mönstren, om du vet var du ska titta:

• Långsammare leverans. Ändringar som “borde vara enkla” tar veckor. Ledtiden för likartade uppgifter växer år för år.
• Fler buggar. En växande andel av fakturerad tid går till rättningar och akuta utryckningar i stället för ny funktionalitet.
• Högre estimat. Leverantörer som räknar på en snårig kodbas lägger riskpåslag – du betalar för osäkerheten, inte bara för arbetet.
• Personberoende. Bara en eller två personer vågar röra vissa delar av systemet. Deras kalender blir din flaskhals.

Räkneexempel: när är refaktorering lönsam?

Anta att en typ av funktion ni bygger ofta – säg nya integrationsflöden – tar tre veckor i dagens kodbas, och att en refaktorering för 300 000 kr skulle få ner det till två veckor. En utvecklarvecka hos byrå kostar grovt 40 000–55 000 kr.

Bygger ni tio sådana funktioner under året sparar refaktoreringen tio utvecklarveckor, alltså 400 000–550 000 kr. Investeringen är återbetald inom året, och därefter är besparingen ren vinst – plus att varje funktion når användarna en vecka tidigare. Samma kalkyl kan vändas: byggs bara två sådana funktioner per år är refaktoreringen inte motiverad ännu. Det är så skuld ska prioriteras – post för post, mot faktisk användning. Gör kalkylen per skuldpost, inte för “skulden” som helhet; det är skillnaden mellan ett beslutsunderlag och en allmän suck.

Gör skulden synlig och styrbar

Skulden försvinner inte av att ignoreras, men den behöver inte heller “betalas av” i ett stort stopp-projekt. Tre vanor räcker långt:

1. Lista skulden. Be teamet ranka de tio dyraste skuldposterna med uppskattad ränta. Nu är skulden ett beslutsunderlag, inte en känsla.
2. Avsätt en fast andel. Ett vanligt riktmärke är 10–20 procent av varje sprint till skuldbetalning, i första hand i de delar av koden som ändras oftast.
3. Mät ledtid. Följ hur lång tid likartade ändringar tar över året. Sjunker ledtiden ger refaktoreringen effekt; stiger den växer skulden snabbare än ni betalar av.

Vi på Weapp arbetar dagligen i både nya och ärvda kodbaser, och mönstret är tydligt: de team som budgeterar för skulden levererar snabbare över tid än de som skjuter den framför sig. Vill du ha en second opinion på vad skulden kostar i ert system? Hör av dig.