Tobias Fors

Efter ett alldeles för långt uppehåll tar jag åter upp skrivandet av serien Men vad kan jag göra? - tips om saker som du kan göra idag, helt utan att be om tillstånd, för att förbättra tillståndet i ditt aktuella projekt.

Varje gång jag hör någon berätta om ett stycke särskilt hemsk kod de sprungit på kommer jag att tänka på när jag hittade en klass som var 17000 rader lång. Någonstans mitt i denna kompakta massa text fanns två metoder. Den ena hette “up”, den andra “down”. Båda var ganska långa och, visade det sig, helt identiska. Eller inte helt - ett tecken skilde faktiskt. Där det stod ett plus i den ena stod det ett minus i den andra. Det tog en stunds betraktande och ett diff-program för att ställa diagnosen. Sådan är klipp-och-klistra-programmeringens logik. Den enes snabba fix blir den andres huvudbry. Denna monsterklass var representativ för hela kodbasen.

Mitt uppdrag i projektet var väldigt tydligt definierat. Jag skulle vidareutveckla en viss modul i koden. Minnet av hur det kändes när jag först såg den kod jag förväntades bygga vidare på lever kvar. Självklart var den, som man brukar säga, nästan klar och bara några små tillägg skulle göras.

Den del av koden jag fick tilldelad var inte 17000 rader lång. Tvärtom var det en ganska kort klass. En kort och kompakt klass. En tät massa av kryptiska variabler och villkorssatser. Det jag kände när jag tittade på den var fruktan. Fruktan att jag inte skulle klara den uppgift jag fått tilldelad.

Jag minns inte om jag köpte Martin Fowlers lysande bok om refactoring efter min sammanstötning med detta monster till källkod, eller om jag just hade råkat köpa den. Hur det än var så räddade den boken mig.

Fowler beskrev i sin bok hur man kunde jobba i små kontrollerade steg för att omvandla oläsbar kod till läsbar kod. Han visade hur man försiktigt men målmedvetet kunde omforma spaghettikod till små kontrollerbara bitar.

Jag skred till verket metodiskt och omsorgsfullt. Eftersom jag jobbade i Visual Basic 6 hade jag inte tillgång till några automatiska verktyg för refactoring, men Fowlers instruktioner kunde följas steg för steg. Långsamt gjorde jag koden mer hanterbar. Jag bytte obegripliga variabelnamn mot begripliga. Jag bröt ned långa metoder i kortare, och gav dem mer passande namn. Jag tog bort överflödig kod. Jag strukturerade och städade, hela tiden efter Fowlers recept som visade hur jag kunde göra ändringarna på ett tryggt sätt. För första gången kände jag mig som en riktig programmerare (språket till trots skulle vissa säga). Till slut kunde jag göra de tillägg jag blivit ombedd att göra.

Fowlers definition på refactoring var “små designförändringar som inte ändrar kodens beteende”. Idag verkar en vanligare tolkning av termen vara “blandade tekniska förändringar av större och mindre sort”. Den sortens ändringar har vi redan tillräckligt av, men den sort Fowler avsåg är det fortfarande brist på. Därför, om du vill göra en skillnad redan idag, lär dig först vad refactoring betyder. Lär dig sedan att använda tekniken i praktiken. Förmodligen har du redan upptäckt att det finns inbyggt stöd för refactoring i ditt utvecklingsverktyg, så idag är det lättare än någonsin att börja skriva kod som andra inte behöver frukta att ta över, och det - det är att göra världen till en lite bättre plats.

- - -

Övningar

1. Vilken bok skulle kunna rädda dig ur situationen du befinner dig i just nu? Beskriv din situation för en vän eller kollega du litar på och fråga om de har ett tips på en bok som skulle kunna hjälpa dig.
2. Är begreppet refactoring känt bland de du jobbar med? Fråga några kollegor om hur de definierar refactoring.

Att lova något är otäckt. Det kan visa sig att man inte kan stå vid sitt löfte. Det händer ju även den bäste, och kan leda till en obekväm situation. För mig kan rädslan för detta obekväma ibland leda till att jag anammar följande strategi: den som aldrig lovar något behöver heller aldrig bryta ett löfte.

Dessvärre spelar löften en avgörande roll i alla typer av samarbeten. Om du ska kunna basera dina planer på det arbete jag gör, måste du veta vad du kan förvänta dig från mig, och när. Löften spelar dessutom en annan viktig roll - den som skapare eller förstörare av tillit. När någon lovar mig något, och håller löftet, ökar min tillit till den personens förmåga. När någon inte levererar enligt sitt löfte, eller aldrig kan lova något till att börja med, sjunker min tillit till den personens förmåga.

Det första steget till att kunna hålla vad man lovar är därför att (trumvirvel) faktiskt våga lova något.

Så vad innebär det att lova något, och att få ett löfte? Ingen kan förutsäga framtiden, så ett löfte kan aldrig innebära en hundraprocentig garanti att något kommer att hända. En definition som leder till färre besvikelser är kanske att se på ett löfte som att den som lovar åtar sig att göra allt som står i dennes makt för att löftet ska uppfyllas.

Som löftesgivare måste jag alltså förstå vad som står i min makt. Utan insikt, mindre sannolikt att jag kommer att kunna hålla vad jag lovar. Vad som står i min makt är en funktion av mina egna förmågor och det sammanhang jag måste använda dem i.

Det andra steget till hålla vad man lovar är därför en personlig insikt i vad man har makt att lova.
Att inte kunna hålla ett löfte behöver inte alltid leda till minskad tillit. Om du upptäcker att ett löfte du gett inte längre kan hållas ska du inte suga på den sura karamellen. Analysera orsaken, berätta om vad som hänt, och gör - om det utlovade fortfarande är värt att satsa på - ett nytt löfte som har större sannolikhet att fungera. När du gör det bygger du ofta tillit minst lika effektivt som när du faktiskt lyckas leverera på ditt ursprungslöfte.

Att ha “för mycket att göra” är något som belönas i många sammanhang. Det ser helt enkelt rätt snyggt ut att ha mycket att göra, och en kort stund kan det kännas ganska bra också.

Tyvärr är “för mycket att göra” även ett utmärkt sätt att skjuta produktiviten i sank både för sig själv och för de man samarbetar med. Tråkigt nog (eller turligt nog, beroende på hur man ser på saken) brukar eventuella negativa sideffekter inte vara lika tydliga som svetten som stänker från den mer än fullt sysselsattes panna. De små, frekventa, och kanske lite imponerande stånken om att “det är så otroligt mycket just nu” gör också sitt till för att dölja det faktum att mycket är på gång men bara lite blir gjort.

Arbetsdagens längd varierar, men dygnet har exakt tjugofyra timmar, för åtminstone alla jag känner. Den som säger sig ha ont om tid menar alltså egentligen att det finns för mycket att göra. Någon gång då och då kan väl det problemet lösas med hjälp av en längre arbetsdag, men för de allra flesta producerar nog övertid mer magsår än affärsresultat.

Vad är alternativet till att jobba mer? Det är att lära sig hantera sin arbetsbelastning på ett sätt som ger resultat trots att tiden är begränsad.

Att lära sig hantera sin egen arbetsbelastning kräver två verktyg. Det ena är en personlig insikt om att den kortsiktiga nytta det innebär att “ha många bollar i luften” alldeles för ofta resulterar i långsiktig ineffektivitet. Det andra är förmågan att prioritera.

Lyckligtvis är inte båda dessa rekvisit lika svåruppnåeliga. Det ena av dem är faktiskt ganska lätt: att göra en prioriterad lista.

Varför göra en prioriterad lista? Tänk så här. Det är osannolikt att alla de saker du “måste” göra är lika viktiga. Alltså är vissa saker mindre viktiga än andra (dööh). De sakerna hamnar långt ned på listan.

Vad hamnar långt upp på listan? Längst upp på listan hamnar de saker som ger mest fyrverkerier för minst krut. Vissa kallar dessa saker lågt hängande frukt. Jag kallar dem ninjagrepp. Alla vet ju att de fruktade ninjorna (se upp för dem!) besitter kunskap om enkla grepp med dödlig effekt. Liten insats, hög verkningsgrad, eller på corporate-speak: bra nytto-kostnadsrelation.
Varför är det så effektivt att göra en prioriterad lista? Två saker gör metoden effektiv.

Här kommer den första: du kommer förmodligen ändå inte hinna göra allt du trodde du var tvungen att göra. När tiden är slut vill du självklart hellre ha gjort viktigare saker än mindre viktiga saker.

Här kommer den andra: när du gör en, rak och stilig, prioriterad lista så tvingas du göra svåra val. Två saker på en prioriterad lista kan nämligen aldrig (aldrig!) vara lika viktiga. Du måste välja. När vi verkligen måste välja tvingas vi tänka efter, och när vi tänker efter får vi mer kunskap om vad som är viktigt. Då ökar sannolikheten att när dagen eller projekttiden är slut, så har vi faktiskt åstadkommit något av värde både för oss själv och för andra.

Det sägs att vi svenskar är svåra att lära känna, men att när man väl lärt känna oss är vi lojala vänner. Inget större fel med den approachen, slutresultat verkar ju bli bra. Ett problem finns dock. När vi är på jobbet har vi inte alltid flera månader eller år på oss att bygga upp relationer med varandra.

Bristen på tid, upplevd eller verklig spelar ingen roll, leder till ibland märkliga situationer. Som när en person i ledande befattning, något försenad såklart, stormar in i ett konferensrum och hälsar på en handfull människor han aldrig träffat förut med orden: - “Låt mig börja med att berätta hur vi ska göra saker på det här bygget”.

Kanske inte det bästa sättet att etablera en mänsklig relation. Kanske får vi inte alltid det gensvar vi förväntar oss när vi inleder nya relationer på ett sätt som förnekar vårt behov av djupare kontakt.

Låter det flummigt? Borde man inte kunna förvänta sig av relationer på jobbet att de är sakliga och professionella, snarare än djupa? Nej, ibland kanske man kan önska att det vore så, men jag tror inte man kan förvänta sig det. Jag tror inte ens att det är önskvärt.

Så måste man vara kompis med alla sina kollegor?

Nej, jag tror inte det. Men jag tror inte heller att man klarar sig helt utan djupare kontakt.

Genom sig själv känner man andra, lyder ordspråket. Tänk efter - hur reagerar du själv när någon du inte känner kommer till dig och ber dig om något? När en projektledare du aldrig träffat presenterar sig kortfattat, och berättar att du ska jobba med serverkoden, ger dig inloggningsuppgifter och försvinner?

Å andra sidan: hur reagerar du om någon du inte känner gör en uppenbart ytlig ansats att “intressera sig för dig”?

Personligen kräks jag lite lätt på båda tillvägagångssätten. Det första är kallt och obehagligt, det andra är sliskigt och beräknande.

Så vad är mellanläget? Vad är ett avslappnat sätt att lära känna sina kollegor, utan att det känns krystat och tillgjort?

Här är två saker som jag tycker fungerar ganska bra, och som du kan dra nytta av redan idag och utan att be om tillstånd.

För det första, och jag kommer inte ihåg var jag först hittade denna sköna slogan, men den är bra: “Warm-up is never wasted.” Inget möte blir bättre av att man hoppar över de inledande 2-3 minuterna småprat, hälsa (med handslag) på varandra, säga hej. Tvärtom, efter lite uppvärmning slappar gruppen som möts av, och resten av mötet blir effektivare.

För det andra: etablera relationen idag. Vänta inte tills du absolut måste. Hugg någon vid kaffemaskinen och prata en stund. Fråga vad de heter och vad de jobbar med. Kan de någon teknik du är nyfken på, eller har ni kanske gemensamma bekanta? Var har de pluggat?

Nysta lite. Krysta inte fram det, men var beredd på att du kanske måsta sträcka dig lite utanför komfortzonen, det måste i varje fall jag. Fråga om det du skulle vilja att någon frågade dig om.

Intressera dig för dina kollegor, så går arbetet lättare. Dessutom gör du en insats för att bryta legenden om svensken som svår att lära känna. Bara en sån sak.

I det snudd på magiska ordet varför ryms ett otroligt kraftfullt sätt att lära sig mer om vad som helst.

Det berättas ibland sedelärande historier om chefer hos biltillverkaren Toyota som kommer till insikt om sina egna bristande inköpsdirektiv när de frågar varför det finns en oljefläck på golvet. De lyckas helt enkelt härleda det stora från det lilla, med den frigörande frågan: “Varför?” Det visar sig att de själva är ansvariga för oljeläckaget, eftersom de stipulerat inköp av oljefilter från den billigaste leverantören, som tyvärr också visade sig vara den sämsta.
Själv brukar jag använda mig av ett ganska praktiskt verktyg som ibland kallas varför-hur-trappan [1]. Har man tillgång till något att rita på ritar man helt enkelt en liten trappa, och lägger gärna till en pil som pekar upp för trappan med texten “Varför”, och en pil som pekar nedåt med texten “Hur”. Sen är det bara att skriva in det vi vill lära oss mer om någonstans mitt på trappan, och sedan följa trappstegen i endera riktningen. Tar vi ett steg uppåt frågar vi oss varför, går vi nedåt frågar vi oss hur.

Så här till exempel: vi borde börja skriva fler automatiska tester, skriver vi på mitten av trappan (eftersom någon just föreslagit det efter att ha läst MVKJG 1. Sen frågar vi oss varför, och skriver in svaret på steget ovanför: så att vi effektivt kan fånga och ta bort fler fel. Steget ovanför kommer nästan av sig själv, vi vill såklart bygga en felfri produkt, och anledningen till att vi vill det är förstås att vi vill ha fler kunder.

Vi kan gå nedåt också, genom att fråga oss hur. Varför inte rekapitulera från toppen? Vi vill ha fler kunder. Hur kan vi få det? Genom att ha en felfri produkt. Hur kan vi få en felfri produkt? Genom att hitta och eliminera så många fel som möjligt. Hur då? Genom att skriva automatiska tester som hjälper oss i testarbetet!

Sen kan vi fortsätta ännu längre ner förstås. Hur ska vi skriva automatiska tester? Genom att lära oss hantera ett ramverk för att skriva och aggregera tester. Hur ska vi lära oss ett sånt ramverk? Genom att köpa in böcker och planera in tid för lärande i vårt arbete.

Den här enkla modellen är vansinnigt användbar när man planerar ett projekt eller en iteration. Genom att placera in bitar av planen i trappan kan vi känna om de ligger på rätt nivå. Är de lagom konkreta, lagom målorienterade?

När jag hjälper till att planera iterationer vill jag till exempel att de funktioner och kvaliteter vi planerar i ska uttryckas så att utvecklingsteamet själva kan välja hur man vill uppnå dem. Blir vi konkreta för tidigt riskerar vi att låsa in våra tankar och eliminera möjligheter. Är vi för abstrakta blir det svårt att se om det vi planerar verkligen är genomförbart.

Proffsteknik: låt trappan evolvera till ett träd av orsakssamband som sprider sig i alla riktningar. Det finns ju alltid fler sätt att förklara orsaken till något, precis som det finns fler sätt att åstadkomma ett visst resultat.

Ett varningens ord på vägen dock. Konsulten och författaren Gerald Weinberg har pekat ut [2] att en fortsatt undersökning av ett problem ofelbart leder fram till problemets källa, som med största sannolikhet är din uppdragsgivare. På Toyota pratar man om fem varför. Jag brukar kalla metoden för “fråga varför tills du får en smäll på käften”. Det återspeglar bättre den sanna potentialen i denna grovt underskattade teknik.

—-

[1] Jag lärde mig verktyget i den suveräna “Att sälja och ta betalt för kunskap” av Britt-Marie Ahrnell och Rolf Edman.

[2] Se till exempel den roliga Secrets of Consulting, Gerald Weinberg.

För en tid sedan påminde jag några utvecklare om hur användbart och effektivt det är med automatiska tester. Jag tyckte att jag intog en ganska pragmatisk inställning, och tipsade (för att vi skulle komma igång med testskrivandet) om följande introduktionsupplägg.

Under den kommande iterationen kunde vi för varje bugg vi hade uppdrag att fixa först se efter om det verkade gå att skriva ett automatiskt test som återskapade buggen. Om det å ena sidan verkade gå kunde vi helt enkelt skriva testet. Om det å andra sidan inte verkade gå kunde vi skriva ned några anteckningar om varför det inte gick, och sedan tillsammans gå igenom vad som gjorde det svårt att skriva tester.

Ganska moderat upplägg, om jag får säga det själv. Svaret kom dock rätt snabbt: - “Vi har hört det här förut”. Och det hade de naturligtvis. Idag är det svårt för en utvecklare att missa alla uppmaningar om att man måste skriva sina egna automatiska tester, och som ofta när trycket i en riktning blir högt kommer ett mottryck som ett brev på posten. I det här fallet resulterar det i att inga tester skrivs.

En missuppfattning som kanske bidragit till att skrämma upp många är tron att vi måste skriva tester som täcker in alla möjliga felfall. Det är sällan möjligt, eftersom antalet möjliga kombinationer som måste testas ökar så snabbt i en framväxande mjukvara. Istället måste vi sätta oss in i hur vi kan testa för att få maximal avkastning på våra tester. Att börja med att skriva tester som varnar när en tidigare fixad bugg dyker upp igen är till exempel otroligt väl investerad tid.

Många har förklarat och argumenterat för att utvecklare skriver automatiska tester för sin egen kod. Jag har inga nya argument att tillföra, utöver detta: idag verkar de bästa utvecklarna i världen samstämmigt skriva under på att automatiska tester är viktiga, nyttiga och till och med ganska roliga, och att de ska skrivas av utvecklaren själv. Kanske kan detta åtminstone få dig lite nyfiken?

De är definitivt något du kan börja med idag, utan större investering i vare sig pengar eller tid.

*) Men Vad Kan Jag Göra?

Sitter du fast i ett projekt som också sitter fast? Har du tappat hoppet för mänskligheten (eller bara för den del av mänskligheten som utvecklar mjukvara)? Håll ut: det finns hopp. Du behöver inte förändra världen, eller ens ditt projekt, med ett svepande hugg. Du kan göra saker bättre ett litet steg i taget, helt på egen hand.

I min ficka har jag samlat inte mindre än 99 tips om vad du kan göra redan idag för att börja förbättra ditt projekt. Helt utan att be någon annan om tillstånd. Utan någon större investering. Utan att behöva anlita en hord av RUP-konsulter. Det finns ljus i tunneln. Ett steg i taget bara. Ett steg i taget.