Inom långdistanslöpning händer det emellanåt att en löpare går in i väggen. Det kan bero på att man har tömt tanken och fått slut på energi. Men en vanligare orsak är att man har samlat på sig för mycket mjölksyra så att musklerna inte längre kan tillgodogöra sig energin i blodet. Syreskulden har överskridit löparens smärtgräns. Följden blir att löparen måste gå ner i mycket långsamt tempo eller stanna helt, och ägna resten av dagen åt att återhämta sig. Loppet är kört.
Inom mjukvaruindustrin finns ett liknande fenomen. Symptomen är att produktiviteten i ett projekt minskar drastiskt. Nya defekter upptäcks i snabbare takt än de åtgärdas. Moralen hos utvecklingsteamet sjunker i takt med att irritationen hos användarna ökar. Snart börjar de duktigaste och mest erfarna teammedlemmarna lämna projektet och ersättas av inte så duktiga och inte så erfarna utvecklare. Vad som har hänt är att den tekniska skulden har överskridit projektets smärtgräns. Följden blir att nyutvecklingen måste gå ner i mycket långsamt tempo, eller upphöra helt. Snart nog så upphör även finansieringen och projektet måste avbrytas. Uppdraget har misslyckats.
Erfarna löpare vet att tricket att undvika att gå in i väggen, utöver en stadig frukost, är att hålla sig under sitt tröskeltempo, det vill säga det tempo där musklerna förbrukar lika mycket syre som kroppen kan förse dem med. Håller man sig under sin tröskelfart så ökar inte syreskulden i musklerna. En vältränad löpare kan hålla igång på det sättet under flera timmar.
Men ett långlopp kräver mer av en tävlingslöpare än att kunna hålla ett jämt och lagom högt tempo. Man måste kunna hantera långa eller branta backar. Ibland måste man svara när en motståndare gör ett ryck. Eller så hamnar man efter och måste jaga ikapp klungan. Någon gång ser man själv en möjlighet att dra ifrån, kanske just i den där långa uppförsbacken. Då måste man tillåta sig att tillfälligt bygga upp en syreskuld som man sedan får betala av med ränta. Men väntar man för länge med att betala så straffar det sig, både i tid och smärta.
Långdistanslöpning är något som kräver övning. Förutom att den rent fysiska kapaciteten måste tränas upp, så tar det även tid att hitta balansen mellan fart och distans som gör att man håller lagom till mållinjen. Väldigt oerfarna löpare som ska springa sitt första lopp tenderar att rusa i början tills de överhettade, flämtande och med mjölksyrastinna och krampande muskler tvingas stanna.
Att drabbas av mjölksyra och gå in i väggen gör ont, så den oerfarne löparen lär sig snabbt att ta det lugnare. Redan vid det andra loppet tar hon sig sannolikt i mål, och snart kan hon till och med börja njuta av att pressa sin kropp att prestera på toppen av sin förmåga, utan att överskrida den. Hon rusar inte längre i starten utan springer lugnt och avslappnat från första till sista steget, kanske med en spurt den sista biten för att krama ut de sista krafterna.
Inom mjukvaruindustrin ser vi en liknande tendens. Oerfarna team rusar i början, påhejade av projektledare och produktägare med dollartecken för ögonen. Nästan-färdiga funktioner levereras i en rasande takt och läggs i hög ovanpå varandra. Produktägaren och projektledaren skrattar hela vägen till mötena med sina uppdragsgivare där de med Powerpoint-slides och välförberedda demos visar hur fantastiskt bra det går. Defekter avfärdas som barnsjukdommar man måste räkna med, eller ren otur. Finansiärerna är också glada och allt är frid och fröjd.
Tills något händer.
De där defekterna blir fler och svårare att skyla över. Efter hand som systemet börjar användas i skarpt läge så blir felen en källa till oro och problem. Allt mer resurser läggs på att få bort dem. Trots att teamet rusar vidare i samma höga tempo så levererar de färre och färre funktioner. De börjar bli defensiva och komma med invecklade förklaringar till varför det och det kravet inte kan tillgodoses och varför den och den funktionen tar längre tid än väntat att utveckla. Det är tecknen på teknisk skuld vi börjar se. Men till skillnad från syreskulden som ger en omedelbar och distinkt smärta, så ger den tekniska skulden en mer vag och obestämd smärta. Varken projektledare, produktägare eller finansiärer skrattar längre, men var gör det egentligen ont? Kanske behövs fler utvecklare? Kanske behövs bättre utvecklare? Kanske måste de motiveras mer? Eller drivas på hårdare? Kanske bör de jobba annorlunda?
I det här läget är det vanligt att utvecklare byts ut mot nya med snyggare CV’n. Inkörda processer och metoder ändras eller byts ut mot helt nya. Stressen ökar. Rädslan att göra fel ökar. Den som ändå dristar sig att lägga sin hårt pressade tid på att reda ut gamla kodhärvor som hjälpligt fungerar får ofta skulden när nya defekter blir synliga för användarna. Resten av teamet lär sig att undvika de rötangripna delarna för att istället måla över sprickorna och sleva på med ny kod ovanpå den som har börjat flagna. Tiden det tar att utveckla varje ny funktion växer sakta men säkert mot oändligheten. Projektet har inlett sin spiralbana mot de misslyckade projektens svarta hål.
Tyvärr är ovanstående scenario inte särskilt ovanligt. Desto ovanligare är att boven i dramat – den tekniska skulden, faktiskt får skulden för misslyckandet. Det finns ingen kropp som känner koden fräta i sin ådror. Det är svårt att mäta teknisk skuld och det är än svårare att leda orsakssambandet mellan den tekniska skulden och den minskade produktiviteten i bevis. Att uppleva smärtan av den tekniska skulden och sätta den i samband med den låga produktiviteten kräver både erfarenhet och lyhördhet.
De som lär sig känna igen kodsyrasmärtan först är utvecklarna i projektet. De upplever hur de får lägga allt större del av sin tid på att försöka förstå någon annan programmerares invecklade kodhärva och allt mindre tid åt att lösa nya intressanta problem åt produktägaren. Till att börja med kan det vara lätt att skylla problemen på de andra, uppenbart mindre bemedlade, projektdeltagarna som inte kan skriva vettig kod. Tills utvecklaren märker att det allt som oftast är den själv som har bidragit till den obegripliga kodhärvan. Det är nu den viktiga insikten om teknisk skuld börjar ta form.
Så det lite mer erfarna utvecklarteamet har ofta programmerare som förstår att man måste hålla ett lagom högt tempo i ett projekt om det ska vara uthålligt i längden. Och att kodsyran, det vill säga den tekniska skulden, kontinuerligt måste hållas på en kontrollerad nivå genom ständig ansning och anpassning av den befintliga kodbasen. Varianter på Scoutregeln hörs citeras: ”Checka in koden i lite bättre skick än du checkade ut den.” Tyvärr är det inte alltid att de här insikterna når projektledaren eller produktägaren, som ju befinner sig längre från själva roten till problemet. Det kan få till följd att fel teammedlemmar premieras för fel saker. Den som snabbt bygger nya funktioner men lämnar rörig kod efter sig får beröm för sin produktivitet. De som kommer efter och städar upp och kanske samtidigt springer på en mina som leder till en ny synlig defekt får förmaningar av typen: ”Laga inte det som inte är trasigt”.
Om inte utvecklarteamet är starkt nog att stå emot den här negativa feedbackloopen så kan det lätt förfalla till det mindre erfarna teamets arbetssätt: Lappa, laga och bygg på så länge det går (och lämna skeppet innan det märks att det har börjat sjunka). Men är teamet starkt nog så självorganiserar det sig till en effektiv maskin som har pli på de mindre erfarna utvecklarna som vill rusa och levererar det produktägaren behöver i den takt som är optimal, strax under teamets tröskelfart.
En del av utvecklingsteamets ansvar är således, inte bara att stå emot somliga projektledares påtryckningar att göra fel saker, utan även att utbilda projektledaren i teknisk skuld och om teamets tröskelfart. Teamet måste vara för projektet och projektledaren vad musklerna är för kroppen och hjärnan – det organ som sänder smärtsignaler genom hela organisationen när skulden börjar närma sig smärtgränsen och som belönar med endorfiner, beröm och god stämning när den får signaler uppifrån att hålla ett högt men kontrollerat tempo och hålla sin kodbas i trim.
Produktägarens ansvar blir då, snarare än att detaljreglera hur teamet ska lösa dess behov, att sätta upp snitslarna längs banan och tala om var målet ligger så att teamet vet åt vilket håll och hur långt det ska springa. Och projektledarens ansvar blir, snarare än att driva på (det gör teamet så bra själva), att serva med vätskekontroller och allt som teamet behöver längs vägen för att prestera på topp. Allt för ofta ser man dock utvecklarteam som får springa utan snitslar eller mål och utan vätskekontroller, men med tydliga krav på att göra nästa hundring så fort de bara kan, och sen nästa, och nästa. Men så enkelt är det inte att vinna ett långlopp och så enkelt är det inte heller att bygga hållbar mjukvara med kvalité.
Så, det är dags att vi i branchen börjar betrakta oss mer som långdistansare än kortdistansare. Sprintprogrammeraren får kanske spurtpriset men långdistansutvecklaren vinner i det långa loppet.
Inom mjukvaruindustrin finns ett liknande fenomen. Symptomen är att produktiviteten i ett projekt minskar drastiskt. Nya defekter upptäcks i snabbare takt än de åtgärdas. Moralen hos utvecklingsteamet sjunker i takt med att irritationen hos användarna ökar. Snart börjar de duktigaste och mest erfarna teammedlemmarna lämna projektet och ersättas av inte så duktiga och inte så erfarna utvecklare. Vad som har hänt är att den tekniska skulden har överskridit projektets smärtgräns. Följden blir att nyutvecklingen måste gå ner i mycket långsamt tempo, eller upphöra helt. Snart nog så upphör även finansieringen och projektet måste avbrytas. Uppdraget har misslyckats.
Erfarna löpare vet att tricket att undvika att gå in i väggen, utöver en stadig frukost, är att hålla sig under sitt tröskeltempo, det vill säga det tempo där musklerna förbrukar lika mycket syre som kroppen kan förse dem med. Håller man sig under sin tröskelfart så ökar inte syreskulden i musklerna. En vältränad löpare kan hålla igång på det sättet under flera timmar.
Men ett långlopp kräver mer av en tävlingslöpare än att kunna hålla ett jämt och lagom högt tempo. Man måste kunna hantera långa eller branta backar. Ibland måste man svara när en motståndare gör ett ryck. Eller så hamnar man efter och måste jaga ikapp klungan. Någon gång ser man själv en möjlighet att dra ifrån, kanske just i den där långa uppförsbacken. Då måste man tillåta sig att tillfälligt bygga upp en syreskuld som man sedan får betala av med ränta. Men väntar man för länge med att betala så straffar det sig, både i tid och smärta.
Långdistanslöpning är något som kräver övning. Förutom att den rent fysiska kapaciteten måste tränas upp, så tar det även tid att hitta balansen mellan fart och distans som gör att man håller lagom till mållinjen. Väldigt oerfarna löpare som ska springa sitt första lopp tenderar att rusa i början tills de överhettade, flämtande och med mjölksyrastinna och krampande muskler tvingas stanna.
Att drabbas av mjölksyra och gå in i väggen gör ont, så den oerfarne löparen lär sig snabbt att ta det lugnare. Redan vid det andra loppet tar hon sig sannolikt i mål, och snart kan hon till och med börja njuta av att pressa sin kropp att prestera på toppen av sin förmåga, utan att överskrida den. Hon rusar inte längre i starten utan springer lugnt och avslappnat från första till sista steget, kanske med en spurt den sista biten för att krama ut de sista krafterna.
Inom mjukvaruindustrin ser vi en liknande tendens. Oerfarna team rusar i början, påhejade av projektledare och produktägare med dollartecken för ögonen. Nästan-färdiga funktioner levereras i en rasande takt och läggs i hög ovanpå varandra. Produktägaren och projektledaren skrattar hela vägen till mötena med sina uppdragsgivare där de med Powerpoint-slides och välförberedda demos visar hur fantastiskt bra det går. Defekter avfärdas som barnsjukdommar man måste räkna med, eller ren otur. Finansiärerna är också glada och allt är frid och fröjd.
Tills något händer.
De där defekterna blir fler och svårare att skyla över. Efter hand som systemet börjar användas i skarpt läge så blir felen en källa till oro och problem. Allt mer resurser läggs på att få bort dem. Trots att teamet rusar vidare i samma höga tempo så levererar de färre och färre funktioner. De börjar bli defensiva och komma med invecklade förklaringar till varför det och det kravet inte kan tillgodoses och varför den och den funktionen tar längre tid än väntat att utveckla. Det är tecknen på teknisk skuld vi börjar se. Men till skillnad från syreskulden som ger en omedelbar och distinkt smärta, så ger den tekniska skulden en mer vag och obestämd smärta. Varken projektledare, produktägare eller finansiärer skrattar längre, men var gör det egentligen ont? Kanske behövs fler utvecklare? Kanske behövs bättre utvecklare? Kanske måste de motiveras mer? Eller drivas på hårdare? Kanske bör de jobba annorlunda?
I det här läget är det vanligt att utvecklare byts ut mot nya med snyggare CV’n. Inkörda processer och metoder ändras eller byts ut mot helt nya. Stressen ökar. Rädslan att göra fel ökar. Den som ändå dristar sig att lägga sin hårt pressade tid på att reda ut gamla kodhärvor som hjälpligt fungerar får ofta skulden när nya defekter blir synliga för användarna. Resten av teamet lär sig att undvika de rötangripna delarna för att istället måla över sprickorna och sleva på med ny kod ovanpå den som har börjat flagna. Tiden det tar att utveckla varje ny funktion växer sakta men säkert mot oändligheten. Projektet har inlett sin spiralbana mot de misslyckade projektens svarta hål.
Tyvärr är ovanstående scenario inte särskilt ovanligt. Desto ovanligare är att boven i dramat – den tekniska skulden, faktiskt får skulden för misslyckandet. Det finns ingen kropp som känner koden fräta i sin ådror. Det är svårt att mäta teknisk skuld och det är än svårare att leda orsakssambandet mellan den tekniska skulden och den minskade produktiviteten i bevis. Att uppleva smärtan av den tekniska skulden och sätta den i samband med den låga produktiviteten kräver både erfarenhet och lyhördhet.
De som lär sig känna igen kodsyrasmärtan först är utvecklarna i projektet. De upplever hur de får lägga allt större del av sin tid på att försöka förstå någon annan programmerares invecklade kodhärva och allt mindre tid åt att lösa nya intressanta problem åt produktägaren. Till att börja med kan det vara lätt att skylla problemen på de andra, uppenbart mindre bemedlade, projektdeltagarna som inte kan skriva vettig kod. Tills utvecklaren märker att det allt som oftast är den själv som har bidragit till den obegripliga kodhärvan. Det är nu den viktiga insikten om teknisk skuld börjar ta form.
Så det lite mer erfarna utvecklarteamet har ofta programmerare som förstår att man måste hålla ett lagom högt tempo i ett projekt om det ska vara uthålligt i längden. Och att kodsyran, det vill säga den tekniska skulden, kontinuerligt måste hållas på en kontrollerad nivå genom ständig ansning och anpassning av den befintliga kodbasen. Varianter på Scoutregeln hörs citeras: ”Checka in koden i lite bättre skick än du checkade ut den.” Tyvärr är det inte alltid att de här insikterna når projektledaren eller produktägaren, som ju befinner sig längre från själva roten till problemet. Det kan få till följd att fel teammedlemmar premieras för fel saker. Den som snabbt bygger nya funktioner men lämnar rörig kod efter sig får beröm för sin produktivitet. De som kommer efter och städar upp och kanske samtidigt springer på en mina som leder till en ny synlig defekt får förmaningar av typen: ”Laga inte det som inte är trasigt”.
Om inte utvecklarteamet är starkt nog att stå emot den här negativa feedbackloopen så kan det lätt förfalla till det mindre erfarna teamets arbetssätt: Lappa, laga och bygg på så länge det går (och lämna skeppet innan det märks att det har börjat sjunka). Men är teamet starkt nog så självorganiserar det sig till en effektiv maskin som har pli på de mindre erfarna utvecklarna som vill rusa och levererar det produktägaren behöver i den takt som är optimal, strax under teamets tröskelfart.
En del av utvecklingsteamets ansvar är således, inte bara att stå emot somliga projektledares påtryckningar att göra fel saker, utan även att utbilda projektledaren i teknisk skuld och om teamets tröskelfart. Teamet måste vara för projektet och projektledaren vad musklerna är för kroppen och hjärnan – det organ som sänder smärtsignaler genom hela organisationen när skulden börjar närma sig smärtgränsen och som belönar med endorfiner, beröm och god stämning när den får signaler uppifrån att hålla ett högt men kontrollerat tempo och hålla sin kodbas i trim.
Produktägarens ansvar blir då, snarare än att detaljreglera hur teamet ska lösa dess behov, att sätta upp snitslarna längs banan och tala om var målet ligger så att teamet vet åt vilket håll och hur långt det ska springa. Och projektledarens ansvar blir, snarare än att driva på (det gör teamet så bra själva), att serva med vätskekontroller och allt som teamet behöver längs vägen för att prestera på topp. Allt för ofta ser man dock utvecklarteam som får springa utan snitslar eller mål och utan vätskekontroller, men med tydliga krav på att göra nästa hundring så fort de bara kan, och sen nästa, och nästa. Men så enkelt är det inte att vinna ett långlopp och så enkelt är det inte heller att bygga hållbar mjukvara med kvalité.
Så, det är dags att vi i branchen börjar betrakta oss mer som långdistansare än kortdistansare. Sprintprogrammeraren får kanske spurtpriset men långdistansutvecklaren vinner i det långa loppet.
1 kommentarer
Jon
05 May 2015 21:04
Väl skrivet. Man kan inte sprinta ett maraton brukar jag hävda :)
Kommentera