Vad kostar teknisk skuld? Så räknar du hem en refaktorering

”Vi har mycket teknisk skuld” är ett påstående utan belopp och utan tidshorisont. Det låter som en fråga om smak, och då blir det behandlat som en. Vill du få tid att betala av skulden hjälper det att beskriva den i något verksamheten redan mäter: tid, risk och pengar.

Teknisk skuld är inte samma sak som dålig kod

Ward Cunningham myntade begreppet för att beskriva en medveten avvägning: du tar en genväg nu för att komma ut och lära dig något, och betalar ränta tills du går tillbaka och gör om det ordentligt. All skuld är inte tagen medvetet. En del uppstår för att kraven ändrades, eller för att den som byggde inte visste bättre då. Men lånebilden håller ändå: det som kostar är räntan, inte att lånet finns.

Skillnaden spelar roll, för det är räntan du ska räkna på. Ful kod i ett område du inte rör kostar lite, så länge den inte ligger i vägen för en säkerhetsuppdatering eller är det enda en person förstår. Ful kod i det område där ändringarna kommer tätt kostar vid varje ändring.

Fyra sorters skuld, med olika ränta

• Kodskuld. Duplicering, oklara gränser, funktioner som gör flera saker på en gång. Räntan betalas när någon ändrar i området och måste förstå mer än ändringen kräver.
• Testskuld. Beteende som saknar tester måste kontrolleras för hand. Räntan betalas i de releaser som berör det beteendet, som tid för att testa och som risk för det som inte testades.
• Beroendeskuld. Ramverk och bibliotek som ligger flera större versioner efter. Räntan är låg i vardagen, men ett gammalt beroende kan stoppa dig från annat: nya versioner av andra bibliotek, en ny körtid, en säkerhetsfix som bara finns för senare versioner. Då måste flera uppgraderingar göras samtidigt.
• Kunskapsskuld. En person förstår systemet. Det kostar redan i dag, i form av att den personen blir flaskhals för frågor och granskningar, och det kostar mer när personen är sjuk, ledig eller har slutat.

Beroendeskulden skiljer sig från de andra genom att räntan inte kommer jämnt. Den ser billig ut tills den dag en säkerhetsfix kräver flera uppgraderingar i rad.

Sätt en prislapp: mät ledtid, inte kodrader

Fyra mätetal att börja med

DORA-mätetalen är en rimlig startpunkt. De är oberoende av teknikval och kommer ur versionshanteringen, CI-servern och incidentloggen, om du har dem. Fyra av dem räcker här:

1. Ledtid för en ändring. Från commit till produktion.
2. Driftsättningsfrekvens. Hur ofta du levererar till produktion.
3. Andel misslyckade ändringar. Hur stor del av driftsättningarna som leder till ett fel som måste rättas eller rullas tillbaka.
4. Återställningstid efter en misslyckad driftsättning. Hur lång tid det tar att få tjänsten att fungera igen efter en driftsättning som gick fel.

Skuld kan synas i alla fyra, men den är inte den enda förklaringen. Ledtiden växer när en ändring sprider sig till fler filer än den borde. Frekvensen faller när varje release kräver en manuell testrunda. Felandelen stiger när beteende saknar tester. Återhämtningen drar ut på tiden när den som rullar tillbaka inte vet vad ändringen rörde. Titta på siffrorna tillsammans med utvecklarna innan du drar slutsatsen.

Översätt till kronor

Ta ett konkret område och jämför hur mycket arbetstid liknande ändringar tar där, mot ett område i samma system som är lätt att jobba i. Extra arbetstimmar per ändring, gånger antalet ändringar per år i området, gånger en timkostnad, är en grov uppskattning av räntan. Räkna väntetiden för sig: en ändring som ligger tre dagar i kö för granskning kostar något, men inte tre dagars utvecklingstid. Siffran är grov, för ingen ändring är exakt lik en annan. Men den går att diskutera på ett sätt som ”koden är rörig” inte gör.

Lägg sedan till risksidan: vad kostar en timmes driftstopp för verksamheten, och hur stor del av återställningstiden beror på att området är svårt att förstå?

Be inte om tid för ”bättre kod”. Be om kortare ledtid för prisändringar, och visa vad den är i dag.

Så prioriterar du vad som ska betalas av

Ställ två saker mot varandra: hur ofta ett område ändras, och hur ont det gör att ändra det. Områden som ändras ofta och gör ont är där avbetalningen ger mest tillbaka. Områden som gör ont men sällan ändras kan vänta, om de inte bär på ett säkerhetsproblem eller blockerar en uppgradering.

Ändringsfrekvensen behöver du inte gissa, den ligger i versionshistoriken. En sammanställning av vilka filer som ändrats mest det senaste året visar var arbetet sker. Jämför listan med det utvecklarna klagar på. Där de överlappar har du både belägg och en plats att börja.

Regeln vi själva jobbar efter

Betala av skulden i samma leverans som funktionen, i det område funktionen ändå berör. Ett separat refaktoreringsprojekt utan funktionellt innehåll är svårt att försvara när något brådskar, och det säger inget om avbetalningen hjälpte förrän långt senare. Gör du det tillsammans med en funktion får du en signal redan vid nästa ändring i området.

Undantaget är beroendeskulden. Ge den egen, planerad tid, för den följer inte din backlog utan andras releasecykler.

Behöver du ett underlag inför ett sådant beslut? Så jobbar vi. Ska avbetalningen göras i ett system som inte får stanna kan strangler fig vara ett sätt att göra det i steg.