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.