torsdag 17 december 2009

"The pit of despair"

Nyligen har vi i vårt team gjort en ansats till att göra mera unit tests. Det är en grym känsla när vi alla verkar få samma "tända glödlampa" över våra huvuden, när insikten om att det här är vad vi borde göra slår oss alla samtidigt. Att vara överrens underlättar ju helt klart.

Men vägen till ett bättre och förändrat arbetssätt är motig. Jag har flera gånger den senaste tiden varit på god väg att ta en liten genväg för att slippa ta den jobbiga vägen över unit tests. Jag vet ju självklart innerst inne att vi inte kan fortsätta koda på utan tester, alla de buggar jag kämpat med är ju ett bevis på att något måste bli bättre. Men ändå kryper den gamla vanan fram ibland och man kommer på sig själv att argumentera för att försvara sitt tillfälliga undantag. "Ja men den HÄR grejen kan jag ju inte testa... den är ju trivial och dessutom svinjobbig att testa!"

Som tur är finns det fler än jag i teamet. Hade det bara varit jag hade min monolog enkelt kunnat låtit logisk och ja själv hade säkert accepterat ursäkten för att tillfälligt undvika från planen. Tillfällena hade nog blivit fler... och ännu fler. Till slut sitter man där igen, inte ett dugg bättre och med samma gamla buggar som välkomnar en på morgonen. Men har man människor runt sig som ifrågasätter undantaget (ja ibland räcker det med en tveksam blick för att fånga samvetet...) så blir det inte så.

Nä, det är bara att bita ihop! Under Dan Norths föreläsning på Öredev pratade han om "the Satir Change Model". Den beskriver ungefär hur vi hanterar förändring och hur vi tar oss vidare. Det är en stegvis process.
Steven Smith beskriver den bra i sin blog.


I stort går det ut på att vi befinner oss i ett nuläge, trygga i det vi kan, det vi är vana vid och vårt beteende, även om det är ett destruktivt beteende. En förändring introduceras och genast föds ett motstånd mot det nya där vi, medvetet eller omedvetet, motarbetar förändringen. Nästa steg är KAOS. I botten av detta kaos finns "the pit of despair". Nu är vi på botten och har svårt att se hur vi ska kunna ro iland förändringen.

Men - låter vi oss komma förbi denna grop väntar integrering och nya insikter, när vi ser hur det nya faktiskt hjälper oss i vårt arbete. Och fullföljer vi integreringen väntar ett nytt nuläge där vi förbättrat oss och vant oss vid nya, mindre destruktiva beteenden.

Tänker jag efter känner jag klart igen mitt eget beteende. Fastän jag var fullt delaktig i initiativet till förändringen har jag gjort motstånd med mina lama ursäkter om att slippa undan. Just nu befinner vårt team sig i gropen och med sprattlande armar försöker vi gräva oss upp. Men att bara inse att det är där vi är hoppas jag är ett bra tecken.

Det är dags att släppa motståndet och låta kaoset styra ett tag.
Snart är vi på väg upp igen. Åtminstone lagom till nästa förändring...

Over and out!

Dagens kodarmusik: Ingen musik, utan lite Hanselminutes med Roy Osherove om Unit Testing.

söndag 13 december 2009

Dags att spela i samma lag!

Min uppfattning om vårt yrke, systemutvecklare, har alltid varit att vi gör mer än att knacka kod. Vi gör mer än att designa mjukvaruarkitekturer. Vi löser behov. Vi utvecklar verksamheten tillsammans med de som arbetar i och med den. Utan dem skulle det inte finnas någon verksamhet, inga behov och inget berättigande för vårt yrkes existens. Tyvärr upplever jag att vi ganska sällan kommer till vår fulla rätt.

Den "färdiga" lösningen på ett fat
Allt för ofta kommer en färdig lösning till oss från användare eller ledning. Det innebär att någon annan än vi har tänkt ut vilket systemstöd som ska finnas och när det måste vara klart. Vi kommer in allt för sent i processen när viktiga beslut redan är fattade som på många sätt inskränker i vår möjlighet att utöva det vi är bäst på - att utveckla IT-stöd. Om vi redan tidigt fanns med i processen kunde vi bättre förstå skäl och bakgrund till det man vill åstadkomma och kanske finna bättre vägar eller ännu bättre lösningar. Men när man får en färdig lösning finns det oftast varken tid eller mandat för att gå tillbaka och riva upp beslut eftersom någon annan ju redan "vet" att det är den enda och bästa vägen. Sen sitter man som utvecklare och knackar ihop något man egentligen inte tror på.

Två månader på IT-kammaren och sen är det klart
Ett annat vanligt scenario är att vi IT-människor får allt för fria händer. Vi tolkar lite tunna uppgifter vi fått för att sedan stänga in oss och designa en lösning som ur vårt perspektiv verkar klockren. Tyvärr slutar det ju ofta med väldigt komplicerade funktioner som användarna inte förstår eller tycker fungerar i deras vardag. De vet inte vad de ville ha, men det som levererades var inte rätt. Lösningen har fått för stort IT-fokus. Fundera en stund över den där dialogen du designade med lite väl "data-nära" termer här och var...

Det här är två ytterligheter, men de pekar båda på samma område där vi allt för ofta brister - samarbete.

Vi måste på ett bättre sätt lyckas använda varandra. De har kunskap om verksamheten och lever i den varje dag. De är beroende av det vi levererar och måste leva med det, varje dag. Vi har kunskap om hur man gör bra IT-stöd, hur man kan samverka med befintliga lösningar och vilka tekniker som är aktuella idag. Var för sig kommer vi till korta, men tillsammans har vi ju en rätt bra laguppställning. Vi täcker ju in alla väsentliga områden! Vore det då inte bättre om vi blev lite mindre DE och lite mera VI?

VI jobbar gemensamt eftersom vi har ett gemensamt mål, en verksamhet som fungerar bra och presterar på topp. Genom att utnyttja våra olika kompetenser och roller på bästa sätt kan vi få mycket bättre effekt och undvika feltolkningar. VI är större än meningslösa motstridigheter, vi bryr oss om vårt gemensamma arbete och vårt gemensamma resultat. Det spelar ingen roll vem eller vad som är skälet till att något inte fungerar eller brister, vi har ett gemensamt ansvar för att få det att fungera.

Det här är några punkter jag tänker arbeta mer för framöver:
  • I varje verksamhetsprojekt få med kunskap om IT och möjliga lösningar tidigt
  • Upprätta en bra dialog tidigt, lyssna - vad är behovet egentligen?
  • Leverera små, körbara, delar av vår lösning regelbundet som vi kan prova gemensamt - på riktigt!
  • Aldrig mer säga "ok, då fattar vi" och försvinna in på kammaren och tok-koda i 3 månader
  • Aldrig mer säga "ja den lösningen blev ju sådär, men det var ju de på X fel, så det är inte mitt problem"
Vi är ett och samma lag. Vi har ett och samma mål.
Så vad är problemet?

Over and out!

Dagens kodarmusik: Europe - New love in town

måndag 7 december 2009

Unit testing success story!

Jag var bara tvungen att skriva en liten glädjepost om mitt första riktiga äventyr med unit testing.
Jag har under de senaste dagarna lagt till några nya funktioner i en grafisk kontroll. Den består i stort av en datagridview med ett antal rader och kolumner. Vissa rader är summor av ovanstående rader, vissa kolumner är summa av radens värden. Alltså, det finns lite relationer raderna och kolumnerna emellan.
I samband med att jag gjorde de nya funktionerna skrev jag i princip om hela kontrollen och dess affärslogik för att göra den mera testbar. Det verkade som en liten lagom prototyp. Och det var det.

För att bara beskriva läget före min unit testing refactoring, såg det ut ungefär så här:

  • Inga unit tests
  • Grafisk kontroll: Specialhantering för alla typer av rader och kolumner, kontroll mot konstanter och vissa magic numbers. Mycket kontroll av inmatade värden och omvandling från string till int.
  • Coordinator: Specialhantering av samma konstanter, 150 rader kod. 
  • Affärsobjekt: Ärvda versioner av riktiga affärsobjekt för att kunna blanda affärsobjekt med rena summeringsrader och kolumner. Konstanter och magiska siffror lite här och där.
  • Acceptanstest: Starta applikationen. Prova funktion 1, funkade inte. Ändra lite. Prova igen. Prova funktion 2, funkar! Prova den tredje funktionen, funkade inte. Ändra. Funkar! Prova lite till. Nu funkar inte funktion 1. Osv osv. Nervöst inför releasen... Buggfix redan första dagen.

Och så efter...

  • 40 unit tests, all green!
  • Grafisk kontroll: Bara hantering av hur cellerna ska se ut, hur de formatteras mm. Hämta värde och skriva värde till och från affärsobjekten sker med en enda enkel metod. 
  • Coordinator: En konstruktor och två properties. Det är allt.
  • Affärsobjekt: GUI wrappers som ibland håller referenser till affärsobjekt, ibland inte. Hel uppsatta för att på bästa sätt stödja GUI programmeringen. Och helt testbara!
  • Acceptanstest: Allt funkar med en gång! Iallafall ser det ut så...
  • Känns grymt bra inför releasen!
Med andra ord, att skriva unit tests för min lilla funktionsändring gjorde inte bara att jag fick mer förtroende att den fungerar. Det gjorde också lösningen betydligt bättre eftersom en testbar arkitektur helt enkelt är en bra arkitektur. Testbarhet motverkar nämligen "fix-och-trix-lösningar" som jag lätt faller tillbaka till. Tyngdpunkten på funktionerna ligger i affärslogiken. GUI:t hanterar bara grafisk representation.

Sen kan man säga vad man vill om att jag kanske även utan unit tests borde sett att lösningen... ja...sög.
Men det är skit samma nu. Med hjälp av en unit testing utflykt och genom att tänka på testbarheten blev det en självklarhet även för mig.

Att inte skriva unit tests i fortsättningen känns otänkbart. Nu är de här för att stanna, för den känsla jag nu har inför det jag presterat och inför en stundande release är något jag vill vänja mig vid.


Ett litet citat på vägen, som inte alls har med ämnet att göra, men som var så bra. Andy Hunt sa i sitt keynote på Öredev 2007 på temat "Accidental Complexity", dvs saker som är komplext utan att det egentligen finns skäl till det:
XML is like kids. They start of small and cute. Then they grow.

Over and out!

Dagens kodarmusik: Riva - Time is the healer (Armin van Buuren remix)

söndag 6 december 2009

En nybörjares syn på unit testing

EN sådär 10 år efter branschen är jag igång med lite unit testing. I den nya funktion jag nu ska implementera har jag försökt göra så kompletta unit tests som möjligt. Det är inte lätt.
Så här långt in i kampen har jag kommit fram till ett par saker:

Använd mocks - på rätt sätt
En Mock är ett fake-objekt, som man använder istället för den verkliga implementationen. Man ersätter då alla anrop på en verklig klass med anrop på en mock. Du kan då i testet styra vad din mock ska svara på anrop och på det viset skapa en känd omvärld för ditt test. Generellt sett har jag haft mest användning av mock objekt när det gäller de olika skiktens ställföreträdare och inte så mycket när det gäller affärsobjekt. Till exempel är det lättare att göra en fake implementation av en "ProduktManager", som innehåller funktioner för att hämta och spara produkter än för själva klassen "Produkt" i sig.

Men här märker man direkt om arkitekturen är testvänlig eller inte (läs: bra eller inte...). Om det inte är möjligt att byta ut sina "managers" mot andra implementationer är det svårt att använda mocks. Men om alla användare av managern använder ett interface är det enklare. Om man dessutom använder en instance factory eller en IOC containter (här är jag dock på tunn is) gör det hela lösningen ännu mer testbar.

Sen försöker jag dra gränsen för både mocks och omfattningen av test vid ett skikt. Det innebär att man testar ett skikt i taget och det enda som man "mockar" är skiktet under det skikt man just nu testar. (Phew, hur blev det där egentligen?).




Så, för att förklara:
Om jag ska skriva ett test för en coordinator, kommer jag att ge den en eller flera mocks för de managers den använder. På det sättet ger jag den klass jag använder givna förutsättningar. Inget konstigt så långt. Där drar jag gränsen för testet. Repository skikten är aldrig inblandat i testet. Inte heller GUI. Det gör testet mindre, mer fokuserat och enklare att skriva.

Behovet av att använda mocks för andra objekt, som entiteter har jag ännu inte riktigt utrett. Det jag har märkt är att det kan hjälp att skapa enkla metoder för att fylla på de riktiga affärsobjekten med testdata. Men jag använder då i vilket fall det riktiga affärsobjektet. Men vem vet, kanske din hjälpfunktion är en indikation på att du behöver den även i produktionskoden?

Ett sätt att bemästra GUI tester... lite
Hur man testar GUI är ett problem för mig. Men jag har hittat en utväg. Gör GUI:t dummare.

Med en coordinator (som i vårt fall är den GUI pratar med) som levererar så färdig information som möjligt kan man lägga mer kod i den mycket mer testbara coordinatorn. Att tänka på vad som är enklast att hantera för ett GUI, och bygga coordinatorn efter det, gör skillnad.

Funktioner som exempelvis tar in strängvärden kan man evaluera om värdet var giltig integer eller ej i coordinatorn. Sen får GUI:t hantera det som den vill, men problemet kommer inte sprida sig vidare eftersom vi med tester i coordinatorn sett till att alla felaktiga värden hanteras korrekt.

Ett annat bra sätt är att helt ta bort null-problematiken för GUI:t. Låt aldrig coordinatorn returnera null, utan istället en tom lista, tom sträng etc. Kanske är det till och med så att vi borde skapa VårKlass.Empty för att alltid ge tillbaka något. Hur många NullReference problem har man inte fått...

Vid databindning i en DataGridView, använd antingen CellValueNeeded och CellValuePushed som pekar på GetValue(...) i coordinatorn och SetValue(...) i coordinatorn. Eller, vilket oftast är ännu bättre, skapa tillrättalagda, testbara GUI objekt com är gjorda för databindning.

Kontentan är att GUI:t ska vara så dumt som möjligt! Då slipper vi komma på obskyra sätt att testa det med unit tests. Då kan GUI:t testas manuellt utifrån användbarhet och inte för att hitta buggar med vad jag ibland kallar för "Happy testing". Klicka här, klicka där... klicka lite här.... Ja du vet vad jag pratar om.

Håll testerna rena och tydliga
När TDD förespråkarna gav oss utvecklare fribrev vad gäller dokumentation hurrade nog inte bara jag. "Jag skriver kod istället för dokumentation - grymt!". Men då gäller det ju att testerna går att läsa som dokumentation. Här har jag hittat ett par bra tips
  • Låt testerna få tydliga namn, hur långa som helst bara de är tydliga
  • Uttryck testerna som ett krav eller påstående, som SökningPåOkändProduktGerTomLista eller IckeNumerisktVärdeFörAntalPåverkarInteDataOchKastarInteException.
  • Undvik onödiga Asserts i testet. Om du har gjort en assert i ett testfall, gör inte om den i ett annat. Till exempel, du har en funktion som alltid ska returnera resultat och inte null. Säkerställ detta i testet HämtaProdukterReturnerarAlltidEttVärde. I alla andra tester förutsätter man sedan att så är fallet. Inga if != null, inga Assert.IsNotNull, såvida det inte gäller något specifikt för just det nya testet.
  • Skapa hjälpfunktioner i din klass som gör komplexa eller otydliga operationer.
    Jag råkade ut föra att jag i många tester behövde hämta ut ett objekt från en IEnumerable med hjälp av LINQ. Koden blev rätt hårig och var egentligen inte del av testet. Istället för att skapa massa komplex kod i mitt test la jag ut den koden i en hjälpfunktion med enkelt namn. Då ser testet snyggare ut och blir enklare att förstå. Dessutom är det ju inte fel att lägga ett test på hjälpfunktionen också, en gång för alla så att inte heller resultat från den behöver ifrågasättas.
  • Använd alltid möjligheten till att skriva en kommentar till din Assert, alltså en sista inparametern till Assert, inte som en kommentar i koden.
  • Skriv aldrig kommentarer i testkoden. Den ska inte behöva kommenteras.
  • Ta utan att blinka bort tester som heter TestMethod1 eller TestaProdukt mm. Vad gör du när ett sånt test fallerar? Nä, dåligt namngivna tester är faktiskt sämre än inga tester, iallafall ur dokumentationssynpunkt.
  • Låt dina Asserts återspegla vad testet heter, dvs det ska var tydligt att din Assert testar just det som namnet på ditt test säger
  • Klappa dig själv på axeln om du gör ett test med bara EN assert i. Bra gjort!
Med andra ord - ställ samma krav på testkoden, eller högre(!), som på produktionskod vad gäller tydlighet och format.

TDD eller... ?
Precis som med Unit tests är det ju inte direkt ett buzzword längre. TDD ha funnits ett bra tag, men jag har inte lyckats ta det till mig än. Jag tycker Uncle Bob är en riktig hjälte med många bra idéer. Jag skulle gärna vilja känna att TDD är min grej. Du vet väl vad TDD reglerna är?
  • You are not allowed to write any production code unless it is to make a failing unit test pass.
  • You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
  • You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
Mitt förfarande för unit tests är just nu trevande och utforskande. Det består i stort i att koda i mindre sjok för att sedan skriva tester i mindre sjok och så börja om igen. Istället för att känna mig missnöjd över att jag ännu inte kör TDD väljer att se det så här: Nu gör jag tester, det gjorde jag inte förut. Mina kodsvängar är kortare nu och jag tänker hela tiden på testbarheten. Jag är på gång!

Uncle Bob själv sa sig vara lite skeptisk till TDD först, men blev helt såld på det. Jag gillar ett citat han gav angående insikterna efter att ha givit sig hän till TDD, det säger lite av min känsla också.
I can no longer concieve of typing in a big long batch of code hoping it works. I can no longer tolerate ripping a set of modules apart, hoping to reassemble them and get them all working by next Friday.
- Uncle Bob

Over and out!

Dagens  kodarmusik: Supersnälla Silversara - Samla Samla (okej udda, men den är OMÖJLIG att få ur huvudet!!! Prova - jag vill inte lida själv.)


Lite länktips
Know Your Units - Kevlin Henney, Curbralan, UK
Coplien och Martin debaterar TDD, CDD och professionalism
TDD artikel från mästaren själv, Uncle Bob

fredag 27 november 2009

Videos från Öredev

Missa inte chansen att se dessa guldkorn från Öredev!
Scott Hanselman - Information overload and managing the flow
Neal Ford - The Productive Programmer

Och som en bonus, från ett tidigare Öredev,  missa absolut inte
Uncle Bob - The renaissance of craftsmanship

Jag lovar att var och en av dessa är väl värd sina 50 minuter. Garanterat!

Jag vill ha en databas i rött och grönt!

Alltså det här med automatiska tester är ju "old news" vid det här laget. Ja, att automatiska tester finns är ingen nyhet, men användningen av det är fortfarande nytt för många av oss, inte minst mig själv.
Med en kodbas på 100.000-tals rader kod är ett par hundra tester inget vidare facit. Men, nu var det inte det jag funderade på...

Vad jag länge funderat över är hur man testar databasen och DB2 i synnerhet. Det finns ju fina grejer som "Linq to SQL" eller "Visual Studio for Database Developers". Men - det gäller ju allt som oftas SQL Server. Jag har absolut inget emot MSSQL, tvärtom! Men, nu sitter jag inte med Microsoft utan med IBM DB2. Det finns mycket att säga om den, men i vår utvecklingsgrupp har vi efter en del besvärligheter äntligen hittat bra vägar att utveckla mot DB2.

Men att jobba med databaser innebär ju att man, hur man än vänder och vrider på accessen mot den, delar sin applikation i minst två delar. En del kör Stored Procedures med affärslogik (not my flavor...), en del SP's som ersättning mot SQL i koden (smakar bättre) och en del släpper loss med SQL kod blandat med den vanliga källkoden (smakar bäver). O/R mappers eller inte, databasen är en del av applikationen. Att designa och bygga den är en vital del av att bygga applikationen.

Men säg då att man valt SQL i koden, då är väl bara DB:n ett dumt lager? Nä. Det finns fortfarande triggers, referensintegritet, vyer... Så länge man lagt kod i databasen på ett eller anat sätt är det också en del av applikationen och måste på så vis också testas.

Okej. Du har inga triggers och ingen RI (skojar du eller?). Vet du vad, du har fortfarande ett testbehov! Vad händer om du förändrar schemat. Vad händer om du lägger till en kolumn eller byter en datatyp? Vad händer om någon annan gör det utan att du vet om det? Hur testar man att applikationen klarar det? Ofta tror man att "ja, men en sån ändring påverkar ju inte någon annan applikation". Men hur vore det att verkligen veta?

Nog om behovet. Det finns.

Min önskan är att jag skulle kunna lägga mina tester av databasen tillsammans med testerna av den övriga koden. Att få samma inbyggda Visual Studio stöd för mina tester. Att enkelt kunna testa fram om min nya release gör det den ska i databasen och hur bakåtkompatibel  den är.

Att testa att rätt saker händer i databasen
Det här ju egentligen rätt elementärt. Du ser till att databasen ser ut på ett visst sätt, att vissa data finns och att andra inte gör det. Du kör din kod. Du kontrollerar att rätt saker hänt.
Men hur gör man det på ett sätt som låter oss inkorporera det i Visual Studio tester?

Låt oss skapa en struktur av hjälpklasser som representerar databasen vid ett givet tillfälle, ett snapshot. Det rymmer sig extremt mycket information i databasens metadata, så det här kan autogenereras. Egentligen liknar min vision egentligen typade dataset, men med mindre buggar och kanske en aaaning snabbare.

Okej, jag ger mig på ett försök att förklara tanken med lite pseudokod.

Vi tänker oss en tabell med kunder som vi ska testa mot. Vi börjar med att se till att vår testkund inte finns redan.

TableCustomer.DeleteIfExists(12345); 

Varje tabell har ett antal hjälpmetoder, för att skapa, ta bort eller uppdatera rader. Vi känner till metadatan och vilka fält som är nycklar samt vilka som är NOT NULL. Det gör att vi kan skapa alla möjliga operationer mot databasen automatiskt. Särskilt mycket nytta får vi av de som arbetar mot primärnyckeln (som givetvis INTE behöver vara ett RowId, utan kan vara sammansatt)

När vi väl tagit bort kunden, kan vi köra vår riktiga kod. I detta fall ett anrop på en SP som skapar en kund.

// Detta är produktionskoden, ett anrop på en stored procedure
CustomerProxy.SaveCustomer(12345, "Test Customer", "West street 25", "Waynesburg, PA");

TableCustomer.Row row = TableCustomer.GetByPrimary(12345);
Assert.IsNotNull(row);
Assert.AreEqual(12345, row.CustomerId);
Assert.AreEqual("West street 25", row.StreetAdress);
Assert.AreEqual("Waynesburg, PA", row.CityAdress);


För de av er som ifrågasätter min simpla och uppenbart sunkiga datamodell - grattis! Ni lider av samma skada som jag. Men det är inte det viktiga. På ett enkelt sätt har vi testat att databasen ser ut som vi tänkte oss.Dessutom har vi gjort det med unit tests och testmöjligheterna är autogenererade.

Men vi har ytterligare en vinst: Vi märker när schemat ändras. Om någon skapar nya fält som krävs av kundtabellen kommer vår snapshot inte att fungera. Vår SP kommer inte heller fungera.

Om vi autoskapar vår snapshot varje natt i samband med det nattliga bygget kan vi få med alla de ändringar som skett i databasen. På det sättet kan vårt snapshot hänga med i förändringarna. Då blir det rätt uppenbart om någon ändrat någonting som påverkar våra tester. Efter vårt bygge kör vi ju givetvis vårt stora testpaket och hittar då en eller flera röda "pluppar" i testprotokollet.

Inte nog med det! Om vi inkluderar vårt snapshot med vår release som just nu ligger i produktion så vet vi vad applikationen förväntar sig av databasen. Det gör ju att testerna av releasen direkt smäller om någon släppt en "helt ofarlig ändring". Detta eftersom vi givetvis inte genererar om releasens snapshot utan kör på det den förutsatte vid releasetillfället.

Eller, ännu bättre! Om vi istället kör två uppsättningar tester av vår releasekod, en med den gamla snapshoten och en med en helt ny autogenererad snapshot. Då ser vi om vår kod klarar av den nya strukturen. Två sätt att testa samma sak, men ur olika vinkel och på det viset bättre!

Jag vet inte om ni har hängt med på hälften av det jag yrat om eller om det ens verkar vettigt. Jag brinner verkligen för det här ämnet och om allt vill sig väl hoppas jag presentera lite exempelkod vad det lider.

Kanske finns det till och med visst stöd i befintliga lösningar därute:
http://db2unit.sourceforge.net/
http://www.theserverside.net/discussions/thread.tss?thread_id=23702
http://www.anydbtest.com/

Vad som än finns i dessa lösningar, är själva idén något jag tror starkt på!

Phew! Dags att släppa vilda databastester för ett tag och ta helg!

Over and out!

Dagend kodarmusik: C-Quence - Endorphine (Original mix edit)

torsdag 26 november 2009

We are the Commitments!

Ja jag har inte ens sett den där "Commitments" rullen, men begreppet "Commitment" har jag funderat kring en del.

Att göra ett commitment är att förbinda sig, att förpliktiga sig att göra någonting. Att ställa upp helhjärtat för något och ingå en överenskommelse. Det här är ju en grundbult i all form av planering. Att kunna räkna med vad jag förväntas göra och att jag vet vad jag kan förvänta mig av andra.

Vissa personer är svårare än andra att få ett "commitment" från. Titta bara på hantverkare. Hur många av oss har inte fått "om en vecka" eller "i början av nästa månad" i ansiktet om vi frågat om den snälle rörmokaren/elektrikern/snickaren om han kanske eventuellt möjligen kommer snart?

Jag har mer än en gång raljerat över hur det skulle se ut om vi i IT branschen också gjorde så. För det gör vi väl inte? Vi säger väl alltid en fast tid och levererar väl alltid till den tiden? Vi kan väl enkelt räkna ut hur lång tid en funktion tar att införa? Tyvärr är det ju inte så. Jag tror att det till stor del på brister i våra commitments.

Dela upp saker i mindre uppgifter
Att få frågan "hinner du implementera denna funktionen på 3 veckor?" är oftast inte lätt att svara på. Tyvärr brukar jag lite väl snabbt göra ett överslag för att kunna svara "ja" direkt. Man vill ju inte sätta käppar i hjulen för en redan satt deadline och visst fixar man det där? Men en uppgift som tar 3 veckor att göra innehåller ju en hel del detaljer. Därför tycker jag att vi borde vara mer försiktiga med våra commitments och ta med oss en sådan fråga in på kammaren. Där delar man upp uppgiften i hanterbara delar som var för sig blir enklare att planera. Låt vara att det tar ett tag, men när man kommer tillbaka med sitt svar blir det mer säkert. Dessutom kan det självfallet också bli så att man svarar "ja, del 1,2 och 3 hinner jag. Men del 4 kommer inte finnas med". Då får beställaren bestämma sig för att tilldela mer resurser eller acceptera bortfallet.

Detta är en av delarna i Scrum som jag gillar skarpt. Att man avsätter tid i början av varje sprint för att planera, bryta ner och definiera vad man kommer hinna med. Att man faktiskt gräver ner sig lite i början för att kunna ge ett bättre commitment. Sen kan det ju finnas osäkra punkter man dyker på, men då är det ju ypperliga saker att börja med.

Daily scrum
Som jag skrev i ett tidigare inlägg är det här med "daily scrums" något jag tror starkt på. Vi har i teamet kommit överrens om vissa saker, vad som ska göras och när det kommer att vara klart. Att varje dag följa upp hur det går är att respektera våra gemensamma commitments. Då märker man tydligt om någon faller efter eller har svårt att klara sitt commitment. Eller förresten, det är ju hela teamet  som gjort ett commitment och de har vi ju alla intresse av att klara av! Att inte följa upp varje dag blir att kasta en överrenskommelse i ett svart hål och sedan få reda på vad som kom ur det där hålet. Jaha, det blev en sån!

Tydlighet i uppdrag och commitments
Ska vi kunna ge bra besked till våra beställare måste vi vara tydliga mot varandra, både som uppdragsgivare och som den som utför uppdraget. Allt för ofta pratar vi i lösa termer som "när du har tid" eller "ja, när du känner dig klar med A, kanske du kan titta på B?" Vad är det egentligen man har förbundit sig till i ett sådant läge? Ingenting! Vad kan beställaren förutsätta att du gör? Dito! Lägg till detta att man inte kommunicerar läget på sina commitments dagligen och vilken planering har du?

Det skulle kännas så mycket bättre om jag själv var säker på vad olika kravställare förväntar sig av mig och att jag har varit tydlig med vad jag kommer leverera. Då behöver man inte lägga onödig energi på spekulation, besvikelse eller frustration. Iallafall inte beroende på sina och andras commitments.

Efter att ha skrivit detta inlägg började jag googla lite och hittade ett mycket intressant dokument som beskrev hur agila metoder motverkar teamets problematik. Ett av dessa problem var just "Lack of commitments". Läs gärna How agile practices adress the five dysfunctions of a team!

Over and out!

Dagens kodarmusik: Darude - In The Darkness

torsdag 19 november 2009

Hjälp! Vi har fått en vatten(fall)skada!

Med hjälp av en konsult och en kollega har jag just insett någonting. Vi är skadade. Eller, i bästa fall är det inte du och jag, utan bara en stor del av vår omgivning som är skadad. Det handlar inte om en fysisk skada eller svininfluensa, det handlar om tydliga symtom av vattenfall-skada.

Denna skada skapar en icke-kreativ miljö, en stel miljö som har svårt att hantera förändring och initiativ. Den gör att kreativa människor resignerar och riskerar att idéer släcks innan de ens provats.

Var ska vi börja nysta i det här då? Varför inte hos vår gamle vän Wikipedia..
Vattenfallsmodellen är ett sätt att driva ett projekt, till exempel ett större administrativt datasystem. Tanken är att varje steg ska vara helt klart och bedömas innan man går vidare i nästa steg. Vattenfallsmetoden är mer än 30 år gammal.

Just det, jag talar om det vattenfallet, den modellen.

Men okej, vad är nytt i insikten om att vattenfallsmodellen inte fungerar? Ingenting såklart. Vi kan till och med lämna hela argumentationen mot vattenfallsmodellen i systemutvecklingsprojekt därhän. Det jag insett går mycket djupare. Det finns nämligen en så djupt rotad vattenfalls-kultur att det återkommer långt utanför systemutvecklingsprojekten.

Har du någonsin fått en kreativ idé, kanske på jobbet, som kännts rätt smart, ganska självklar och riktigt logisk? Du lade fram din idé med en entusiasm man bara finner hos kreativa människor som just satt igång att skapa. Du fick kanske medhåll om att idén var bra och att det verkligen vore något att ta tag i. Man kanske till och med sa "Bra gjort, kör igång direkt så får vi se hur det går!"?
Då är du lycklig! Jag tror till och med att du är ovanlig.

I allt för många fall skulle din idé försvinna i det allmänna bruset. Men i de fall jag nu tänker på tas din idé om hand efter ett tag. Det tillsätts en utredning där du troligen inte är med, som pågår allt för länge. Det väcker frustration och din idé tappar sitt driv. I andra fall presenterar du en kanon-lösning där du knäckt ett gammalt problem med en riktig innovation. Istället för understöd (och kanske din förväntade ovation) får du avvaktande reaktioner, eftersom ingen vågar tro på dig och din idé. De vet ju inte hur det slutar, de har ju inte analyserat den...

Varför blir det så? Det finns säkert många anledningar, men det här är min teori: Det finns en så utbredd vattenfalls-mentalitet hos många människor där man vill veta allting på förhand inte vågar chansa med ett osäkert kort. Det finns ett behov av att utreda varje hörn, specificera och analysera alla delar av lösningen. Sen kan det bli tal om att dra igång. Den entusiasm man kände för sin idé, det engagemang man lagt ner i den försvinner. Dessutom kanske inte den den idé man hade ens är aktuell längre i dess ursprungliga form. Omgivningen har ändrats, du har ändrats och fått en förfinad, kanske ännu bättre idé. Är ni med på vart vi är på väg?

Om vi inför varje förändring ska analysera varje detalj kommer vi aldrig kunna hänga med. Då har vi analyserat klart lagom tills nästa förändring dyker upp. Vi blir som en dålig skidåkare i en svart puckelpist, precis när man tror man fattat dyker nästa skräckinjagande puckel upp...Dessutom kommer allt för många vara upptagna med att analysera och allt för få med att skapa nya innovationer.

Om vi tillät oss att ta språnget tidigare, att våga lita på vår och andras entusiasm skulle mycket vara vunnet. Då skulle vi vårda innovation, kreativitiet och ambition. Det driver utvecklingen framåt och föder innovatörer. Låt gå att vi inte vet exakt hur allting kommer bli, men låt oss starta med det vi vet. En person vi litar på har en "gut-feeling", så kör! Vi lär oss på vägen och tids nog ser vi om vi behöver justera riktiningen, byta spår eller stanna upp.

Jag förespråkar inte att vara ansvarslös, givetvis måste man veta riktningen och målet för att kunna ta sig vidare. Men vad jag efterfrågar är en flexibilitet att ta små steg och att våga ta dem utan att helt ha koll på vart vägen leder. Min 4-åriga dotter kommer ofta på förslag om tokiga pyssel vi ska göra därhemma. Allt för ofta blir det ett nej, eftersom jag redan funderat ut vad som eventuellt kommer inträffa och hur stökigt det kommer att bli. Men om jag vore mera villig att ta en rätt ofarlig risk, kanske jag får chansen att vara med när min dotter lär sig något, utvecklas eller bara får en mysig stund med total uppmärksamhet. Okej, liknelsen mellan projekt och idéer på kontoret och barnens pyssel är kanske lite svag, men tänk efter... innovation och uppfinningsrikedom kanske hör ihop med barnslig nyfikenhet?

Jag tror inte att någon idag vill påstå att man utvecklar eller arbetar efter vattenfallsmodellen. På frågan om verksamhetens spelsystem är det väl ingen som med gott samvete säger "Vi kör en rak vattenfallare med en projektledare på topp!". Då låter det ju bättre att namedroppa lite "iterativt", "agilt" eller "scrum" istället.

I ett program med en av mina husgudar: "Arga snickaren" var det ett innertak med vattenskador. Personen som ägde huset hade funderat på att måla över fläckarna för att slippa se skiten. Arga Anders sa något i stil med "Ja det kan du ju göra, men om två månader ser det likadant ut igen".

Så länge som vår inställning är vattenfalls-skadad spelar det ingen roll hur agil/iterativ/inkrementell vår systemutveckling är eller sägs vara. Så länge som vi inte främjar människor och deras kreativitet är allt det där bara puts på ytan.

Tack till två herrar Olausson som väckte denna nya insikt.

Dagens kodarmusik: Linkin Park - Crawling.

tisdag 17 november 2009

Utnyttja rädslan för att göra bort sig - på rätt sätt.

"Nothing motivates like the fear of appearing to be an idiot."
Tyler Jennings, Öredev 2009

Vid första anblick låter det kanske negativt, men om man funderar lite mer kan det ju användas på bra sätt.

Visst händer det att man gör saker som inte är prioriterade, kanske för att de är roligare eller för att man fått påtryckningar utifrån. Det händer ju också ibland att man allt för länge ältat ett problem men tjurskalligt gett sig fan på att lösa det på ett visst sätt. Eller varför inte när man underskattat uppgiften men inte vill erkänna att man tidsupskattat fel. Till slut blir det en dålig vana och sen sitter man där, sönderstressad för att klara de uppgifter som egentligen skulle göras på den tid man ursprungligen hade.

Allt det där kan ju fortgå om man får sitta helt ifred utan ifrågasättande. Dag efter dag, vecka efter vecka sitter vi där med en sporadisk fråga om hur det går. När det närmar sig release blir det extra kaotiskt och stressat, men så ska det väl vara? Visst blir det lite sisådär med kvaliteten, men mjukvara är ju komplext, eller hur? Nä. Så ska det inte vara. Det är bara destruktivt.

Men, tänk om man fick frågan varje dag, fast mera tillspetsad med

1. Vad gjorde du igår?
2. Vad ska du göra idag?
3. Finns det något som hindrar ditt arbete?

Detta är frågorna man får varje dag med "the daily scrum". Att träffas såhär varje dag tycker jag verkar extremt lovande. Det förhindrar ju att man

- Sitter med ett problem som någon annan har lösningen på, dvs inte frågar när man borde
- Sitter med uppgifter som inte ingår i det prioriterade arbetet, för att man blivit störd med ovidkommande eller för att man helt enkelt gjort något "roligare"
- Stångar sig blodig på sin lösning utan att någon ifrågasätter den
- Inser att man inte kommer hinna i tid men frågar ingen så...

Som utvecklare ska man inte se det som ett hot, utan som en möjlighet att bli av med de hinder man eventuellt har för att klara sina uppgiter. Eller som ett tillfälle att hjälpa andra att komma vidare. Allt för att bli bättre, och effektivare. Och om inte det funkar för dig, du vill väl undvika att verka vara en idiot, eller hur?

måndag 16 november 2009

Samtal jag behöver färre av

Genom att kommunicera med andra lär vi oss saker, producerar vi saker och skapar effektiva samarbete.
Samtal med andra är ju alltid lika produktivt... eller?

Det finns de samtal, både på jobbet och privat, som verkligen motarbetar allt vad produktivitet innebär. Jag funderade lite kring det där och kom på ett antal scenarier som jag ska jobba med för att hantera bättre framöver.

Samtal med någon som är på väg därifrån
Har du någon gång haft en känsla av att den du pratar med bara vill avsluta samtalet? Du vet, när han eller hon blir mer och mer forcerad i sina svar med ena foten bokstavligen utanför dörren? Det har jag. Jag har inget problem med att just mitt ärende har lägre prioritet än något annat, men jag har problem med när någon, utan engagemang, inleder samtalet. Handlar det då om ett ärende jag känner engagemang för kommer jag troligen avbryta det jag håller på med för att på bästa sätt bidra till diskussionen.
Efter hand inser man att den investerade energin just slösats bort. Personen egentligen inte har tid med den diskussion, som han eller hon just startade... jag har tappat mitt fokus och när personen gått behöver jag inte bara återfokusera utan också svälja stoltheten och frustrationen över att just ha dragit en utläggning till "void".

Framöver tänker jag försöka på förhand göra klart om personen har tid att snacka om ämnet en stund eller inte. Om inte-  inget engagemang, inget fokustapp, ingen förnedring. Vad man kan önska från motparten är att inleda med "Du, kort bara, jag är på väg till X och undrar bara hur det ligger till med Y?".

Samtal när man själv är på väg därifrån
Ok. Jag är inte perfekt. Ovanstående exempel drabbar ju även mig i det omvända. Man triggar igång någon som man inte var beredd på och så står man där som ett fån och lyssnar fastän man för längesedan antingen blivit A - ointresserad eller B - känner att det tar för lång tid. Är svaret A, så är samvetet styrande. Här berättar ju någon något som är intressant för honom eller henne, men inte för mig. Är det en polare, och läget är rätt, kan man ju alltid avbryta med ett "Boooring", men oftast är det någon mindre välkänd. Då blir det till att lyssna helt enkelt.  Är svaret B, kan man ju alltid be att få återkomma eller boka en tid för ett "riktigt" samtal om saken.

Nu kanske vi gränsar till något djupare mer medmänskligt... Alla samtal syftar ju inte till att gagna båda, utan för att den som håller utläggning helt enkelt behöver prata av sig och min fråga gav ett välbehövligt tillfälle. Tänker man mer på det viset är det bara att lyssna, engagera sig och känna att man gjort något för någon annan. Men om någon på gång på gång suger in en i sitt nät och "pratar av sig" blir ju oftast tendensen att man går i större och större cirklar runt denne.

Bekräftelsesamtal förklädda till diskussioner
Det finns de som gärna vill ha en diskussion om något och på ytan verkar vara uppriktigt intresserad av min åsikt. Egentligen är personen bara ute efter att bekräfta en redan cementerad uppfattning. Man är egentligen inte beredd att diskutera men vill ändå ge skenet av att man är öppen för input. Kanske tänkte denne cementerade åsiktsbärare att åsikten var så självklar att det inte kunde finnas någon annan syn på saken?

Provokation är underskattat ibland. Här finns det verkligen utrymme för lite klädsam provokation. Om man misstänker att det finns en gjuten åsikt kan man ju alltid påstå något i den helt motsatta riktningen bara för att se vad som händer! Antingen avbryts samtalet och man slösar inte bort en massa onödig tid och frustration. Eller, beroende på graden av provokation, kan det sluta i skratt. Risken finns ju också att stämningen blir lite tryckt, men den får man ta... Inte särskilt produktivt, men kanske gör det att personen i fråga inte frågar mig nästa gång det blir aktuellt att polera sitt ego. Kanske sådde jag till och med ett frö av osäkerhet som tvingar fram lite mera eftertanke.

Samtal smittade med "Jag-vet-bättre-än-du-lilla-vän-syndromet"
Detta syndrom drabbar de "experter" som ställer frågor som de "vet" svaret på, men ändå frågar för att sedan kunna förklara vad som är fel i det svar man ger. Är ni med?
Exempel: Svärmor/mamma frågar "Om barnet gråter i sängen efter läggning, tar ni upp det då?". Svarar man då "Ja" så går man i en taffligt preparerad fälla och en lektion följer. Om jag detekterar att jag är på väg i fällan brukar jag återigen prova lite klädsam provokation och svara "Ja, det är klart. Vill barnet upp är det väl klart att man tar upp det! Då får barnet komma upp och får lite godis". Ja det där sista kanske är bordeline spydigt, men att försöka kläda in sina lektioner i fina frågor är ju rätt lågt det med...

Samtal eftersom det är lättare än att tänka efter
Vissa personer tar allt för lätt till frågan, kanske under devisen "en vanlig fråga får man tåla...". Att få en fråga en gång eller två är ju okej, men om samma person ställer samma fråga gång blir det lätt störigt. Det är precis som att vissa människor inte sparar något i databasen utan använder andra människor som sin databas. Själva är dom en "tunn klient" någonstans med ganska begränsad hårddisk... för att dra en nördig analogi. Visst kan det kännas bra att vara en viktig kugge som människor frågar ofta, men varje fråga skapar ett engagemang som stjäl tid och energi. Kan jag med mitt svar göra den som frågar mera självständig - kanon! Men att bli databas för en massa klienter är... inte fullt lika kanon. När jag blir tillfrågad nästa gång ska jag försöka ge ett engagemang som just syftar till att slippa frågan nästa gång, inte genom att vara otrevlig utan genom att försöka svara bra. Men det är klart, om det inte hjälper och frågan återkommer gång på gång kanske det finns fog för bara lite spydighet. Lite bara?

Ett annat exempel, där jag själv lätt faller in, är att fråga som första steg i tankeprocessen. Som att man behöver någon annan som startar upp den egna hjärnan. Ofta sitter man inför en ny design av en systemlösning och med en gång börjar man fråga bordsgrannen: "Du, vad tror du om det här...". Egentligen borde jag själv tänka igenom problemet översiktligt och sedan planera in en kort eller lång session med bordsgrannen. Det kräver ganska liten ansträngning, men dåliga vanor och lättja gör att jag själv ofta gör så här. Dels färgas mina initiala tankar av den jag frågat, dels startar jag en helt oförberedd diskussion som stör bordsgrannen i sitt arbete. Varje liten förberedelse är bättre än ingen... här ska jag bli bättre!

Vad vill jag egentligen med det här långa inlägget?
Okej, jag kanske låter lite bitter och en aning cynisk i mina amatörmässiga socialvetenskapliga analyser. Men min poäng är att vi borde vara ärligare och mer medvetna när vi pratar med andra. Det här handlar om en respekt för varandra och varandras tid. Att engagera någon utan förberedelse eller utan eget engagemang är inte respekt. Att fråga någon fastän man egentligen inte bryr sig om svaret är inte respekt. Att inte känna efter ifall motparten är intresserad utan bara köra på är inte respekt. Det är bara slöseri med tid och människor helt enkelt.

Vilka samtal behöver jag fler av då? Enkelt. De som gör mig glad!

Over and out!

Dagens kodarmusik: Ingen. Min son sover och jag vill för allt i världen inte väcka honom.

söndag 15 november 2009

Lästips på ämnet effektivitet!

Apropå Dan North och hans diskussion kring "efficiency" vs "effectiveness".
Läs Dans senaste bloggpost (12/11) om en dam i en taxi!

[Dagens kodarmusik: Lange - Out of the sky]

måndag 9 november 2009

Butiken är stängd för Fokustid!

I helgen har jag arbetat en del hemifrån. Vi har en release som redan nu är försenad, men som bara måste fram till nästa vecka. Eftersom jag varit själv hemma med mina två barn, den ena en 2-åring med halsfluss, har förutsättningarna inte varit optimala...


Men ändå blir de få timmar jag lagt på hemmaplan 100% mer effektiva än de timmar jag lägger när jag är på kontoret. Till och med när jag jobbat med min son i knäet, med "Dora Utforskaren" på ena halvan av min skärm och Visual Studio på andra halvan har jag lyckats dräpa en massa gamla surdegar som varit kvar.


Även om jag känner mig nöjd med min insats ställer jag mig frågan om varför jag inte kan vara lika effektiv på kontoret. När jag stängde laptopen vid midnatt på lördagskvällen började en idé snurra i min skalle - fokustid.


Jag tror mycket på idén om att begränsa våra kanaler till när det passar oss. Jag har under en tid försökt att begränsa telefonvägen genom att vidarekoppla telefonen och mailvägen genom att bara läsa av mailen vid vissa tider. Men det återstår en viktig kanal -muntlig kommunikation, dvs när någon bara kommer in och börjar prata. Nu föreslår jag inte att vi utvecklare  helt stänger in oss i en grotta, dricket Jolt och aldrig pratar med någon. Nej, vi ska helt enkelt styra när vi öppnar kommunikationen mot omvärlden. 


Hur gör vi det då? Jag tänker mig att vi inför fokustid, tid när vi bara fokuserar på det vi tänkt göra och inget annat. Då får ingen störa, vi svarar inte i telefon eller på mail (såvida det jobb vi för stunden tänkte göra inte är att just ringa eller maila...). 
Givetvis måste akuta saker komma igenom, men hur mycket är egentligen så akut? 
Hur lång fokustid vi har är givetvis individuellt. Kanske är det pomodoro teknikens 25 minuter, kanske är det mer.


I mitt fall tänker jag börja med en målsättning om att minst halva dagen ska vara fokustid, dvs fyra timmar. Dessa tänkte jag som första test dela upp i två pass om två timmar. Under dessa två timmar tänker jag råfokusera! Jag tänker dra på ett par lurar, lyssna på lite jobbar-trance (funkar bäst för mig) och stänga dörren till kontoret. Då betar jag av det jag planerat att göra.


När fokustiden är slut öppnar jag kanalerna igen och kommer upp till ytan igen. Jag tror att folk kommer förstå så länge som man är tydlig med vad man planerar. Man kan inte heller ha fokustid under hela dagen eftersom kommunikation med andra ingår. Så länge som de vet att man återkommer inom två timmar är det väldigt få situationer som jag kan tänka mig där det är så akut att det inte kan vänta. Det här handlar ju lika mycket om att kunna värdera vad som är akut och inte. Även om användare ofta uttrycker sig i form av "bråttom" eller "akut!" så ändrar de sig lätt när man ifrågasätter litegrann. Det visar sig att det är okej att vänta ett par timmar, en dag eller kanske en vecka! Alla som skriker "jag brinner!" gör faktiskt inte det...


Nu är min fokustid-metod inte testad än. Den låter bra på pappret och jag är inte på något vis först med dessa tankar. Scrum och Pomodoro har ju tydliga inslag av det här.  


Jag är trött på det eviga "whack-a-mole" spel som jobbet oftast är.  Jag säger som Rage Against the Machine - "Take the power back!".


Over and out!


[Dagens kodarmusik: Muse - MK Ultra]

söndag 8 november 2009

Mitt första inlägg någonsin...(eller Tack Öredev!)

Tack Öredev!


Efter att ha kommit tillbaka från den fantastiska utvecklarkonferensen Öredev i Malmö är jag full av nyfunnen inspiration. Talare och underhållare som Scott Hanselman, Dan North och Ze Frank lyckades verkligen få igång mitt tankemaskineri!


Temat för årets Öredev var effektivitet. Ett rätt utslitet ord, men ju mer jag hörde från olika talare finns det en helt del sunt förnuft i deras tankar.


Scott Hanselman pratade bland annat om att kunna välja vilka kanaler man har öppna och begränsa frlödet i dessa kanaler. Han pratade en del om hur man organiserar sin mailkorg och definierar automatiska regler för att låta de viktiga mailen stå ut och de mindre viktiga bli något man läser när (och om) man får tid och lust. Att skapa en regel för alla mail där man står som "kopia" är ett extremt bra tips! Den som sätter mig som kopia/CC får helt enkelt vara beredd på att det är ett mail jag kanske inte läser! Klockrent! Ett annat var att separera de interna mailen från de externa. Nyhetsbrev och annat sorteras till sin egen mapp.


Ett mera kontroversiellt tips från Scott var att låta mailklienten vara stängd fram till på förmiddagen/lunchen. Att hela tiden få popups som meddelar om ett nytt mail stör! Vi måste välja när vår mailkanal är öppen.


Scott, min nya hjälte, hade också tipset om att på sin telefonsvarare tala in "Hej! Det här är inte sättet att nå mig, skicka ett mail istället!". Att på detta sätt kanalisera sin information till ett flöde, istället för flera, känns också som en bra idé!


Om Scott Hanselman är min hjälte, är Dan North min nya mentor.
Jag lyssnade på flera av hans föredrag och han är helt lysande. Bland annat hade han en session om "Our obsession with efiiciency". Det handlade bland annat om skillanden mellan "efficiency" och "effectiveness". Jag har lite svårt med att hitta bra översättningar till svenska. Men att vara "efficient" kan sägas vara att göra rätt saker, medan "effectiveness" är att göra saker rätt. Han hade bland annat ett exempel om hur man mäter allt i spenderad tid för att bevisa sin effektivitet, ett rätt korkat sätt. "Ja du hade 4 timmar på dig att göra den här uppgiften, du har gjort 2 av dessa och är således halvvägs färdig nu". Dan drog liknelsen med en bil. Om man vet att bilen drar 1 liter milen och tankar fullt (50 liter) så vet man att den har gått 25 mil när tanken är halvtom. Det säger ju dock inget om att man kanske ställt bilen på tomgång en halv dag och bränt 25 liter på det istället... Med andra ord - vi måste mäta i vad vi faktiskt presterar och inte hur lång tid prestationen tog. Det tål att tänkas på.


Mot bakgrund av det som dessa fantastiska talare pratat om har jag bestämt mig för att göra en ansats till att bli mera effektiv (översätt till mera "effectiveness") i mitt arbete och i min vardag. Scott Hanselman sa "everyone should have their own blog" och jag tänker ta det rådet. 


Så därför finns nu denna blogg. Kanske läser någon den, kanske gör ingen det. Men just nu skriver jag den bara i självterapeutiskt syfte.


Over and out!


"If you think professionals are expensive, consider what amateurs cost!"

Dan North, Öredev 2009.