Teknisk skuld: vad det är och hur du minskar den

I början av en applikations liv går det snabbt att lägga till en ny funktion. Ett par år senare tar en lika stor ändring tre gånger så lång tid, och efter varje release måste något rättas som ingen har rört. Utvecklaren säger ”det där är svårt att ändra” och ingen kan riktigt förklara varför.

Det här har ett namn: teknisk skuld. Det är summan av alla genvägar som en gång togs för att bli klar snabbare och som aldrig rättades till efteråt. Precis som en ekonomisk skuld växer den med ränta: ju längre den står kvar, desto dyrare blir varje nästa ändring.

Var teknisk skuld kommer ifrån

Teknisk skuld är inte nödvändigtvis ett tecken på dåligt arbete. Ofta har den varit ett medvetet och rimligt beslut: produkten behövde ut på marknaden före konkurrenten, deadline var fast eller det var ännu inte klart vad användarna egentligen behövde. Problemet uppstår när genvägen blir den permanenta lösningen.

De vanligaste källorna:

• Ouppdaterade komponenter. Ramverket, biblioteken och serverprogramvaran ligger flera versioner efter. Varje överhoppad uppdatering gör nästa större och mer riskabel.
• Kopierad kod. Samma logik finns på fem ställen, lite olika varje gång. En rättning på ett ställe når inte de andra.
• Tester som saknas. Ingen kan före en release kontrollera om ändringen förstörde något någon annanstans.
• Odokumenterade beslut. Varför är den här tabellen uppbyggd så här? Varför anropar den här funktionen tre andra? Svaret försvann med utvecklaren.
• Tillfälliga lösningar. ”Vi gör så här nu och fixar det sedan.” Sedan kom aldrig.

Så känner du igen teknisk skuld

Du behöver inte läsa koden själv för att märka skulden. De affärsmässiga symptomen är ofta tydligare:

• Uppskattningarna drar ut: ”det tar två veckor” blir sex.
• Felen kommer snabbare än de rättas.
• En ny utvecklare behöver månader innan hen vågar ändra något.
• Det finns en del av systemet som ingen vill röra.
• Säkerhetsuppdateringar installeras inte, eftersom ”det kan förstöra något”.

Stämmer tre eller fler av dessa är skulden sannolikt redan större än budgeten för ny utveckling.

Så mäter du skulden

Teknisk skuld går inte att räkna ut exakt i euro, men den går att kartlägga. Vid en granskning går jag igenom:

1. Komponenternas ålder. Vilka ramverk och bibliotek saknar support och vilka har kända säkerhetshål.
2. Riskpunkterna. De delar där ändringar orsakar flest fel och som ändras oftast. Där lönar sig en rättning mest.
3. Beroendena. Vad anropar vad, och kräver ett byte av en del att tio andra ändras.
4. Läget för tester och dokumentation. Hur stor del av systemet som går att kontrollera utan att klicka igenom för hand.

Resultatet är en lista där varje problem har en risk, en effekt och en uppskattad arbetsinsats. Utifrån den kan du bestämma vad som görs direkt och vad som kan vänta. Hur granskningen går till i detalj har jag skrivit om i artikeln mjukvarugranskning.

Så minskar du skulden utan att stoppa verksamheten

Det vanligaste misstaget är att bestämma sig för att ”skriva om alltihop”. Ett fungerande system innehåller affärsregler som samlats under flera år och som ingen specifikation beskriver. Vid en omskrivning måste alla upptäckas på nytt, och under tiden måste det gamla systemet fortfarande fungera. När en omskrivning trots allt lönar sig tar jag upp i artikeln gammal mjukvara: modernisera eller bygga om.

Ett stegvis arbetssätt är klokare:

• Börja med säkerheten. Komponenter utan support och kända säkerhetshål först av allt.
• Rätta där du ändå arbetar. Om en ny funktion berör en viss modul, städa upp den modulen samtidigt. Då minskar skulden där den faktiskt kostar.
• Lägg till tester före ändringen. Först tester runt den riskabla delen, sedan ändringen. Då syns det direkt om något gick sönder.
• Byt ut del för del. En gammal modul ersätts med en ny tills alla delar är utbytta. Efter varje steg har du en fungerande applikation.
• Dokumentera löpande. Skriv ner varje beslut, så att nästa person inte behöver börja om från början.

Hur mycket tid ska läggas på att minska skulden

En bra tumregel är att reservera en del av varje utvecklingscykel för uppstädning i stället för att lämna den till ett projekt ”någon gång senare”. Är skulden redan så stor att nya funktioner inte kan läggas till inom rimlig tid behövs en separat moderniseringsetapp. Då får man under en period göra mer uppstädning än ny utveckling.

Sammanfattning

Teknisk skuld är normalt, men den får inte växa osynligt. Kartlägg den, börja med de delar som har störst risk och minska den steg för steg, så att verksamheten inte behöver vänta.

Har din applikation nått den punkt där varje ändring är dyr och riskabel, se hur jag arbetar med modernisering och vidareutveckling av mjukvara, eller beskriv din situation. Jag säger ärligt om applikationen är värd att städa upp eller om det är klokare att bygga något nytt.