h1

Teknisk Skuld är mera än bara ful-kod

måndag, 10 maj, 2010

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.

4 kommentarer

  1. Jättebra inlägg med bra uppstrukturering av teknisk skuld! Det är viktigt att tänka på teknisk skuld och se när den uppstår, för det är så lätt att den smyger sig in när det blir ont om tid trots att man egentligen vet att man inte sparar någon tid i längden.


  2. […] är teknisk skuld (technical debt) ett viktigt begrepp relaterat till ett systems kvalitet. Agilekonsulten Jimmy Janlén definierar teknisk skuld som ”ryggsäcken av ogjort, slarvigt eller dåligt utfört arbete, en ryggsäck vars tyngd […]


  3. Av egen erfarenhet så har jag insett att det agila tankesättet alltför ofta existerar på projektlednings- och utvecklingsplanen men att det är väldigt svårt att få produktägare, kravställare och högre ansvariga att förstå vad det går ut på.
    Tidspress är helt ok om förekomsten av denna är införstådd i sprintplaneringsstadierna och prioriteringar kan göras utefter detta. A och O kan tyckas, men redan här misslyckas väldigt många projekt.

    Det farligaste är dock att det i planeringsskedena alltför ofta saknas tydliga eller ens kompletta kravställningar, vilket ofelbart leder till att påbörjade (eller avslutade) tasks plötsligt måste designas om eller dumpas. Som utvecklare vet vi att detta ofta har en dominoeffekt och för att hålla tidplanen försöker man minska denna effekt genom fullösningar.

    En bra utvecklare måste därför tyvärr lyfta informationsspridningen på sina axlar (för det är de facto så att det oftast är utvecklarna som har den största insynen i hur det fungerar) och ta ansvar för att göra beslutsfattare och kravställare väldigt medvetna om att deras sätt att bidra till utvecklingsprojekt kan få extremt kostbara konsekvenser om de inte hänger med i verkligheten.

    Sedan finns det ju självklart dåliga utvecklare som inte KAN producera något, men det är ett helt annat och långt mer lättlöst problem – foten! =)


  4. […] Ibland lämnas t.o.m. buggar kvar i systemen därför att många användare och programvara förväntar sig att de finns… I projekt som startar under stor tidspress så görs ofta misstag som lätt försvårar framtida förbättringar, en s.k. ”Teknisk skuld” (Scrum-begrepp) byggs då upp. Se ex https://jimmyjanlen.com/2010/05/10/teknisk-skuld-ar-mera-an-bara-ful-kod/ […]



Kommentera

Fyll i dina uppgifter nedan eller klicka på en ikon för att logga in:

WordPress.com Logo

Du kommenterar med ditt WordPress.com-konto. Logga ut / Ändra )

Twitter-bild

Du kommenterar med ditt Twitter-konto. Logga ut / Ändra )

Facebook-foto

Du kommenterar med ditt Facebook-konto. Logga ut / Ändra )

Google+ photo

Du kommenterar med ditt Google+-konto. Logga ut / Ändra )

Ansluter till %s

%d bloggare gillar detta: