När kan man försvara teknisk skuld?

Teknisk skuld

Begreppet teknisk skuld är en utmärkt analogi för system med bristande kvalitet. Att slarva med kvalitet motsvarar att ta ett lån med ränta i form av högre kostnader för fortsatt utveckling och underhåll. Att höja kvaliteten och förbättra sina system motsvarar amorteringar; de kostar kortsiktigt, men i gengäld minskar räntekostnaderna. Ränta på ränta motsvaras av att brister leder till snabbfixar som leder till ökad komplexitet och nya brister vilket gör att den tekniska skulden får en tendens att växa exponentiellt.

Det här talar förstås för att man ska kämpa för att hålla nere den tekniska skulden. Ytterligare ett viktigt skäl är att de allra flesta utvecklare skyr dåliga system. Är man mån om sin personal bör man verkligen låta dem slippa det sisyfosarbete som det kan vara att lappa i ett system med låg kvalitet där räntan växer snabbare än man amorterar.

Att under en kort period inför en release acceptera en viss teknisk skuld kan vara taktiskt rätt, men det bygger på att man sedan är beredd att snarast möjligt beta av på skulden. Tyvärr är det vanligt att man alltför tidigt börjar låna – bygga teknisk skuld – i tron att man på så sätt ska komma tidigare till release. För de flesta är det ointuitivt hur snabbt man förlorar i tempo när man gör avkall på teknisk kvalitet.

Kort livslängd ändrar spelplanen

Men vad är det då som har hänt som gör att jag allt oftare – om än med viss tveksamhet – ändå kan se att det är försvarbart med en något högre nivå av teknisk skuld? Jo, svaret är att utvecklingen går allt snabbare, och vi får fler och fler system, eller delsystem, som bygger på plattformar med mycket kort livslängd. Det här är extra tydligt med webbapplikationer där de underliggande plattformarna ändras och byts ut i ett rasande tempo. Om man inser att man ändå kommer att tvingas byta plattform och göra om allt från början inom ett par år så blir inte den tekniska skulden lika allvarlig. När man slänger koden blir man ju även av med både skuld och räntor!

Delikat balansgång

Det går förstås inte att hitta ett generellt svar på vilken nivå av teknisk skuld som är rätt att ha. Att som produktägare eller projektledare pressa ett team till att slarva med kvalitet är nästan alltid en dålig idé. I regel lönar det sig att ständigt jobba med att hålla nere den tekniska skulden, men det finns undantag. Om man strategiskt i en fas vill tillåta sig att bygga teknisk skuld bör strategin stämmas av med dem som är insatta i tekniken och som ska jobba med systemet. I ett större perspektiv är valet av underliggande plattformar centralt. Och givet en redan vald teknisk plattform bör man ta hänsyn till den när man bedömer hur hög teknisk skuld som är strategiskt rätt.

Läs också: 
Därför tar uppgifter ofta längre tid än du tror
Dags att riva nästa mur – ta med kraven i Devops