Jimmy Janlén "Den Scrummande Konsulten"

Medvetenheten kring Teknisk Skuld och dess betydelse för ett projekts agilitet sprider sig till snabbt. Detta är såklart en önskvärd trend, och troligen en livsavgörande insikt för vissa företag. Men om du förringar Teknisk Skuld till att enbart handla om kodens kvalitet så lurar du dig själv och risken blir stor att du kommer att ta beslut på felaktiga grunder.

Jag brukar påstå att Teknisk Skuld är den största fienden mot ett agilit projekt, dvs. förmågan att varje sprint ta sig an nya krav, lika många som förra sprinten, och känna tillit till att det man nyss levererat uppfyller DONE kriterierna och är av hög kvalitet. Ju högre Teknisk Skuld, desto dyrare att förändra och bygga vidare på koden och underhålla produkten.

Teknisk Skuld är ryggsäcken av ogjort, slarvigt eller dåligt utfört arbete, en ryggsäck vars tyngd gör att utvecklingen av en produkt går allt långsammare. Teknisk Skuld kan introduceras oavsiktligt (arkitekturen visade sig vara fel och svår att skala, den överarbetade programmeraren introducerar många buggar pga slarv), eller avsiktlig (genvägar tas och delar av arbete, såsom t.ex. dokumentation och test, skjuts upp för att hinna klart med releasen).

Oavsett orsak och härkomst så är teknisk skuld som ett kreditkort, förr eller senare måste du betala tillbaka din skuld om du vill göra nya stora inköp med kortet. Betalar du inte tillbaka utan väljer att ta ett sms-lån för att finansiera nästa utbyggnad sitter du snart fast i ränte-fällan.

.

Teknisk Skuld kan grupperas i följande kategorier:

Programmerings skuld
Dålig kod kvalitet. Slarvigt skriven. Samma kod förekommer på flera ställen. Skör kod (dvs. svår att ändra på utan att något går sönder). Obegriplig för någon annan än utvecklaren själv. Krånglig och besvärlig att bygga vidare på.

Design skuld
Dålig eller ingen design. Stel arkitektur. Avsaknad av (eller felaktigt skurna) lager. En snårskog av klasser och moduler. Det är enklare att bygga den nya funktionen som ett plåster utanpå istället för att utnyttja arkitekturen som tänkt.

Test skuld
Delar av systemet har inte testats, testats dåligt eller på fel sätt. Okänd testtäckning. Fallerar ett gammalt automatiserat test är det svårt att veta om testet är fel eller om koden gömmer en defekt.

Kunskapsskuld – Det finns isolerad och odokumenterad kunskap. Kod är svår att förstå pga av avsaknad av kommentarer. Samma fel upprepas pga att lessons learned inte sprids. Isolerad kunskap skapar resurs-flaskhalsar. Nya teammedlemmar har svårt att komma upp till ett produktivt tempo. Förvaltning står handfallen när något går galet pga avsaknad av rätt teknisk dokumentation.

.

Farliga och fördummande förenklingar

Dessvärre verkar vissa ”agila experter” enbart rikta in sig på kod-aspekten av teknisk skuld. En farlig och fördummande förenkling. Vissa försöker till och med göra pengar på detta. Bara för att programmeringsskulden är enklare att mäta (med hjälp av olika  analytiska verktyg) än de andra aspekterna betyder det inte att man får glömma bort test-, design- och kunskapsskulden, aspekter som tillsammans kan gömma betydligt högre kostnader än programmeringsskulden.

För att ta ett exempel; ”The Agile Executive” är en blogg jag följer. Den tar bland annat upp teknisk skuld från en mängd olika och spännande vinklar och har skrivit en radda mycket bra artiklar om ämnet. Grytan bubblade dock över för mig när de häromdagen annonserade ut och hyllade Cutter Consortiums nya tjänst, ”New service boils down technical debt to $$; ties it to cost and value”, i en artikel. Tjänsten fokuserar enbart kring kodens kvalitet och genom att förenkla ner detta till några mätetal extraherar Cutter sedan priset på den tekniska skulden i pengar eller man-dagar.

Här är ett annat exempel på när den tekniska skulden reduceras till kod-kvalitet:
http://www.infoq.com/news/2010/03/monetizing-technical-debt

.

Nödvändiga förenklingar?

Missförstå mig dock rätt, jag tycker det är en vacker och eftersträvansvärde tanke att kunna åskådliggöra teknisk skuld med ett konkret pris. Kanske t.o.m. nödvändig för att få förståelse och mandat från Produktägare och beställare för att adressera och förebygga tillväxten av Teknisk Skuld.

Jag anser dock att förenkla det till några enstaka kod-tekniska faktorer är dock farligt förenklande, till snudd på fördummande, och svaret blir inget annat än en delmängd av sanningen.