Rubriken för första Puke-inlägget var ”Men fulhacka då!”. Jag tänkte att jag skulle utveckla resonemanget lite om fulhack.

Det första man ska vara medveten om är att ett fulhack är vad Ward Cunningham m. fl. kallar för en ”designskuld” (se ”Technical Debt”, ”Design Debt” mm.). En friktion i utvecklingsorganisationen är den om desigskulder/fulhack. Ett av skälen till att utvecklare skyr fulhack (även då hacken är ekonomiskt motiverade) är att de har dåliga erfarenheter av att bli dubbelbestraffade för dem.

Scenariot är ofta detta: I slutet på en releasecykel vill produktägaren pressa in funktionalitet som är viktig för kunden, men som inte är trivial att införa sådan som kodbasen ser ut nu. Den önskade funktionaliteten har ingen lösning som harmonierar mer arkitekturen.

Utvecklarna måste då antingen försvara sin kodbas, vilket gör produktägaren harmsen (och ofta på goda grunder: funktionen kan vara avgörande för kunden, och kunden kan vara avgörande för företaget); eller ge efter i form av en lösning som på ett eller annat sätt förstör kodbasen, arkitekturellt sett.

En degenererad kodbas är trögare att arbeta med (måste påminna om Emelies ”clean code” här), varför utvecklarnas produktivitet sjunker, vilket produktägaren bestraffar utvecklarna för. Alltså: först tvinga utvecklarna att knyta samman sina skosnören, och sedan skälla på dem när de inte springer lika fort som tidigare.

Det är ju uppenbart så att produktägaren i dessa fall inte tar ansvar för sina beslut och sin produkt. Inget i processen tvingar den heller att ta ansvar: likt en bortskämd unge kan produktägaren ena stunden önska och kräva, och sedan gnälla över konsekvenserna. Allt medan produkten degenererar.

Lösningen är att hantera denna designskuld på samma sätt som man hanterar andra skulder: man synliggör dem, betalar kostnaden för dem, och ser dem som möjliggörare som dock har ett pris i form av en kalkylerad risk.

När man tänker på det är det inte så underligt. Hela produkten är faktiskt redan resultatet av ett sådant risktagande, en sådan lånerisk. Kostnaderna för utvecklingen av en produkt tas ju innan produkten börjar generera intäkter. Verksamheten är alltså redan inställd på den typen av överväganden.

Felet som utvecklarna gör är att de inte synliggör designskulden när den uppstår. Verksamheten har inga problem att hantera lånerisker, men de måste först och främst veta att de har dem.

Hur synliggör man då designskulder? Det enkla sättet är att se dem som tidsskulder. I klarhet: när man inför fulhacket gör man samtidigt ett estimat för vad det kostar att göra förändringen ogjord och kanske vad det kostar att göra det bra. Detta läggs som ett ärende i ärendehanteringssystemet (produktens backlog). Samtidigt markerar man i koden med ”Kludge” i en kommentar, och kanske ett namn eller annan identifikation så att det blir en länk mellan ärendehantering och kodbas.

Nu är fulhacket med på agendan. I och med att man lägger den i produktens backlog blir den ett ansvar för produktägaren att inför varje cykel ta ställning till och prioritera upp eller ner. Hur skulden i praktiken sedan kommer att hanteras beror helt på hur produktägaren vill göra. Men ägaren kommer aldrig mer att kunna ignorera eller låta bli att hantera den.

Eller skylla den på någon annan än sig själv.