Vad är teknisk skuld?
Teknisk skuld är summan av genvägar i kod och arkitektur som gör varje framtida ändring långsammare och dyrare. Precis som ett lån har den ränta: ju längre den ligger, desto mer kostar den. Viss skuld är medveten och rationell för att hinna till marknaden, medan smygande skuld är farligast. Symtomen märks som allt trögare utveckling.
Teknisk skuld är ett av de mest träffande begreppen i systemutveckling, just för att liknelsen håller hela vägen. Det förklarar varför ett system som en gång var snabbt att bygga vidare på plötsligt blir segt och dyrt. Här är vad det betyder, och hur du känner igen det.
Definitionen
Teknisk skuld är summan av alla genvägar och kompromisser i ett systems kod och arkitektur som gör varje framtida ändring långsammare och dyrare. Varje gång någon väljer den snabba lösningen i stället för den hållbara – för att spara tid nu – läggs en liten bit skuld till högen.
Ingen enskild genväg är farlig. Problemet är att de ackumuleras. Ett system fullt av små kompromisser blir till slut ett system där ingenting går att röra utan att något annat riskerar att gå sönder. Skulden syns inte i gränssnittet och märks inte av användarna direkt – den bor i koden, osynlig tills den börjar bromsa allt arbete.
Den bästa förklaringen till hur det fungerar ligger i själva namnet.
Låneliknelsen: amortering och ränta
Teknisk skuld beter sig precis som ett ekonomiskt lån, och det är därför liknelsen är så användbar.
En genväg ger dig fart nu, på samma sätt som ett lån ger dig pengar nu. Men den kommer med ränta. Räntan är allt det extra arbete som varje framtida ändring kräver på grund av genvägen – varje gång någon måste jobba runt den snabba lösningen betalar man lite ränta på skulden.
Betalar man aldrig av växer skulden, och räntan med den. Till slut kan så mycket av utvecklingstiden gå åt till att bara hantera gammal skuld att det knappt blir kraft över till nytt. Att amortera – löpande avsätta tid för att städa och förbättra koden – håller skulden i schack. Ett system helt utan teknisk skuld är orealistiskt; målet är att inte låta den skena.
Medveten mot smygande skuld
En viktig nyans är att inte all teknisk skuld är av ondo. Den kan delas i två sorter, och de bör hanteras helt olika.
| Sort | Karaktär |
|---|---|
| Medveten skuld | Ett aktivt val för att hinna till marknaden – känd och planerad |
| Smygande skuld | Byggs upp oavsiktligt och osynligt, utan beslut – farligast |
Medveten skuld är ofta helt rationell. Att ta en genväg för att hinna lansera i tid och vinna en marknad kan vara ett klokt affärsbeslut – så länge man vet att skulden finns och tänker betala av den när trycket lättar. Det är ett lån man tar med öppna ögon.
Smygande skuld är den farliga. Den byggs upp oavsiktligt, en slarvig lösning i taget, utan att någon fattat ett beslut eller ens noterat den. Eftersom ingen ser den planeras den heller aldrig bort, och den kan hinna växa sig stor innan den upptäcks. Det är skillnaden mellan ett lån man tagit medvetet och en skuld man vaknar upp och inser att man dragit på sig.
Symtomen du märker
Du behöver inte läsa kod för att ana att skulden växer. Den avslöjar sig i vardagen, framför allt i tempot.
Det tydligaste tecknet är att enkla ändringar plötsligt tar orimligt lång tid. Något som borde vara en dagsuppgift drar ut på veckor, och utvecklarna säger att de måste bygga om en del innan de kan lägga till det du bad om. Ett annat symtom är att buggar återkommer – fel man trott var lösta dyker upp igen, ofta för att den underliggande strukturen är för skör.
När “kan ni inte bara ändra det här snabbt?” allt oftare möts av tvekan i stället för ett ja, är teknisk skuld ofta den underliggande orsaken. Det är inte att teamet blivit sämre – det är att systemet blivit tyngre att arbeta i.
Att känna igen dessa symtom tidigt gör att man kan amortera i tid, innan skulden lamslår utvecklingen. Vill ni ha ett neutralt omdöme om hur mycket skuld som byggts upp i ert system och vad som är värt att åtgärda, tittar vi på Weapp gärna på koden tillsammans innan den blir en flaskhals.
Vanliga frågor
Vad är teknisk skuld, enkelt förklarat?
Det är alla genvägar och kompromisser i ett systems kod och arkitektur som gör det svårare att ändra i framtiden. Varje gång man väljer den snabba lösningen framför den hållbara byggs lite skuld upp. Den syns inte utåt, men den gör att systemet blir allt trögare och dyrare att vidareutveckla över tid.
Varför liknas det vid ett lån?
För att mekaniken är densamma. En genväg ger dig fart nu, precis som ett lån ger pengar nu, men den måste betalas tillbaka med ränta. Räntan är allt extraarbete varje framtida ändring kräver på grund av genvägen. Betalar man aldrig av växer skulden, tills en stor del av arbetet går åt till att bara hantera den.
Är all teknisk skuld dålig?
Nej. Viss skuld är medveten och klok – att ta en genväg för att hinna lansera i tid och vinna en marknad kan vara helt rätt, så länge man vet att skulden finns och planerar att betala av den. Det farliga är den smygande skulden som byggs upp oavsiktligt och osynligt, utan att någon fattat ett beslut om den.
Hur märker jag som beställare att vi har teknisk skuld?
Du ser det i tempot. Enkla ändringar som borde ta dagar tar plötsligt veckor. Buggar man trodde var lösta återkommer. Utvecklarna blir alltmer försiktiga och säger att de måste bygga om innan de kan lägga till nytt. När 'kan ni bara ändra det här snabbt' allt oftare möts av tveksamhet, är skulden ofta orsaken.
Går teknisk skuld att bli av med?
Den går att betala av, men sällan att eliminera helt. Genom att löpande avsätta tid för att förbättra och städa i koden – amortera skulden – hålls den på en hanterbar nivå. Poängen är inte ett skuldfritt system, vilket är orealistiskt, utan att inte låta skulden växa okontrollerat tills den lamslår utvecklingen.