Ohälsosamma personberoenden orsakar flaskhalsar och sänker leveranstakten hos utvecklingsteam, de får leveranser att misslyckas, företag att gå i konkurs, och de leder till utbrändhet bland personalen. Trots detta är det otroligt vanligt att företag och leveranser sätter sig i beroendeställning till nyckelpersonal.

Systemutveckling ett kunskapsyrke

För att förtydliga varför personberoenden är ett sånt problem just i IT-branschen så börjar jag med att skriva lite om systemutveckling.

System existerar för att, på ett automatiserat sätt, lösa problem av olika slag. Att bygga system är ett utforskande arbete där utvecklare, tillsammans med intressenter, försöker hitta de bästa lösningarna på problemen utifrån en rad kriterier som till exempel kostnad, förvaltningsbarhet, användarvänlighet, automatiseringsgrad och time-to-market.

Den bästa lösningen är nästan aldrig känd i förväg utan måste tas fram genom ett samarbete mellan domänexperter och utvecklingsexperter. Detta arbete kräver ofta att teamet provtrycker idéer genom att bygga något litet, “känna” på det, och sedan anpassa det efter de lärdomar som upptäcks (så kallat iterativt eller “agilt” arbete). Systemutveckling är alltså ett kunskapsyrke där man genom experiment, analys, tankekraft och diskussion samlar på sig kunskap som man sedan använder för att lösa problem.

Personberoenden är farliga på grund av det faktum att systemutveckling handlar om kunskap och förståelse: försvinner personen så försvinner förståelsen. Det kan vara extremt svårt att bygga upp den förståelsen igen när det inte finns någon som kan förklara hur saker hänger ihop och varför vissa saker gjorts på vissa sätt.

Risk versus Reward

En vanlig orsak till att personberoenden uppstår är ett fokus på kortsiktiga vinster framför långsiktig hållbarhet. Vinsterna kan vara ekonomiska men ibland även tidsbesparande eller känslomässiga (typ “jag pratar hellre med den här personen än den här personen”):

• Det är “mer effektivt” att låta den som bäst kan en viss kodbas/system/domän/osv utföra allt arbete där, istället för att låta någon annan göra det (som över tid kunde lära sig att bli lika duktig).
• Det är “lättare” att låta dialog med ett leveransteam gå via den i teamet som bäst förstår verksamheten (t.ex. en produktägare eller “lead developer”). Det blir färre “dumma frågor” och personen i fråga kan, tillsammans med verksamheten, snabbare hitta en gemensam förståelse. Att resten av teamet lämnas “in the dark” ses inte som ett problem om man betraktar dem som “utförare” istället för “tänkare”.
• Det är “billigare” att lägga mer ansvar på ett team istället för att anställa fler (läs på om kognitiv belastning: att ge teamet mer ansvar än de mäktar med leder lätt till att teammedlemmarna delar upp ansvarsområdena, och kunskapen om dem, mellan sig).

De kortsiktiga vinsterna går inte att bortse från: man kan spara både tid och pengar genom att strunta i personberoenden och fortsätta på samma spår, istället för att stanna upp och jobba med kompetensspridning. Men är det värt risken? Ni som sitter i beslutsfattande position behöver fundera över den frågan. Hur länge dröjer det innan nyckelpersonerna blir flaskhalsar som bromsar upp, istället för att effektivisera, genom att andra tvingas vänta på dem? Vad skulle hända om en av dem plötsligt försvann? Klarar ni av att ett system slutar fungera under en längre tid när ingen vet hur man lagar det? Och hur stor är risken att någon av dessa saker inträffar?

Vad är er bussfaktor?

Bussfaktorn är ett (skämtsamt) sätt att mäta personberoenden. Den definieras som det minsta antalet personer som plötsligt kan försvinna (bli påkörda av bussen, träffade av blixten, osv.) innan en leverans stannar upp på grund av kompetensbrist. Det lägsta (och sämsta) värdet på skalan är en bussfaktor av 1, som innebär att det finns en person som teamet/leveransen/företaget inte klarar sig utan, förmodligen någon som sitter på kunskap som ingen annan har. Skulle den personen försvinna gör den resulterande kompetensbristen att leveransen stannar upp eller misslyckas.

Vad är er bussfaktor? Under covid-pandemin såg jag flera leveranser där bussfaktorn var 1. Oftast var det någon person i ett team, exempelvis en arkitekt eller lead developer, som satt på domänkunskap som ingen annan hade. Istället för att dela med sig av kunskapen så hade denna person gjort det till sin uppgift att dirigera de andra teammedlemmarna i vad de skulle göra. De teammedlemmarna slutade, i sin tur, att tänka efter och gjorde istället bara som de blev tillsagda, något som ytterliggare ökade beroendet till “dirigenten”. Detta skedde alltså MITT I EN PANDEMI. Det kunde räcka med att en nyckelperson blev hostad på i mataffären så kunde en hel leverans, ibland värd miljoner, gå i stöpet. När man tar ett steg tillbaka och beskriver det på det här sättet så håller de flesta med om att det inte är särskilt smart att riskera en hel leverans (eller hela företaget) på något som så lätt kan hända.

Att vara en nyckelperson

Att vara en nyckelperson kan kännas roligt. Du bidrar till din arbetsgivares framtid, får ta stort ansvar, och känner dig behövd. Du har bra belägg till löneförhandlingar och kanske till och med kan starta eget för att fortsätta din anställning som konsult (med ännu bättre betalt).

Det finns dock baksidor: nyckelpersoner blir ofta flaskhalsar. Så mycket information/frågor/beslut måste gå via dem att de inte hinner med. De bromsar upp utvecklingen och pushas samtidigt till att arbeta övertid för att hinna utföra sina arbetsuppgifter. Kombinera känslan av otillräcklighet med vetskapen om att allt vilar på deras axlar och vi har ett recept till utbrändhet för några av de viktigaste personerna på företaget. Om inte det så har vi ett recept till tidspressade och ogenomtänkta lösningar.

Nyrekrytering och konsulter för att fylla kompetensluckor

Kan vi inte fylla kompetensluckorna med rekrytering och konsulter? Svar: nej. De tekniska luckorna kan fyllas genom att rekryta och/eller ta in konsulter med samma tekniska erfarenhet, men eftersom ert företag och era system oftast är någorlunda unika så är de domänmässiga och luckorna svåra att snabbt täppa igen, likaså den historiska kunskapen om varför saker är byggda som de är. När nyckelkompetensen väl försvunnit så sitter ni illa till. Det är säkrare att proaktivt arbeta bort personberoenden och försöka bibehålla en nöjd personal.

Synliga och osynliga aspekter av ett system

Som kund ser man oftast bara ytan av det man beställer: gränssnitt och prestanda. Ser systemet fult ut eller är segt så är det något man som kund direkt upptäcker och kan påpeka.

Andra aspekter, som till exempel kodkvalitet, säkerhet och arkitektur, är mer abstrakta. Hos flera av dem syns inte bristerna för användaren förrän långt senare, när de får påverkan på systemets förvaltningskostnad. De kan visa sig i akuta problem, som att ett system plötsligt blir extremt långsamt efter att det samlat på sig en viss datamängd. Eller mer långtgående problem, som att utvecklingen går allt långsammare och nya buggar introduceras allt oftare. Många beställare känner nog igen sig i symptomen, men jag tror inte att alla förstår de bakomliggande orsakerna.

Min kollega Erik har beskrivit det så här:

Att bygga något som fungerar är enkelt. Utmaningen ligger i att bygga något som håller över tid.

Orsaker till problem

Som beställare förväntar man sig att de saker man beställt levereras med kvalitet. Ett team som agerar oprofessionellt kan dock pressas till att tumma på de osynliga aspekterna, något som över tid kan få katastrofala följder. Orsakerna kan vara flera, en beställare som pressar teamet att leverera i ett ohållbart tempo eller kanske en konsultchef som vill maximera vinsten (på kundens bekostnad). I min erfarenhet är det skrämmande mycket vanligare än vad man vill tro att se kodbaser och lösningar där team har struntat i den långsiktiga förvaltningsbarheten. Vi har ett flertal gånger fått ta över system där andra konsultfirmor kastats ut.

Så i grund och botten så är det alltså utvecklare som inte tagit ansvar för sitt jobb som är orsaken. Om det sen beror på att de inte kunnat göra sitt jobb för att de inte haft tillåtelse, struntat i det, eller helt enkelt inte haft kompetens, låter jag vara osagt. Det skiljer sig förmodligen från fall till fall men ofta tror jag att den verkliga boven är en kombination av press (att leverera funktionalitet eller fixa buggar), bristande externa kontroller, samt ett team som inte sätter stopp.

Det blir lätt för pressade utvecklingsteam att tumma på det som inte syns när ingen ställer dem till svars. Out of sight, out of mind. Att sedan kalla utvecklingen för en misslyckad leverans blir direkt felaktigt, det borde kallas en vanskött leverans.

Hur kan man undvika problemen?

För det första så är det viktigt att inse att det finns osynliga aspekter av ett system och att det är viktigt att man arbetar proaktivt med dem. Försök inte tvinga ut mer funktionalitet innan teamet byggt klart det de redan håller på med, och anställ ett professionellt team som tar ansvar över förvaltingsbarhet.

Jag tror även det är bra att man som beställare har något sätt att kontrollera att arbetet utförs ordentligt. I flera andra branscher använder man sig av besiktningar eller revisioner, och jag tror IT-branschen kan använda sig av något liknande. En myndighet, till exempel, skulle kunna ta in en tredje part med uppdrag att kontinuerligt utvärdera kvaliteten hos det som levereras från utvecklingsteamet. För konsultbolag borde det vara kontraktuellt tvunget att hålla en viss kvalitetsnivå: dålig kvalitet - inget betalt.

Det kan dock vara svårt att helt och hållet förlita sig på att en tredjeparts-revisor ska kunna lösa problemet. Kod kan skrivas på ett nästan oändligt antal sätt och olika utvecklare har olika preferenser. Det blir alltså svårt att göra en objektiv bedömning. Det gäller även att ha koll på att tredjepartsrevisorn inte är jävig, alltså att denne inte har något att vinna på att utvecklingsteamet lyckas/misslyckas. Istället (eller som extra stöd) föreslår jag att man använder sig av verktyg som SonarQube, Qodana, GitHub CodeQL, och liknande, som kan göra kodanalyser på ett automatiserat sätt. Dessa verktyg producerar rapporter som gör det möjligt att mäta kodkvaliteten mer objektivt.

Det finns även verktyg som automatiskt kan göra säkerhetsanalyser och meddela teamet om sårbarheter upptäcks. Trivy och Dependabot är exempel på sådana verktyg.

Att dessa verktyg kan köras automatiserat innebär ytterliggare en fördel: kontinuerlig uppföljning. Detta är viktigt då det innebär att teamet kan upplysas om problem tidigt. Ju snabbare problemen upptäcks, desto lättare (och i förlängningen billigare) blir det att lösa dem. Risken är annars att det finns ny kod som bygger vidare ovanpå den gamla problematiska koden, något som gör det svårare och mer riskfyllt att få in rättningar. Som medskick till detta vill jag också påpeka att om man väljer att använda en revisor istället för ett automatiserat verktyg så bör revisorn vara delaktig i leveransen så att denne kontinuerligt kan lämna feedback till teamet. Att ta in en revisor i efterhand är inget jag rekommenderar då det i princip redan kan vara försent för att göra de förändringar som krävs.

Några skräckexempel

Som avslutning så listar jag här några exempel på saker jag stött på:

• Företag där hela utvecklingspersonalen säger upp sig. Trötta på att varje dag behöva vada igenom den illaluktande kodbasen så hittar utvecklarna roligare och mer givande jobb på annat håll.
• Oanvändbara system. System som, hur mycket pengar och utvecklingstid man än slänger på dem, aldrig riktigt lyckas göra det de ska (här kan man fråga sig om utvecklingstiden spenderas på bästa sätt, kanske skulle man tjäna på att jobba med städning ett tag istället för att bara släcka bränder).
• Systemintegrationer där data ofta försvinner eller skrivs över med gammalt data. Detta kan ske när utvecklingen bara försöker få saker att funka och inte tar hänsyn till saker som meddelandeordning, idempotens, back pressure, persistens och race conditions (det finns en del att tänka på när data ska hållas i synk).
• Förändringar som borde varit enkla blir jättekomplexa på grund av utdaterade systemberoenden, krypteringsstandarder, eller liknande (som när TLS1.0/1.1 försvann i mars 2021, äldre system kunde behöva stora uppdateringar för att fortsätta fungera).

Fler, riktigt läskiga, exempel finns bland annat på Agila kontrakt:s Wall of Shame