En definition på teknisk skuld för mjukvaruutveckling är att det är kostnaden längre fram för merarbete, som kommer sig av att utvecklare väljer genvägar. Typexemplet är en snabbfix för att åtgärda ett problem, istället för att lägga ner eftertanke på att bygga en bra lösning som eliminerar problemet.

När tillräckligt många snabbfixar har gjorts i en applikation så blir situationen till slut ohållbar och det krävs en genomgripande omarbetning av applikationen. Det är dags att betala den tekniska skulden.

En likhet mellan teknisk skuld och bostadslån är att båda medför ränta. Vad gäller teknisk skuld visar sig räntan i att det krävs mer arbete för att åtgärda ett problem ju längre man väntar med att göra det och ju fler andra problem som manifesterar sig.

Det här är inga nyheter för utvecklare eller annan it-personal som varit med ett tag. Det kan nog hävdas att teknisk skuld är den enskilt största anledningen till långsam systemutveckling, till svårigheter att förändra it-lösningar och till att underhåll för många företag står för en större del av it-budgeten än nyutveckling.

Fredik Normén
Fredik Normén, Squeed.

Agila arbetssätt ger ingen patentlösning på problemen med teknisk skuld. Tvärtom. Det finns en stor risk att arbetssätt med korta iterationer (sprintar) förvärrar situationen. Om man ska få till ny eller förändrad funktionalitet under en sprint på två veckor finns det helt enkelt inte tid att åtgärda stora, grundläggande problem. Lösningarna får lätt en karaktär av snabbfixar.

Men det finns en ”enkel” lösning på problemet:

– Man måste hitta utrymme för att eliminera teknisk skuld under utvecklingsfasen, säger Fredrik Normén, konsult på Squeed.

Iris Classon,
Iris Classon, Konstrukt.

– Numera sätter vi av tid för att jobba med teknisk skuld under sprintarna, tidigare väntade vi ibland tills det small, säger Iris Classon, utvecklare på Konstrukt.

Hon säger vidare att det händer att en hel sprint sätts av för jobb med den tekniska skulden, även om det inte händer så ofta. Ett exempel kan vara en stor refaktorisering för att databasen som används för en applikation designas om. Däremot brukar man inte avsätta en hel sprint för att ta hand om många små uppgifter.

– Regeln är att städa där man är, säger Iris Classon.

Läs ocksåTidsuppskattningar ett hinder mot lyckad systemutveckling

Vad finns det för orsaker till att en del team inte fortlöpande hanterar ärenden som kan leda till teknisk skuld?

Christian Landgren
Christian Landgren, Iteam.

– Det kan vara ett tecken på ett icke fungerande team, eller det kan vara en kund eller en produktägare som inte vill prioritera sådana uppgifter, säger Christian Landgren, vd på Iteam.

Även han framhåller vikten av att arbeta fortlöpande med problem som kan orsaka teknisk skuld. Han påpekar också att stress leder till att man samlar på sig teknisk skuld. Och det finns metoder för att undvika stress:

– Det finns ord som leder till stress. Det är till exempel bättre att använda ord som takt och rytm, i stället för hastighet eller velocity.

Ett mer konkret råd är att alltid lämna kod i bättre skick än man finner den. Det är en grundregel för att jobba löpande med teknisk skuld, för att slippa större avbrott i ett senare skede.

Läs också: Är ni agila på ditt företag? Är du säker på det?

Även Fredrik Normén pratar om grundläggande arbetssätt:

– Problemen blir ofta större med stora monoliter, det är bättre att bryta isär sådana i mindre tjänster. Det är också viktigt att undvika onödiga beroenden i koden och att följa principer som Solid, säger han.

Helt klart är att arbetsätt som används kan påverka omfattningen av teknisk skuld:

Jenny Klarenfjord
Jenny Klarenfjord, Dynabyte.

– Ju mer agilt man jobbar, desto färre problem med teknisk skuld blir det, säger Jenny Klarenfjord, konsult på Dynabyte.

Hon tipsar även om att köra demonstrationer inte bara för kunder och användare, utan även för utvecklare, arkitekter och annan teknisk personal. Det är också bra att avsätta tid för granskning av koden inom ett team. På så sätt blir det enklare att identifiera problem som kan leda till teknisk skuld.

Kontentan av alla råd är tydlig: Gör inte snabbfixar som kan orsaka problem längre fram och om det finns problem, åtgärda dem fortlöpande. Konsekvensen av det är att projekten kan ta längre tid. Men det är det värt i det långa loppet.