Enkla lösningar

februari 7, 2010

Jerry Weinberg har sagt att: ”Det finns inga svåra problem, bara svåra lösningar.” Som programmerare är alltså din främsta uppgift att hitta enkla lösningar på de problem du ställs inför.

Det finns en stark tro på att verklighetens problem kräver komplexa lösningar.
I själva verket beror den uppfattningen på att vi har för vana att välja tekniker som medför oavsiktlig komplexitet. Företagsstandarder, modeord och svag teknisk kompetens gör att vi väljer tekniker som inte är lämpade för de problem vi ställs inför. ”Här gör vi allt i Java!”, ”Vi löser alla problem med en SOA-lösning!” och ”Vi väntar till dess Microsoft släpper ett verktyg för det här!” hörs systemutvecklare säga, gärna med viss stolthet i rösten.

Själv har jag, bland annat, sett hur man lagt hela applikationer som lagrade procedurer i relationsdatabaser. Ovanpå detta har man kopplat GUI’n som går direkt mot dessa lagrade procedurer. Eftersom man uppfattat det som problematiskt att låta samma GUI-applikation gå mot flera databaser har man dessutom använt en välkänd integrationsprodukt för att kopiera data mellan databaser så att GUI-applikationerna kan få se det data som låg i den främmande databasen. Ibland handlar det bara om en boolesk variabel. En etta eller en nolla. En ensam liten bit. För åskådliggörandet av denna enda lilla bit definieras ett företagsstandardiserat protokoll som en XSD för att beskriva hur ettan (eller nollan) ska serialiseras till text (XML) som sedan ska skickas på en kö så att den kan läsas av en annan integrationsmodul för att av den kunna skrivas ner i den andra relationsdatabasen från vilken GUI-applikationen läser denna etta (eller nolla).

Så vill vi inte ha det. Vi måste lära oss att se att en lösning inte bär sin vikt. Vi får inte skapa lösningar som i sig är större problem än ursprungsproblemet.
Misslyckas man med det har man även misslyckats som systemutvecklare.

Agilt arkitekturarbete

januari 12, 2010

Under den långsamma övergången till ett agilt arbetssätt har en del av de traditionella rollerna och artifakterna visat sig vara problematiska. Inget arbete har stötts och blötts så mycket som arbetet med ”arkitekturen”. Frågan hur man arbetar med en arkitektur i ett agilt sammanhang är ganska knepig att besvara, men jag tänkte göra ett försök.

Arkitekturbegreppet

Ralph Johnson säger (fritt översatt) i Martin Fowlers artikel Who needs an architect:

Arkitekturen omfattar det som utvecklare anser viktigt för att kunna förstå hur systemet fungerar och kunna delta i vidareutvecklandet av det.

Vissa delar av arkitekturen är på låg nivå, andra på högre nivå. Om vi måste anpassa en produkt efter hur den integrerar med befintliga tjänster eller produkter är lösningen för det en del av produktens arkitektur, men även hur vi väljer att kommunicera mellan mindre komponenter inom vår produkt är en del av arkitekturen. På lägsta nivån är språkval och runtime-miljö även där en del av arkitekturen, med det inte sagt att den aspekten behöver vara enhetlig genom hela produkten men det är en arkitekturell aspekt på det vi gör. Kort sagt vi har arkitektur på alla olika nivåer av abstraktion.

Den agila ansatsen

I agila sammanhang är man mån om att man inte ska lita för mycket till gammal kunskap. Under utvecklandet av en produkt är vi i ständigt lärande. Den nya kunskapen vill vi, så fort det är möjligt, införliva i produkten. Därför försöker vi göra allt arbete kontinuerligt under utvecklandet. Kommer man till en situation med okända behov är det egetligen inte något problem, det tillhör det dagliga agila systemutvecklingsarbetet att utreda behov. På samma sätt förhåller det sig med arkitekturarbetet, vi kommer att vara tvungna att kontinuerligt se över vår arkitektur. En agil arkitektur ska svara mot de behov vi uppfyller nu, inte mot de vi kanske uppfyller imorgon, men inte heller mot de vi uppfyllde igår. Arkitekturen är på tok för viktig för att vi ska kunna nöja oss med att bara ägna den uppmärksamhet i början av utvecklingsarbetet.

Med det inte sagt att agila utvecklare inte kan tänka efter före. Många av dem jag känner gör en första, rimligt initierad, gissning innan de sätter igång med utvecklingsarbetet. De aktar sig bara för att tro att den initiala gissningen är rätt arkitektur och förbereder sig istället för att den ska kunna förändras.

Två skrån med olika fokus

Inom den agila rörelsen har det varit stort fokus på tvärfunktionella arbetslag som arbetar koncentrerat med en produkt och att låta arbetslaget gemensamt ta ansvar för det tekniska helhetsperspektivet för produkten.
Arkitektskrået har samtidigt rört sig längre bort från tekniken och man pratar om strategisk IT och verksamhetsutveckling. Här fokuserar man mycket på synergieffekter av olika integrationsstrategier och, i viss mån, verksamhetsmål med IT-förvaltning alltid sett över en hel produktportfölj. Där skiljer sig de åt, olika horisont och olika perspektiv.

Spekulativ och oavsiktlig design

Att dessa två, tillsynes välvilliga, rörelser har svårt att finna gemensam mark beror på följande problematik. De agila arbetslagen vill låta arkitekturen växa fram allt eftersom behoven manifesteras och de vill själva välja hur de tekniskt ska implementera de verksamhetskrav som framställs samtidigt som arkitektskrået gärna ser sig som ett kompetent tekniskt roder för hela verksamheten där de bidrar med tydliga riktlinjer för hur vissa aspekter av systemet ska implementeras.

Arkitekterna uppfattar här de agila utvecklarnas process som något som leder till en oavsiktlig design eftersom designen bara blir det som behoven påkallar. Agila utvecklare, å sin sida, tycker att det arkitekterna gör sig skyldiga till är spekulativ design som, allt som oftast, visar sig vara onödigt komplex och tungrodd.

Agilisterna uppfattar att arkitekterna fråntar utvecklarna designansvaret vilket leder till osäkerhet bland utvecklarna när man upptäcker svagheter i designen. Arkitekterna å sin sida tycker att utvecklarna inte är kompetenta nog att förvalta helhetsdesignen.

Det är alltså inte en argumentation om huruvida arkitekturkompetens är viktig eller ej – båda läger tycker att den är av avgörande betydelse. Konflikten ligger i hur den ska tillämpas.

Fördomarnas ursprung

För att förstå vad dessa ömsesidiga fördomar bottnar i måste man se till de olika grupperingarnas vardag. I lite mer traditionellt ledda systemutvecklingsorganisationer tillhör det god sed att uppmärksamma talangfulla programmerare och genast göra dem till arkitekter eller, t.o.m. projektledare (ja, jag har sett det hända). Kvar blir, generaliserat, oerfarna och mindre engagerade programmerare som inte har erfarenhet nog att själva fatta goda designbeslut. Faktum är att de ofta inte heller är kapabla att förstå och följa de direktiv som överlämnas från arkitekterna. För att komma till rätta med utvecklarnas tillkortakommanden har man typiskt en designfas. Ett par arkitekter samarbetar (i bästa fall) för att fixera grundtankarna i produktens arkitektur. Vikten av att tänka efter före är enorm – just eftersom man inte kan lita på att utvecklarna kommer att själva kunna förvalta designen aktivt.

I agila sammanhang ser det lite annorlunda ut, som talangfull programmerare blir man inte arkitekt, istället är den viktigaste uppgiften att agera designcoach och parprogrammeringspartner i arbetslaget. Kompetensen inte bara uppmärksammas, den anses t.o.m. så viktig att man inte vill isolera den till någon viss person. Man tar den initiala kostnaden för att sprida kompetensen eftersom man vet att det kommer att betala sig på kort tid. Faser finns inte inom agil utveckling, istället strävar man efter att kontinuerligt hålla uppmärksamheten på produkten som helhet.

Som vanligt kan vi konstatera att båda läger har kommit till en insiktsfull, men fördomsfull, slutsats baserat på den vardag man befinner sig i. Den stora skillnaden är att de agila arbetslagens vardag kan beskrivas som samarbetsorienterad och platt medan arkitekternas vardag baseras på en traditionell ledarskapssyn enligt command-and-control och top-down hierarkier.

Agila Sverige 2009

maj 13, 2009

Förra året hade jag, tillsammans med ett par goda vänner, förmånen att få arrangera en agil konferens om agil systemutveckling. Under två dagar träffades ca. 150 personer, från hela Sverige, i Stockholm för att utbyta erfarenheter via blixttal och open space.

I år återkommer konferensen och jag är stolt över att åter få stå som medarrangör. Ett huvudmål med konferensen är att vara tillgänglig. Det kostar bara 1000:- för två dagar inklusive en trevlig och god middag. Som deltagare kan man räkna med att få träffa engagerade och kunniga systemutvecklare som, mer än gärna, delar med sig av sina erfarenheter i drygt 50 blixttal och i ett 20-tal open space-sessioner. Förra året gavs deltagarna konferensen betyget 9,3 av 10. Kom och hjälp oss göra årets upplaga ännu bättre.

Jag arrangerar agila sverige 2009

Adaptiv startar

mars 25, 2009

Den 1:a april börjar jag på nytt jobb. Egentligen är det inget nytt jobb för jag kommer göra precis samma saker som tidigare. Agila införandeuppdrag och teknikkonsulting är det som jag gjort de senaste 5 åren och det är det jag kommer att fortsätta med. Det är snarare ett nytt liv. Joakim Holm, Johan Lind och jag kommer att tillsammans starta Adaptiv Sthlm AB (vi kallar det bara Adaptiv).

Det är naturligtvis spännande, roligt och stimulerande att få chansen att jobba med så duktiga medarbetare som Johan och Jocke, men jag tänkte ta tillfället att besvara de frågan som jag oftast får om detta.

Varför nu när krisen bryter över oss!?

Ptja, spelar det någon roll egentligen? Visst kan det bli så att krisen kan komma att pressa priser eller att man får gå någon månad utan uppdrag, men samma kris gäller ju även om man är kvar hos sin arbetsgivare. Dessutom är min uppfattning att kriserna blir mindre för mindre företag. Man behöver inte ta på sig några stora fasta kostnader och att hitta uppdrag åt tre seniora konsulter är betydligt enklare än att göra det åt 15 oerfarna.

Som konsulter med 10+ års arbetslivserfarenhet tror vi att det blir lättare för oss att märkas under en lågkonjunktur. Kostnadsskillnaden mellan en junior konsult och en seinor är skrattretande liten och vi kan visa på att vi kan utgöra en investering med hög avkastning vilket är det som efterlyses när marknaden är svag.

Även om det finns många fantastiskt duktiga och intressanta teknikgurus i Stockholm så är jag väldigt tacksam för att vi blev tre och att det blev vi tre. Det är tillräckligt svårt att hitta tider då alla tre kan ses och Johan och Joakim kommer att kunna stimulera mitt lärande under många bra år framöver. Det blir spännande att prova alla de mer eller mindre nya och galna idéer som vi har för företaget och jag hoppas på att vi kommer att få tillfälle att samarbeta med många andra mindre konsultfirmor i Sverige.

Ses!

Nytt kurstillfälle i TDD/BDD

februari 16, 2009

Tillsammans med Joakim Holm har jag, under hösten, arbetat hårt med att vidareutveckla vår kurs i TDD/BDD. Våra elever har varit nöjda med våra tidigare kurser, men vi har hela tiden ansträngt oss för att hitta nya och inspirerande sätt att lära utt TDD och BDD. 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. I vår nybörjarkurs har vi utökat tiden för praktik, för det går inte att lära sig TDD utan att få utföra momenten 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. Under de två dagarna får du en inblick i hur experterna arbetar framgångsrikt med TDD/BDD. I viss mån innebär TDD/BDD en kunskap om rätt verktyg och hur och när man bör använda dem. Men det är också en samling relaterade arbetssätt och tekniker som kräver studier och övning för att bemästra. Vissa arbetssätt kan finslipas under en livstid. Sett ur ett ännu högre perspektiv är TDD/BDD en attityd, ett sätt att se på hantverket att utveckla goda system och produkter. Vi vill tipsa om verktygen, få deltagarna att prova arbetssätten och utstråla attityden.

Noll fel

augusti 26, 2008

När jag gick min systemvetarutbildning så var man tydlig med att något som skulle kunna kallas buggfri programvara det finns inte. Även de enklaste av program är behäftade med buggar, helt enkelt för att även de är så komplexa.

Nu med agila (lättrörliga) metoder är noll fel en värdering och helt plötsligt anser vi att vi visst kan leverera buggfri programvara – hur kommer det sig?

Jag tänker försöka förklara vad vi menar med noll fel och sedan förklara i vilken utsträckning det idag är möjligt att komma dit.

Bugg eller brist

För att förstå hur vi kan börja tänka tanken på att leverera buggfri programvara så måste vi först fundera på vad en bugg är. En bugg i den här bemärkelsen är när programvara inte uppför sig som förväntat. En enkel variant skulle kunna vara att en svensk kalenderapplikation missar skottdagen eller att den tror att första dagen i veckan är en söndag (vilket är sant i många länder, men inte i Sverige). Detta skiljer sig från en brist som i kalenderapplikationen skulle kunna vara att man bara kan se innevarande månad. Många skulle idag kalla brister för buggar, men det tycker jag är konceptuellt fel. Att ha brister i programvara är ett normaltillstånd och allteftersom vårt användande utvecklas uppstår brister som vi kan välja rätta till i programvaran eller välja att leva med.

Med agil systemutveckling så har vi blivit väldigt duktiga på att uttrycka exakt vilket beteende som stöds av vår applikation. Alla de specifikationer i form av exekverbara tester som vi skapar under framtagandet av koden kan tala om för oss exakt hur vi kan förvänta oss att applikationen fungerar. Skulle något sätt att använda koden på vara odokumenterat så kan man säga att det beteendet inte stöds av applikationen.

Förutsatt att alla våra tester ”är gröna” så kan vi säga att vi inte har buggar i vår applikation, eventuellt har vi brister, men inte buggar.
Ok, då var det alltså klarlagt, vi kan ha noll fel. Nej, så enkelt är det inte.

Agila buggar

Först ett självklart undantag. När vi skriver våra exekverbara programspecifikationer så försöker vi helatiden göra det i så små isolerade enheter som möjligt, helt enkelt för att kunna ta så små och kontrollerade steg som möjligt. Skulle vi bara lita till de tester som vi har på lägsta nivå (och många gör det fortfarande) så kan vi inte uttala oss om hur de små enheterna fungerar tillsammans. Därför proklamerar agila metoder för att man ska låta de små testerna komma av större tester som baseras på användarscenarier. Men även för de lyckliga få som använder den typen av automatiserade scenarietester så finns små kryphål. Idag utvecklas nästan alla applikationer för användande på Internet. Det innebär att vi är många användare som samsas om appliktionsresurserna. Även tämligen avancerade scenarietester kan komma att missa konsekvensen av väldigt många samtidiga användare och det gäller inte bara prestanda utan även logiska fel som i hanterandet av tillstånd. Att hantera tillstånd trådsäkert är inte svårt i sig men misstag är svåra att upptäcka. Klart mest problematiskt är dock det faktum att våra specificerande tester bara tjänar som exempel på användandet. Vi kanske tror att vi har kommunicerat all funktionalitet när vi i själva verket har missat delar, eller missförstått i det tysta. NLP lär oss att det kan bero på att vi inte lyckats avtäcka de djupstrukturer som döljer sig bakom beställarens ord alternativt att vi omedvetet väljer att förstå beställningen på ett sätt som är felaktigt för att det förenklar lösningen.

Ögonbrynshöjare

Sammantaget får vi nog vänja oss vid att, även i framtiden, se buggar dyka upp i våra applikationer. Min erfarenhet säger mig dock att buggar kommer att vara ögonbrynshöjare. Vi kommer inte behöva buggrapporteringssystem där vi registrerar de hundratals buggar som upptäcks under användandet. Istället kan en whiteboard med uttrymme för 1 – 10 buggar noterade på Post-Its eller indexkort vara tillräckligt.

Jag hade en chef för en tid sedan som stolt förklarade för mig att anställda vill ha en chef som säger nej. Jag är helt säker på att han hade vissa belägg för sitt påstående, men jag är lika säker på att det finns en mer nyanserad formulering som ligger ännu närmre sanningen. Personligen vill jag ha en chef som skapar goda förutsättningar för de anställda att själva förstå hur de ska tackla de problem som de ställs inför. Jag kallar det ”management från sidan”.

En chef, eller gruppledare, ska se sig som en ledsagare som har en god idé av vilket klimat han vill skapa på arbetsplatsen och sedan gör allt för att det klimatet ska uppstå genom de anställdas engagemang. Problem som uppstår i organisationen ska inte gömmas undan i något styrelserum, det ska upp på den största whiteboard man har och sedan ska alla känna att de har rätt att bidra till en lösning av problemet. Likadant med företagets framtidsvisioner. Som ledsagare kan man visa på framkomliga vägar men man behöver inte se till att alla ”rättar sig i ledet”, ofta kan kunskaperna hos kollektivet hitta en ännu mer framkomlig väg som ger samma resultat och då ska de inte hindras från att få välja den vägen.

Jag känner mig manad att ge alla ni chefer därute (som tyvärr aldrig kommer läsa detta…) en lista på vad ni borde tänka på:

  • Lita på dina anställda – de vill också känna sig engagerade.
  • Var öppen med organisationens problem om du vill ha dem lösta.
  • Även ”fotfolk” förstår problem som ett företag ställs inför.
  • Att lösa problem är roligt, du kommer att ha många frivilliga medhjälpare.
  • Att låta de anställda vara med och besluta om vad som är företagets största problem kommer vara intressant både för dig och de anställda.
  • Förståelsen mellan arbetsgivare och anställd kommer att öka och, rentav, bli god.
  • Var inte rädd att säga vad du tycker men se till att du inte underkänner någon annans åsikt. De vet att du har sista ordet – du behöver inte hävda dig på den punkten.
  • Se till att du förstår de synpunkter som kommer in – vissa åsikter kan te sig helt galna, men de är också de mest intressanta. Kanske kan ni, tillsammans, förädla dem.
  • Eftersom ni troligen inte arbetat såhär tidigare så får du tänka på att det kan ta lite tid för dina anställda att vänja sig vid det nya arbetssättet.

Slutligen – försök att inte vara en semafor-chef, föreställ dig istället att du står vid sidan om organisationen och iaktar lite som en lugn fotbollstränare. Finn glädje i att coacha dina anställda när du tror att det är välkommet och när du tror att du har något att bidra med, men det är de som ska lösa problmen och de måste få den information de behöver för att kunna hitta den bästa lösningen.

För en tid sedan träffade jag en gammal skolkamrat på väg hem från jobbet. Det slog mig då att, sist jag träffade honom, formulerade han en så sympatisk syn på samhällsekonomiska system. Nu ska jag väl genast infoga att jag inte är speciellt bevandrad i idéhistoria så det behöver ju inte nödvändigtvis vara han själv som är upphovsmannen, men för mig var det en ”ögon-öppnare”. Till dess hade jag mest fått höra för och mot plan- och marknadsekonomiska system och mest insett att det hela är en fråga om mänskliga värderingar. Så som min vän formulerade det så kan ett samhälle värderas utifrån hur mycket samarbete respektive motarbete som finns inom samhällsstrukturerna. Sålunda kan man exempelvis säga att marknadsekonomins tendens till att skapa konkurrens är dess svaghet. Det är ett resursslöseri att motarbeta varandra på det viset. Samtidigt kan man i planekonomin se att korruption är en typ av motarbete där en person inte ser till samhällets bästa utan sätter sin egen privata ekonomi först.

Jag ser klara paralleller till hur olika utvecklingsmetoder kan bedömas. Det har blivit mycket populärt att prata om projekt som agila (lättrörliga) kontra traditionella a’la vattenfall. Kanske är det ännu mer intressant att bedöma dem efter hur mycket samarbete respektive motarbete de stipulerar?

Inom lättrörliga metoder ligger stor fokus på att kommunicera väl och på ett begripligt vis (informell verbal kommunikation, enhetliga språk där kundens egna termer används och koncisa dokument där de behövs), traditionella metoder har en artefakttyngd värdering där, lite hårddraget, inget finns som inte är dokumenterat i ett godkänt dokument. Här har vi verbal kommunikation mot dokumentation. Den verbala kommunikationen förutsätter samarbete – ni måste finnas på samma plats vid samma tidpunkt. Dokumentationen låter det vara öppet. Visserligen finns det inget som hindrar att du skriver ett dokument till någon som står bredvid dig eller att ni t.o.m. skriver det tillsammans, men det är ofta mer frestande att skriva sina dokument ensam och skicka dokument över e-mail och låta den andra parten få läsa dokumentet ”i lugn och ro”.

I traditionella projekt har man en tydlig rollfördelning där man har distinkt olika ansvar. Det finns, projektledare, beställare, utvecklare, arkitekter, testare och ibland även varianter på ovanstående med prefix såsom ”senior” eller ”junior”.

Man hamnar då i situationer där vissa uppenbara brister i organisationen kan vara ”någon annans problem”. Istället för att inse att alla problem som organisationen har är hela organisationens problem.

En av de mest kritiserade vanorna inom lättrörliga utvecklingsmetoder är vanan av att jobba i par om två. Logiken bakom det är att det aldrig finns bara en som kan någonting och att mindre erfarna utvecklare för lära sig en massa praktiska knep av mer erfarna utvecklare. Mot det står givetvis den fördyrande omständigheten att ha två personer som utför samma arbete – till synes utan någon hastighetsökning. Den kritiken är dock inte helt berättigad eftersom kvaliteten på det producerade blir högre och det, annars obligatoriska, efterarbetet med buggrättning begränsas; samtidigt som man har investerat i en försäkring som ger dig möjligheten att, med kort varsel, förlora en projektmedarbetare utan att projektets hastighet rubbas nämnvärt.

Jag har ofta konfronterats med personer som, när de stirrat nederlaget i vitögat, gjort allt för att skjuta över problemet till ett annat bord utan att ha försökt rätta till skadan. Nyligen var det en som försökte skjuta över en hög smuts på mig. Jag frågade honom vad han förväntade sig skulle hända nu när han tog avstånd från problemet i förvissningen om att han inte skulle få skit för det. Svaret var fascinerade frankt: – Ja, alltså, jag förstår att du inte har möjlighet att fixa de här problemen, men jag vill ju ha ryggen fri, så att säga…

Då frågade jag honom om han trodde att någon konstellation på företaget tillsammans var kapabla att lösa problemen och, jo det trodde han nog. Jaha, men då är det väl bättre att vi försöker samla den skaran för att se om vi kan komma tillrätta med det hela. Jag påpekade också att det här med att skylla ifrån sig kan han väl vänta med till dess slaget är förlorat, jag menar mitt under ett projekt är det ju mest en form av sabotage. Hans minspel ändrades något och han verkade nästan roat försöka förstå vad jag höll på med.

Jag försökte samarbeta. Kontroversiellt, måhända, men vansinnigt effektivt. Tyvärr kan jag inte säga att problemen är lösta än, men nu jobbar man i alla fall kreativt på att lösa dem.

Istället för att fundera över vad som är lättrörligt eller inte så kan man ta avstamp i att arbetsmetoder ska främja samarbete. Det kollektiva engagemanget och den kollektiva ansvarskänslan leder till ett produktivt arbetsklimat.