02.28.09
Adaptiv Sthlm AB
Nu kan det (äntligen!) offentliggöras att jag, tillsammans med Johan ”Behe” Lind och Måns ”Månstret” Sandström, kommer att starta ett nytt bolag vid namnet Adaptiv Sthlm AB. Webbplatsen blir adaptiv.se och bolaget drar igång i början av april.
Varför Adaptiv Sthlm? Namnet ska naturligtvis skänka associationer till adaptivitet, dvs anpassningsbarhet, en viktig aspekt av lättrörlighet. Det andra ordet tillkom mest för att öka ”rockfaktorn”. Vi kommer att erbjuda tjänster som coachning, utbildning och realisering inom systemutvecklingsområdet. Som en personlig not kan jag säga att jag ser fram väldeliga emot att få två trevliga och högst kompetenta kollegor.
En sak till, den här bloggen kommer troligen att fortsätta som förut, men verksamheten i mitt eget bolag, Terrier Software, kommer att minska radikalt.
02.16.09
Dokument på rätt sätt
I mina senaste inlägg har jag velat göra det för troligt att när det gäller att kommunicera, förklara, designa, lösa problem, undervisa och liknande aktiviteter är konversation ansikte mot ansikte vida överlägset att någon skriver och någon annan senare läser ett dokument. Faktum är att vi ofta kan se det sistnämnda som svinn, det vill säga ett slöseri med våra begränsade resurser. Det finns effektivare sätt att kommunicera och få fram det vi vill.
Dokument då, menar jag att de är helt värdelösa? Nej, det är de verkligen inte! Det skrivna ordet har flera fördelar:
- minne
- struktur
- potentiell verifierbarhet
Den viktigaste egenskapen hos dokument är att de utgör ett någorlunda persistent minne. Våra mänskliga minnen klingar som bekant av med tiden och är starkt färgade av vår egen upplevelse och personlighet. Det är till exempel därför vi har för vana att skriva protokoll på viktiga möten.
Dokument har en inbyggd struktur, vilket med fördel kan användas av någon som vill samla sina tankar. Håller mitt resonemang? ”Det luddigt skrivna är det luddigt tänkta”, brukar man ju säga. Jag finner själv skrivandet som ett sätt att tänka igenom och klargöra vad jag tänker och tycker. Dokumentet kan i detta fall givetvis vara en ”mind map”, om man föredrar det.
Till sist kan vissa dokument, uttryckt på formell form, verifieras på ett sätt som inte är möjligt med konversationer. Ett avtal kan till exempel kontrolleras av en bolagsjurist. En testare kan verifiera mot en testspecifikation. Ett dokument i elektronisk form kan användas för att automatiskt verifiera att ett system fungerar som det ska. Vissa dokument kan köras av en dator och kallas då för program.
Hur få ihop detta nu? Det verkar som att jag talar emot mig själv. Min poäng är att vi bör använda dokument på det som de är bra på och slopa dokument på områden där de inte bra. Eftersom dokument är så överskattade råder en kraftig överanvändning av dokument som kommunikationsmedel. Det är ur den aspekten man ska läsa den agila värderingen ”[vi värderar] fungerande mjukvara framför omfattande dokumentation”. Dokumentation är bra (ibland). Överdriven dokumentation är svinn. Svinn kostar pengar.
Inom mitt eget område, systemutveckling, finns tre grundläggande former av dokument:
- Arbetsdokument, dokument som tas fram under arbetet för att kommunicera mellanresultat
- Leveransdokument, dokument som är del av leveransen till kund
- Överlämningsdokument, dokument som krävs för att lämna över arbetet från en grupp människor till en annan, till exempel från ett projekt till en förvaltningsorganisation.
Hur kan vi behandla dessa varianter på ett sätt som utnyttjar vad vi vet om rika kommunikationsformer, men ändå tar bibehåller de goda egenskaperna hos dokument? Jag brukar använda följande tumregler:
- Arbetsdokument undviker vi så länge som är möjligt (och lite till). Dessa ersätts nästan helt av minneslappar och konversationer. Här handlar det nästan alltid om att kommunicera och förstå, vilket det finns bättre sätt för.
- Leveransdokument behandlas som vilken leverans som helst. Det är en egenskap hos produkten som måste värderas, prioriteras och estimeras som vilken annan egenskap som helst. Fördelen med detta är att det tydligt visar kostnaden av att skriva dokument. Det är inte något som vi bara får ”på köpet”.
- Överlämningsdokument skriver vi när vi måste, men den verkliga magin är att aldrig sätta sig i en sådan situation. Om vi inte har några överlämningar behöver vi inga överlämningsdokument. Det här tarvar sin förklaring men det får vänta till en annan gång. Om vi ändå måste skapa överlämningsdokumentation är nästa trick att göra den så rik som möjligt. Varför inte filma den mest erfarne systemutvecklaren när denne förklarar hur systemet fungerar i stället för att låta denne skriva dokument?
Låt mig till sist ge några exempel på hur du kan använda dokument på ett klokt sätt:
- Om du har en kund som misstror dig eller ditt företag tar du självklart anteckningar på alla beslut, något annat vore oklokt (minne).
- Skriv ned mål, behov och krav på en superenkel form (1-2 meningar) utan detaljer. Se det nedskrivna som en minneslapp för framtida konversationer (minne).
- För alla möten som du ska leda eller facilitera, tänk inför mötet igenom målet för mötet, vilka punkter som ska diskuteras och i vilken ordning (struktur).
- Skriv detaljkrav på system och produkter på en form som kan bindas till systemet självt och exekveras automatiskt av ett testverktyg (verifierbarhet).
Jag önskar bara att jag kunde diskutera detta med dig som har läst ända hit i stället för att skriva det…
02.08.09
Dokument är fattig kommunikation
I mitt förra inlägg beskrev jag hur en dispyt lätt kan uppstå vid kommunikation med e-post. Skälet till att det händer så lätt är att vi inte får med oss alla övertoner när vi läser brevet. Vi kan till exempel inte höra personens tonfall eller se dennes kroppsspråk, vilka tillsammans lär stå för över hälften av det som egentligen kommuniceras mellan två parter. På liknande sätt kan vi analysera andra vanliga sätt att kommunicera efter vilka uttrycksmöjligheter som står till buds:
- Konversation ansikte mot ansikte: Språk, ansiktsuttryck, gester, kroppshållning, tonfall, timing, doft, beröring, spänningsnivå, synkroniserade uttryck, direkt återkoppling, möjlighet till kollaborativt samarbete, med mera.
- Videokonferens: Språk, ansiktsuttryck, tonfall, timing, direkt återkoppling
- Telefon: Språk, tonfall, timing, direkt återkoppling
- Chatt: Språk, direkt återkoppling
- E-post: Språk, viss återkoppling
- Dokument: Språk
Med timing avses hur uttryck tidsmässigt passade ihop (t.ex. pauser). Med återkoppling avses mina egna möjligheter att interagera vid rätt tidpunkt, till exempel ställa en klargörande fråga. Kollaborativt samarbete är möjligheten att i stället gå iväg och ställa sig framför en tavla och illustrera tankar för varandra. Doft är kanske inget vi tänker på normalt, men vi vet ju vid det här laget att vi styrs mer av dofter än vi tror. Vi märker det snabbt om någon inte luktar gott.
Ju högre upp på listan, desto fler uttrycksmöjligheter finns det tillgång till. Man kan uttrycka det som att konversation har högre bandbredd för kommunikation än de övriga. Konversation ger möjligheter till en rikare form av kommunikation.
I nedre delen av listan hittar vi kommunikationssätt med lägre bandbredd. Om vi tar bort alla möjligheter (utom språket i sig) som står oss till buds för att skapa en klar och tydlig kommunikation mellan oss hamnar vi på… dokument. Dokument är alltså det sämsta kommunikationsmedlet vi har sett till bandbredd. Det ironiska i sammanhanget är att om vi tittar på vilken status dessa kommunikationssätt har i affärslivet så är ordningen den omvända: Dokument har högst status och konversationer lägst.
Vart vill jag komma med allt det här? Jo, om dokument ger sämst möjligheter att kommunicera kommer vi att få flest överföringsfel på den kanalen. Om kommunikationen till exempel handlar om att förklara något komplicerat för någon annan kommer kommunikation via dokument att leda till flest missförstånd och sämst inlärning. Missförstånd leder i sin tur till omarbete och defekter. Kent Beck har skrivit att man kan spåra de flesta fel i produktutveckling tillbaka till en kommunikationsmiss någonstans. Företaget trodde att kunderna ville ha export till pdf (när de i själva verket uttryckte ett annat behov). Teamet tyckte att produktchefen sa att vi skulle lösa detta med tryckavkänning (när hon egentligen sa att det kunde vara ett sätt att kanske lösa det). Ju rikare kommunikation, desto större chans att vi kan rätta till missförståndet snabbt.
Tillbaka till Roger från det förra inlägget, vilken okunskap uttryckte Roger? Okunskapen sken igenom i denna sats: ”Jag vet att man inte ska skriva dokument när man jobbar agilt…”. Den borde ha lydit: ”Jag vet att man inte ska skriva dokument när det finns rikare sätt att kommunicera…” Det har inte så mycket med agilt att göra eller ej, snarare hur vi kommunicerar med varandra. Hade Roger uttryckt sig på det viset hade han kanske insett att det inte var för att kommunicera bättre som Roger behövde ett dokument i det här fallet utan för att komma ihåg något. Varför skulle Roger inte använda ett verktyg han av erfarenhet vet fungerar?
I mitt nästa inlägg tänkte jag titta lite på några fall där det kan vara motiverat att ta kostnaden för att skriva ett dokument.
02.04.09
Tre framtidsfrågor
Peter Larsson på IDG mejlade mig (och säkert många andra) för en tid sedan med tre intressanta frågor rörande framtiden för svenska systemutvecklare. Kanske blir det publicerat någon gång och i någon form i Computer Sweden, men här är i alla fall mina kompletta svar. Det finns mycket man kan säga i dessa frågor, känner jag. Hur skulle ni ha svarat?
PL: Hur ser framtiden ut för utvecklare i Sverige?
JH: Jag bedömer den som lovande. IT-stöd och verksamhetsprocesser smälter ihop mer och mer till ett och detsamma. IT är redan kärnverksamhet och att utkontraktera utvecklingen av livsviktiga stödsystem till andra länder är en farlig väg. Svårigheterna att samarbeta och de långa ledtiderna är hinder som inte kommer att försvinna. Vidare kommer miljöaspekter på resande få en allt större inverkan. Varför skapa 100 resor/år till Indien när vi har närvarande, engagerade utvecklare nära? En annan intressant dragkamp är den mellan egenutvecklat och ”standardsystem”. När folk inser att standardsystemen måste programmeras, och dessutom i proprietära språk, känns troligen egenutvecklat mer intressant igen. Sverige har duktiga utvecklare och många fina produktbolag.
PL: Vilken framtida fråga kommer att vara viktigast för utvecklare?
JH: Svårt att säga vilken som kommer att vara viktigast, men en viktig fråga är vilken status vi systemutvecklare väljer att ha. Vill vi vara kodapor mot spec eller vill vi vara högt värderade medarbetare som utvecklar affärerna? Håller vi kunden på armlängds avstånd finns litet som hindrar kunden att ersätta oss med någon billigare. För att nå det sistnämnda tror jag att vi aktivt måste välja detta alternativ och ta det ansvaret. Högsta kvalitet och minsta slöseri är obligatoriskt annat än i undantagsfall. Vi bör se systemutveckling som ett hantverk, där etik, miljöpåverkan, helhetssyn och samarbetsvilja blir viktiga komponenter.
PL: Vilken teknik ska utvecklare satsa på? Java? Dotnet? Azure? Amazon EC2? Google App Engine? Något annat? Varför
JH: Mitt råd blir att välja det som känns lovande, kul och rätt för dig. Jag brukar rekommendera utvecklare att följa råden från ”The pragmatic programmers” att göra en personlig utvecklingsplan. Rita upp en karta över var du är nu och vart du vill. Var ständigt lärande, fastna inte i en teknik. Läs böcker och engagera dig i ditt yrke. Lär dig både något som är bra att kunna i morgon och något som känns sannolikt på några års sikt. Den som är tidigt ute på en teknik som sedan blir populär har mycket att vinna.
TDD/BDD-kursen är tillbaka
Jag och min kurskollega Måns har arbetat hårt under hösten med att vidareutveckla vår kurs i TDD/BDD. Vi har redan tidigare kört kursen en handfull gånger och fått mycket goda vitsord, men världen förändras och även vi. En nyhet är att vi delat upp kursen i flera kurser som riktar sig till personer på olika nivå. Vi har en kurs för nybörjare, en för erfarna och en för experter. En annan nyhet är att vi satsat hårt på att förbättra vår didaktik, hur vi får personer att lära sig ämnet. Vi har också utökat tiden för praktik, för det går inte att lära sig TDD utan att göra det själv.
Om du eller någon du känner är intresserad så kan jag tipsa om att kursen för nybörjare kommer att ges publikt igen, 9-10 mars i Stockholm, i arrangemang av Jaybis. Den här kursen är lämplig både om man är helt ny på området eller om man är erfaren på enhetstestning men inte på TDD. Vi kör i javamiljö, men det är inte viktigt, vi har haft många dotnetutvecklare som har gått kursen utan problem. På två dagar går det inte att bli expert på TDD, men vi siktar på att ge deltagarna en god start på sin TDD-bana.
