Iterativt, inkrementellt & Testdrivet

Hade idag riskseminarium på jobbet för ett projekt vi gör/ska göra. Vi har redan börjat egentligen, men pga fördröjningar på linan (muda-betonade sådana) så dröjer det ett tag innan vi startar fullt ut.
I alla fall, det är alltid kul att se att de högsta riskerna (nästan) alltid blir:

* Pengarna/tiden tar slut innan all funktionalitet är klar och detta visar sig inte förräns man närman sig slutet
* Testning kommer på slutet och hinns inte med
* Produkten får inte acceptans hos kunden pga olika målbilder/otydliga krav etc.

Det som är bra är att vi har lösningarna: Jobba iterativt & inkrementellt, testdrivet och skriv acceptanstesterna tillsammans med kunden.
Lätt att säga men svårt att göra i praktiken. Ingen säger sig vilja jobba vattenfallsaktigt, men likväl hamnar man ofta där med vissa team. Varför, undrar jag nu, och ännu viktigare, hur undviker man det?

Modelleringsverktyg

Vad är ett högnivåspråk om inte ett modelleringsverktyg? Vi vill modellera ett system i en form som är både läsbar för människor och samtidigt körbar av en dator. Att modellera i alltför hög detaljnivå i något verktyg blir lätt bortkastad tid, därför att förr eller senare måste man ändå implementera sin modell som kod. Därmed inte sagt att all modellering är bortkastad, modellering kan vara jättebra, men det finns sällan anledning att göra det på detaljnivå.

Att modellera på en hög nivå, tex olika delsystem och deras beroenden, kan vara bra för att förmedla bilden till andra och dela upp arbetet mellan olika team. Men att sedan förfina modellen ner på klassnivå känns som rent slöseri. Det är det man har högnivåspråk till!

Inställningen att systemet måste modelleras noggrant "för att bli rätt från början" bygger på uppfattningen att det är krångligt och dyrt att ändra i koden. Det är det inte! Ett väldesignat system är lättarbetat och har man bra tester så känns det tryggt att ändra systemet efter nya krav och funktioner. Så vi kan gott kosta på oss att göra den detaljerade modelleringen i Java istället för något annat verktyg, helt enkelt därför att vid dagens slut så är det källkoden som är viktig, resten är biprodukter.

Ingen designmodell överlever den första kontakten med implementationen!

Titeln är en parafras på den preussiske strategen och generalen Carl von Clausewitz, som sade att "ingen plan överlever den första kontakten med fienden". Han införde även begreppet "krigets friktion". Detta, menade han, är alla de till synes små och triviala saker och händelser som till slut ändrar förutsättningarna i grunden och gör att den ursprungliga planen efter ett tag inte har någon koppling till den verkliga situationen. Den som vinner är därmed inte den som gör den bästa planen, utan den som bäst kan anpassa sig till rådande förhållanden.

Även om mjukvaruutveckling inte är ett krig (vilket vi ska vara tacksamma för) så finns det likheter. I båda aktiviteterna kommer oförutsedda svårigheter att få konsekvenser som vi inte kan förutse. Likaså kommer i båda fallen förutsättningarna (resurser mm) att ändras innan målet är nått. Så att kunna anpassa sig efter rådande förutsättningar är A & O. Det är just därför jag tror på den agila metodikens överlägsenhet över traditionella plandrivna projekt. De senare bygger på att man har en detaljerad plan, och vet man inget annat så förutsätter man att den gäller. Problemet är att ofta kan planen utan uppföljning hamna så långt från verkligheten att det inte går att orientera sig med den längre.

Samma tankesätt verkar gälla för design och implementation. Vad är det som gör det möjligt för kunden att köra sitt system och generera vinst med det? Körbar, vältestad kod.

Vad är det som gör det möjligt för oss utvecklare att låta kundens system ändra sina egenskaper efter ändrade krav eller ändrade förutsättningar, må det vara före eller efter driftsättning?
Välstrukturerad, väldesignad kod.

Vi kan ändra hur mycket som helst i våra designmodeller, systemets beteende kommer inte att ändras för det. Det är i koden vi måste ändra för att generera ett mervärde för systemägaren. Om du inte håller med om att koden är värdefullare än dokumentationen eller modellerna, gör följande tankeexperiment:
Du har två servrar, en med all kod, en med all dokumentation och alla modeller, inga backuper. Det brinner och du kan bara bära ut en server. Vilken väljer du?


För att föregå alla som tror att Agile innebär att man vare sig dokumenterar eller modellerar, så ska man naturligtvis dokumentera sitt system så att andra lättare kan underhålla systemet i framtiden. Bra dokumentation pekar ut för mig vilka ingångar som finns till koden, tex vilka klasser som kan vara lämpliga att börja titta på för att förändra ett visst flöde. När jag väl hittat det ska koden tala för sig själv, annars har man missat något i designen.
Dokumentationen skriver man sedan efter att koden är testad och implementerad, eftersom det då blir så mycket mindre underhållsarbete med den.

Att skapa modeller på en högre nivå än koden för att kunna resonera med andra är naturligtvis också bra, det kan ju bli lite jobbigt att trängas fem personer vid en skärm för att titta på kod. Men man måste hela tiden komma ihåg att man gör det i syfte att få fram körbar, väldesignad kod. Resten är biprodukter, och ju mindre modellering vi kan klara oss med, desto bättre.

CMS på två minuter (bokstavligen) med Comatise och Rails

Pysslade med hemsidan till vårt dagis i helgen och tänkte då göra det lite lättare att lägga till och ändra text utan att behöva gå in och editera i rhtml-filerna. De flesta som kommer att underhålla siten är inte datorvana.
Därför tänkte jag prova Comatose, som är ett lättvikts-cms för Rails. Från att ha installerat pluginen till att ha Comatose uppe och igång tog det inte mer än två minuter. För mig som är relativt ny på Rails så är detta otroligt imponerande.
Letar du efter ett CMS till Rails som pluggar direkt in i din nuvarande applikation på precis de ställen du vill så kan jag varmt rekommendera http://comatose.rubyforge.org/
Funktionaliteten är grundläggande, men det fungerar utmärkt för mindre (och förmodligen större också men det kan jag inte gå i god för) som vill ha ett enkelt CMS utan krången.