JAOO, dag 1: Craftsmanship and Ethics

JAOOs webbplats är på många vis en ganska dålig källa till information. Det är exempelvis svårt, för att inte säga omöjligt, att hitta någon som helst information om vad JAOO står för. "Java Object Orientation" är svaret man kan hitta på enstaka bloggar om man googlar. Jag gissar att man helt enkelt tonar ned denna bit därför att konferensen nu har en bredare publik än vad den förmodligen hade från början. En annan detalj som jag missat, liksom många andra förstagångsbesökare jag pratade med, var att det faktiskt är ett företag, Trifork, som arrangerar konferensen. Trots detta har konferensen väldigt stark "community"-prägel och mottot "for developers by developers" känns faktiskt äkta. Triforks CTO Kresten Krab Thorup inledde konferensen på måndagen med att betona att vad som gör JAOO annorlunda är att det är ett "software company setting up a software conference, not to sell, but to learn themselves".

Den som fick äran att öppna konferensen med en keynote var ingen mindre än Robert C. Martin (alias "Uncle Bob") som talade under rubriken "Clean Code II: Craftsmanship and Ethics". Bob Martin visade sig vara en fartfylld välartikulerad man som gestikulerar med hela kroppen för att engagera publiken och han fick i alla fall mig att bli riktigt inspirerad och engagerad. Faktum är att jag tycker ämnet för hans keynote var så pass intressant att jag ska försöka redogöra för det i detalj.

Efter en effektfull, men kanske något för lång och irrelevant, inledning där han använde Kresten Krab Thorups kropp som material för en historisk exposé över jordens historia och människans lilla del däri, ställde Martin den provocerande frågan: "do we have a profession"? Hans svar var tvekande; under en lång tid gjorde utvecklare lite som de ville, valde sig egen stil. Yrket har inte några regler och riktlinjer, ingen historia med ritualer som till exempel advokater och läkare. Men runt millennieskiftet något hända, vårt hantverk definieras och vi börjar få en historia som vår praxis kan luta sig mot. Det börjar bli möjligt att definiera ett yrke som kan luta sig mot en disciplin snarare än förlita sig på dokumenterade processer. Den disciplin Bob Martin förespråkar är förstås Agile.

För att visa sin hängivenhet till de principer och praktiker som denna disciplin bygger på bär Martin, och numera även många av JAOOs deltagare inklusive undertecknad, ett grönt armband med påminnelsen/uppmaningen "Test first". Men exakt vilka principer och praktiker är det vi talar om?

• Short iterations
  Martin förspråkar en eller två veckors iterationer, fyra är alldeles för lång tid. I slutet av varje iteration ska det finnas exekverbar kod, dokumentation, tester etc. Det ska i princip vara möjligt att leverera mjukvaran varannan vecka.
• Don't wait for definition
  Sitt inte och vänta på att någon annan ska definiera vad som ska göras, utan bidrag själv till definitionsprocessen genom att bygga kod och få feedback.
• Abstract away volatility
  Kod som är en mer trolig kandidat för förändring ska vara på ett ställe och kod som troligtvis inte behöver förändras ska vara på ett annat. "No JavaScript doing business logic in the GUI!"
• Decouple from others
  Koda inte direkt mot andras implementationer, då kan du lätt bli sittande och vänta på att de ska bli klara. Använd stubs, mocks, simulators och så vidare - då berättar du också för andra hur du vill att interfacen ska se ut.
• Never be blocked
  Detta är "The Prime Directive". Martin använde ett exempel med en grupp testare som "inte kunde göra något" eftersom deras testserver inte var konfigurerad. Har inte utvecklarna fungerande mjukvara på sina datorer? Sätt er vid en av dem! Något kan man göra medan man väntar...
• Avoid turgid viscous architectures
  En del arkitektur hindrar mer än den hjälper. Den skapas ofta av arkitekter som vill lösa allting. Ett sätt att komma till rätta med problemet är att låta arkitekterna utveckla: "If architects have to write code they have to live in the mess they've created."
• Incremental improvement
  Koden är obegriplig, svårföränderlig, otestbar o.s.v. Vad gör du? "Admit you have a mess and clean it up! Bit by bit, day by day, slowly clean it up." Gör det till en regel att alltid checka in lite bättre kod än du checkade ut. Vi gör ofta tvärtom - det är inte professionellt.
• No grand redesigns
  Ledningen är aldrig intresserade av detta. "But then the developers begin to bang the drums... And management resigns. Enter the Tiger Team!" De bästa utvecklarna bildar toppteamet som ska bygga det nya fantastiska systemet. "Det gamla systemet" är specifikationen, så hur svårt kan det vara? Samtidigt sitter andra utvecklare kvar och förvaltar och vidareutvecklar systemet i drift. Det blir som Zenons paradox: hur fort Aristoteles än springer måste han alltid först ta sig dit sköldpaddan började med sitt försprång, men då har sköldpaddan hunnit ytterligare en bit och så vidare i all oändlighet...
• Progressive widening
  Pragmatic Programmers kallar det tracing bullets, i XP kallar man det spikes: lägg till en liten feature som går hela vägen uppifrån GUI ned till databasen och fortsätt därifrån. "Add a thin slice, widen it progressively."
• Progressive deepening
  Få den tunna skivan att fungera ett lager i taget. "Make it run, make it work, make it fast."
• Don't write bad code
  Varför skriver man dålig kod? "Vi hade inte tid att skriva bra kod" är ett vanligt svar. Men har man i så fall verkligen tid att hantera konsekvenserna av dålig kod i form av fler defekter, svårare underhåll och så vidare? "Bad code is not something that slows someone else down months from now - it slows you down immediately!" Vad är det vi producerar, vad är vår artefakt? Ett systems beteende? Nej, det är koden som är vår produkt. "If the code is a mess, the product is a mess. Bad code stays forever, dragging the team down, eventually dragging the company down."
• Go fast, go well
  "The only way to go fast is to go well."
• Clean code
  "What is clean code? It is when the code reads in such a way that, as you read it, each line is what you expect it to be."
• Test-Driven Development
  "The jury was out on this one, but now they have come back and it is a best practice." När Bob Martin frågade publiken om de ägnade sig åt testdriven utveckling räcktes ett anmärkningsvärt stort antal händer upp. "All the time?" Något färre händer. Robert Martin använder puristens definition av TDD:
  1. Ingen produktionskod får skrivas innan du har ett test som misslyckas.
  2. Du måste sluta skriva enhetstest när det misslyckas och skriva produktionskod så att det lyckas.
  3. Du får inte skriva mer produktionskod än vad som behövs för att få testet att lyckas.
  Något färre händer kvar efter denna definition.
  Att bedriva TDD på detta vis tvingar oss att ha exekverbar kod hela tiden. "What makes code flexible? The effects of architecture and design are secondary. Tests are what makes code flexible and maintainable."
• QA Should Find Nothing
  Det är i alla fall den inställningen vi bör ha när vi kodar.
• 100% Code Coverage
  Använd ett verktyg som t.ex. NCover för att se till att din code coverage är i närheten av 100% (i närheten räcker eftersom de flesta verktyg aldrig når 100% eftersom de inte räknar in interface).
• Avoid debugging
  Titta på koden och hitta buggen där - koden fungerade ju för två minuter sedan (se TDD ovan).
• Manual Test Scripts Are Immoral
  "Tryck på den knappen, skriv in det och det i inmatningsfälten, kontrollera att resultatet blir XYZ..." Om och om igen. "Could you imagine doing that for a job?! It's immoral!" Låt testarna fokusera på kreativa, utforskande tester.
• Definition of done
  "What is the definition of done? All tests are passing."
• Test through the right interface
  Testa inte via ett grafisk gränssnitt. Om det inte är det grafiska gränssnittet som ska testas och då ska affärslogiken simuleras/stubbas.
• Apprenticeship
  Det bästa sättet att lära sig är att sitta med erfarna utvecklare vecka ut och vecka in. Parprogrammera.
• Use good tools
  Det finns mängder av verktyg där ute, de bästa är ofta Open Source. Varför? "They put care into code."

Ovanstående är hämtat från mina egna minnesanteckningar så vissa citat kanske inte är helt korrekta och möjligen har jag missat ett par punkter. Många av dessa punkter, ja förmodligen alla, är i någon variant kända för de flesta som intresserat sig för agila metoder de senaste åren. Och vissa av de Java-människor jag pratade med tyckte inte det var något att höja på ögonbrynen åt. Kanske beror det på min annorlunda bakgrund (.NET, icke-agila projekt), men jag tycker det var fantastiskt inspirerande att höra en prominent person som Bob Martin med självklarhet, glöd och passion konstatera att "så här är det, så här ska man arbeta - låt ingen intala dig motsatsen". Jag hoppas verkligen att min inspiration ska smitta av sig på andra i de projekt och sammanhang jag deltar i och att jag får tillfälle och möjlighet att tillämpa dessa goda riktlinjer i mitt yrkesutövande. Nu har jag i alla fall ett grönt band som påminner mig. :-) 

JAOO, dag 0: "Leading Agile Retrospectives"

I lördags anlände jag äntligen till Århus efter en smått hektiskt period med en veckas solsemester med kraftigt försenad hemresa, två intensiva arbetsdagar och ett snabbt besök hos vänner i Köpenhamn. För dig som inte besökt Århus kan jag berätta att det är en trevlig liten storstad, en universitetsstad som med ett invånarantal på 300 000 är Danmarks näst största stad. Den är dessutom sedan 1987 säte för konferensen JAOO.

Själva konferensen och dess sessioner började egentligen först på måndagen och slutade i onsdags, men den vetgirige går på tutorials redan dagen innan och avslutar också med tutorials torsdag och fredag. För söndagens tjuvstart hade jag valt "Leading Agile Retrospectives: A Simple, Pragmatic Framework" som leddes av Diana Larsen, en av de människor som förmodligen lett flest agile retrospectives i världen och som tillsammans med Esther Derby författat boken "Agile Retrospectives: Making Good Teams Great!" (Pragmatic Bookshelf, 2006).

Ett retrospektiv är med Larsens och Derbys ord "a special meeting where the team gathers after completing an increment of work to inspect and adapt their methods and teamwork" och som "enable whole-team learning, act as catalysts for change, and generate action". Till skillnad från mer traditionella projektutvärderingar fokuserar ett retrospektiv inte bara på utvecklingsprocessen, utan också på projektgruppen.

Enligt programbeskrivningen skulle vi under denna heldag introduceras i ett enkelt ramverk för retrospektivdesign och få prova på att själva designa ett retrospektiv. Vår 20 personer starka klass blev nästan omedelbart indelade i grupper enligt principen om att "7+-2" är det optimala antalet projektmedlemmar och fick genast i uppgift att simulera ett projekt så att vi skulle ha något att göra ett retrospektiv om. Det simulerade projektet gick ut på att skapa en 3D-modell (!) för "Agile Team Leadership & Management" med fem olika stakeholders: konsulten som ska sälja den, teamet, teammedlemmen, Scrum Master/coach och Functional/Project Manager. Vi hade ungefär en halvtimme på oss och det material som stod till vårt förfogande var huvudsakligen piprensare, post-its, papper, klistermärken, gem, gummiband och tejp. Jag vill faktiskt påstå att vårt team producerade den tydligaste och mest användbara modellen...

Efter denna övning hade vi så ett projekt att utgå i från för att göra ett retrospektiv. Diana Larsen hade redan en färdig design som vi använde oss av. Det började med att hon presenterade agendan och målet med dagens retrospektiv: "Focus on improving the balance and flow between our planning and activities". Sedan fick alla göra en övning hon kallade "Sense of the room" där vi fick skriva ned en känsla (förvirring, tyst, lycklig, engagerad o.s.v.) och ett behov (respekt, kommunikation, vila, utmaning etc.) på olikfärgade lappar. Lapparna samlades in, blandades och lästes upp. Syftet med denna övning var tvåfalt: att få alla att deltaga redan från början och att få en uppfattning om stämningen i teamet. Denna inledning kallas för "Set the stage" i Derbys/Larsens ramverk.

Nästa steg i ramverket är att samla data ("Gather Data"). Den metod Larsen hade valt var att vi var och en under fem minuter på post-its skulle skriva ned observationer från projektet: saker vi iakttog, vad folk gjorde, sådant som stack ut eller andra händelser från projektet. Sedan klistrade vi upp våra lappar under en av fyra kategorier i form av olika ansiktsuttryck som hon förberett på väggen: glad, ledsen, arg, likgiltig. På detta sätt fick vi fram både fakta (lapparna) och reaktioner (kategoriseringen).

Nu var det dags att få fram insikter ("Generate Insights"). För detta använde vi något som kallas inlärningsmatris ("Learning Matrix"). Matrisen har fyra fält för att kategorisera erfarenheter från projektet: "Do same/more", "Do less/stop", "Try/Do differently" och "Appreciation". Vi började med en kort brainstorming för att fylla de olika fälten. Bland annat kom det fram att vi haft kul ("Appreciation"), att vi borde ha brainstormat för att komma på idéer till vår modell ("Do differently") och att vi borde ha jobbat mer iterativt ("Do more"). Därefter fick vi var sin handfull klistermärken med olika valörer (typ 5 cent till 10 dollar) som vi använde för att gradera de idéer vi tyckte det fanns mest "energi" kring i gruppen. De tre idéer som fick det högsta sammanräknade värdet valdes ut för diskussion.

Utifrån de idéer som kom fram kunde vi sedan avgöra vad som borde prövas i nästa iteration ("Decide What to Do"). För att undvika att fastna på första bästa idé, brainstormade vi fram en lista med aktiviteter där vi sedan fick tre röster var för att avgöra vilken eller vilka som var viktigast ("First fit vs Best fit"). Vi valde ut en av våra idéer och fick sedan skapa en "Action Report" för den:

• What is the action?
• Who has the zeal to carry it?
• When will "who" check in with the team?
• Why will this succeed?
• How will we measure success/progress?

Till sist avslutades retrospektivet med en summerering av vad som ska göras så att alla i teamet är införstådda med vad man kommit överens om. Det är också viktigt att tacka alla för ett gott arbete. ("Close the Retrospective")

Detta är förstås bara ett exempel på hur man kan genomföra ett retrospektiv. Det viktiga är att den innehåller alla delar i ramverket:

• Set the Stage
• Gather Data
• Generate Insights
• Decide What to Do
• Close the Retrospective

Vi hann också med att utifrån förberedda scenarier, alltjämt indelade i samma grupper, designa egna retrospektiv utifrån ramverket. Diana Larsens och Esther Derbys bok innehåller en rad olika aktiviteter man kan använda för de olika stegen; vilka man använder handlar dels om tycke och smak, dels om den specifika situation man står inför. Det kan till exempel vara så, som i det scenario min grupp tilldelades, att deltagarna är oroliga för att bli beskyllda för det som gått fel och då är det viktigt att få dem att känna sig trygga och använda aktiviteter där deltagarnas åsikter i stor utsträckning är anonyma.

Dagen avslutades med en "clinic" där vi gick igenom frågor och funderingar kring retrospektiv, dels sådana vi formulerat i början av dagen och klistrat upp på väggen, dels sådana som dykt upp under dagen.

Jag hade väntat mig något mer teori kring ramverket och att få lära mig fler tekniker, men det var bra att få erfarenheten av att praktiskt ha deltagit i och designat ett retrospektiv. Det gör förhoppningsvis att barriären för att testa det i sitt arbetsliv är lättare att komma över och jag vill verkligen försöka få in mer av denna teknik i de projekt jag arbetar med. Det är allt för ofta så att man bara rusar fram längs en kurs man tagit ut tidigt i projektet och aldrig stannar upp och reflekterar över vad man gör och var man är på väg.

Att anlända till JAOO innan majoriteten av deltagarna och att dessutom börja med en handgriplig tutorial med mycket grupparbete var en perfekt mjukstart på konferensen och flera av deltagarna fortsatte att umgås under hela veckan. Man slapp dessutom trängas med alla andra under den stora registreringen på måndagen.

JAOO - her kommer jeg!

Nu har jag anmält mig till konferensen JAOO i Århus, Danmark. JAOO tycks stå för "Java Object-Oriented", men det är nog mycket en historisk kvarleva och konferensens innehåll torde attrahera en vidare krets än namnet antyder. Bland årets spår finns t.ex. LINQ, The .NET Road, Scrum, Web 2.0, Real-World Ruby, Modeling och Agility on the Edge.

Själv ser jag särskilt fram emot den heldagstutorial jag bokat in för fredagen: "Domain Driven Development" med Eric Evans. Andra talare som fångar mitt intresse är Martin Fowler, Michael Feathers och Robert C. Martin, som alla hör till mina absoluta favoritförfattare just nu (mer om deras böcker på denna blogg senare).

Om du ska till JAOO och har lust att ses, hör av dig! Jag kommer att vara där alla sex dagar, från och med söndagen den 23 till och med fredagen den 28 september.

A Low-Tech Approach to Understanding SOA

I våras på Developer Summit deltog jag i en workshop med Thoughtworks Dan North. Rubriken var "SOA for Human Beings" och jag försökte sammanfatta en del av mina intryck här. Utgångspunkten för Dan Norths presentation var de tankar och erfarenheter han tidigare sammanfattat i en artikel för tidningen Better Software Magazines majnummer. Han har nu lagt ut artikeln, "A Low-Tech Approach to Understanding SOA", på sin blogg:

This article presents a simple, technology-agnostic approach to designing and evolving SOAs. You will not see acronyms such as WSDL, SOAP, or REST, and I promise not to use technical terms like “orchestration,” “realization,” and “governance.” Because of this, you will be able to design and implement service-oriented architectures that truly serve your business.

Ladda ned den som PDF eller läs den direkt på webben.