Artiklar för Expert Network

Under åren 2016–2019 samarbetade IDG med ett antal utvalda experter inom IT. De skrev artiklar om "spaningar", och artiklarna publicerades i tidningar som CIO Sweden, Computer Sweden och TechWorld.

Under 2024 bytte IDG publicerings­system, och de flesta artiklarna plockades då bort från deras webbplatser. De artiklar som Mejsla bidrog med till Expert Network publiceras nu här på Mejslas webbplats med tillåtelse från IDG.

När kan man försvara teknisk skuld?

I de allra flesta fall bör vi sträva efter att hålla den tekniska skulden på en mycket låg nivå. Nu har det dock blivit vanligare med applikationer där det kanske kan vara försvarbart att acceptera en något högre nivå av skuld, skriver it-rådgivaren Karl Dickson.

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 kort­siktigt, men i gengäld minskar ränte­kostnaderna. 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 sisyfos­arbete 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 webb­applikationer där de underliggande platt­formarna ä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 projekt­ledare 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 under­liggande platt­formar 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.

Denna artikel publicerades ursprungligen hos IDG i juni 2019.
Författare: Karl Dickson