En systemutvecklares självterapi

Badare, skogshuggare och objektorienterade designers

noreply@blogger.com (Per) — Mon, 07 Mar 2011 21:16:00 +0000

Ibland kastas man tillbaka till skolbänken. Inte i bokstavlig mening, som i att gå en kurs, utan bildligen. Ibland blir man påmind om vad man faktiskt lärde sig där bland alla föreläsningar, fikapauser och tentor. Man blir påmind om hur lite man egentligen vet och hur spännande vårt område egentligen är.

Sitter fortfarande med samma avancerade problem som jag bloggade om förra gången. En avancerad urvalsprocess för att välja det bästa alternativet bland många. Jag vet nu vet vad som ska göras och hur det bör gå till men jag hade stora problem med att få lösningen dit jag ville. Jag ritade pilar och boxar, hittade på coola namn som "Manager", "RuleSet" och "Matcher". Problemet jag hade var att det inte kändes objektorienterat. På något vis luktade hela lösningen procedurell kod... Dessutom blev de tester jag skrev krångliga och allt för nyfikna.

Låt oss ta en avstickare och fundera lite över nyfikna tester. De är ett problem. Det är tester som vill veta lite för mycket om klassen som det testar. Istället för att testa inputs och outputs testar de istället hur klassen under test kommer fram till ett resultat. Tänk dig en metod som processar en fil. Den ska givet ett antal villkor ta olika beslut och då och då interagera med andra klasser. Det vi egentligen vill veta är att vår metod uppfyller sitt kontrakt, att den gör det den utger sig att göra. Men ett nyfiket test kollar istället på vilket sätt den interagerar med omvärlden och "tjuvlyssnar" på algoritmens inre logik. Visst, du kanske har snott ihop världens tajtaste algoritm, men jag kan lova dig att det finns någon där ute som kan göra det annorlunda och troligen bättre. Om denne någon fick i uppdrag att modifiera din algortim skulle de nyfikna testerna stå ivägen och bara orsaka svordomar. De skulle faila bara för att man ändrade på algoritmens struktur, fastän det förväntade beteendet var oförändrat. Varje gång vi använder mocks och inte stubs bör vi därför ställa oss frågan: "är jag för nyfiken".

Ok, det var ett sidospår. Jag satt alltså där med en lösning på gång, men med en lukt av gammal unken Pascal.

Återigen ett samtal med en kollega. Återigen en ny syn på saken, men denna gång en sanning jag har kunnat men glömt bort. Frågan han ställde var enkel och förtjänar fet stil i stor font

"Hur skulle det du försöker göra fungera om det gjordes manuellt, i verkligheten?".

En alldeles lysande fråga! Jag tänkte bort alla artificiella saker jag uppfunnit där på min kammare. Jag började förklara flödet och beskrev deltagarna i mitt scenario som personer. Dessa personer hade inga collections eller managers till sin hjälp. De hade böcker, offerter, anteckningar och andra verkliga saker. De interagerade inte med repositories eller factories. De interagerade med andra personer. En skiss dök upp. Pilar fortfarande, men nu streckgubbar och dokument. Regelböcker och arkivmappar.

Det fantastiska med det här var att jag genast fick en objektorienterad lösning. En lösning som modellerade något verkligt och som efterliknade verklig kommunikation och interaktion. Inga Managers, Coordinators eller Services. Helt plötsligt föll sig också kollaboratörernas respektive ansvarsområden och förmågor på plats.

Jag hade helt glömt att objektorientering mår bäst när den modellerar något verkligt. Den mår bäst av att vi inte hittar på massa abstraktioner och flummiga tekniska begrepp. Den mår bäst när vi använder vårt eget språk som vi skulle använda för att beskriva för vem som helst. En snabb tur till Google ger snart denna mening som förtjänar att dammas av: "Software objects are often used to model the real-world objects that you find in everyday life."[källa] Det tål att tänkas på när vi springer iväg med vårt design-pattern-influerade, tekniktörstande ego...

Vad gäller nyfikna tester slapp jag även dem. Eftersom varje klass nu fick ett tydligt ansvar och tydliga metoder blev det enkelt att testa. Om varje klass får ett tydligt kontrakt är det enkelt att sätta förväntningar och se att de infrias av klassen. Jag tror att nyfikna tester är en indikation på att man pysslar med procedurell kod. Det funkar inget vidare. Tydligen gillar TDD objektorienterad kod bättre än Pascal.

Och så till rubriken. Vad har någon som badar eller kör motorsåg gemensamt med den som sysslar med objektorienterad design? Tja, jag gillar ju både bad och motorsågar (kanske inte i kombination...) men jag är inte den gemensamma nämnaren.

Nä, svaret är enkelt: de är alla saker vi inte bör göra ensamma.

Over and out!
[Dagens kodarmusik: Blow - Ke$ha]

Ett par nya ögon och öron kan spela stor roll!

noreply@blogger.com (Per) — Fri, 25 Feb 2011 15:29:00 +0000

Satt häromdagen och slet mitt hår över en riktigt komplex uppgift. Jag ritade klassdiagram, körde lite TDD, skapade en massa interface.... bara för att inse att jag var ute och cyklade fullständigt. Den känslan är inte ny. Den är tvärtom välbekant.

Jag tror det finns en motsvarighet till författarnas "writers block" även inom vårt yrke. Den där känslan man får när man provat alla angreppsvinklar man har och ändå slutar upp i återvändsgränder. Det är tröstlöst. Det är svårt skadande för självförtroendet. Så ger man upp, slår igen laptopen och slänger sig i soffan med bultande huvudvärk och en känsla av hopplöshet.

Men det tar inte slut där. Då kommer natten. Man vänder och vrider sig och försöker lösa problemet lite sådär halvsovande. Jag minns när jag gick på högskolan och vaknade i flummiga tankar i stil med "hur jag än vänder och vrider på kudden så löser jag inte den här labben". För någon utanför vårt yrke tror jag det låter hur galet som helst. Men jag tror att vi alla har varit där någon gång...

Men sen kommer ljuset - ett par nya ögon eller öron. Man drar ihop en eller ett par kollegor och presenterar problemet för dem. Kanske löser man det bara genom att förklara för dem, genom att höra sina egna ord. Eller så är det någon som bara ser. Ser det du inte kunde se. Någon som får den där förlösande upptäckten som gör att min egen hjärna får en välbehövlig defibliratorchock. Som en LP som hakat upp sig som någon knuffar vidare. Det är en grym känsla!

Ibland är man själv den nytänkande motparten, ibland är man den som kört fast. Oavsett situation är de nya ögonen ovärdeliga.

Dessutom tror jag att man måste igenom det där jobbiga för att kunna ta emot de nya ögonen. Man måste gräva ner sig i ett problem och vända det ut och in före man verkligen kan uppskatta en ny dimension och förstå att den har någon värdefullt att ge.

Precis det här hände mitt senaste problem. En oerhört kreativ diskussion med två begåvade kollegor löste många knutar och någon bara såg. Fantastiskt.

Så alla ni som är med i kreativa diskussioner, se ert värde! Även om man inte kommer fram till lösningen just där och då kan era frågor och nya vinklar vara värda guld. Våga säga nåt, våga komma med en fråga eller åsikt, det kan vara just den som är starten till nästa möjlighet!

Over and out!

Dagens kodarmusik: Sara Lumholdt - Enemy

S - och vad det innebär för oss dödliga utvecklare

noreply@blogger.com (Per) — Fri, 11 Feb 2011 13:28:00 +0000

Efter att ha hört Hadi Hariri prata om maintainable code på ett event i Göteborg häromdagen fick jag en sista knuff att ta tag i något jag funderat över ett tag, nämligen SOLID.

SOLID är en akronym av akronymer som myntades av Robert C. Martin (Uncle Bob), en levande legend i utvecklarsamanhang och författaren till den fantastiska boken Clean Code. SOLID står för fem principer:

Single Responsibility
Open/Closed
Liskov substitution
Interface segregation
Dependency Inversion

Dessa begrepp har många gånger förklarats och diskuterats. Bland annat finns det en hel del referenser till bra podcasts om dem i ett av mina gamla blogginlägg.

Man kan då undra vilket värde det finns i att gå igenom dem igen, men jag tänkte för egen del ta tag i att lära mig dem en gång för alla. Hur kan jag applicera dem i mitt vanliga utvecklarliv, som affärssystemsutvecklare? Eftersom jag är ett unit-testing freak vill jag också gräva lite i hur väl de sammanfaller med testbarhet.

Därför börjar vi idag med S - Single Responsibility Principle (SRP) som definieras såhär

There should never be more than one reason for a class to change
(http://www.objectmentor.com/resources/articles/srp.pdf)

En klass ska alltså ha ett enda skäl att ändras. Det klassiska exemplet är en klass "Anställd", som ansvarar för att spara och hämta sig från databasen, räkna ut sin lön och skriva ut en rapport. I ett sånt tillrättalagt exempel är det ju enkelt att se att den har många orsaker att ändra sig. Databasens struktur innebär ändringar. Löneuträkningen innebär ändringar. Rapportformatet innebär ändringar.

Jag tror inte att någon av oss skriver sådana klasser... eller? Ett mer vanligt fenomen är att vi skriver "god-classes", klasser som kan det mesta och lite till. Ett säkert tecken är namnet. När vi känner oss tvungna att lägga på ändelser som "Service", "Manager" eller "Handler" på vår klass ska vi börja fundera. Vad gör vår klass, egentligen?

En annan vanlig sak är att vi smyger in infrastruktur lite här och var, som säkerhet och loggning. Många klasser i systemet loggar via en logger och varje klass kollar att användaren är auktoriserad. Ändrar vi på någon av dessa tekniker åker vi dit igen. Här kan AOP vara en lösning, men det är en helt annan diskussion.

Ett enklare sätt att titta på SRP är att börja på metodnivå och sedan arbeta sig uppåt. SRP gäller nämligen även där! Här är det ännu enklare att detektera "smells", tecken på att vårat S är i fara:

Långa metoder

En metod på 300 rader gör troligen mer än en sak. En metod på 10 rader gör troligen färre saker...

Otydliga metodnamn

DoWork() - gör säkert bra saker, men vad?
UpdateOrInsert() - gör ju åtminstone två saker
CreateAndRegisterItem() - dito
CreateItemIfTotalIsNotTooHigh() - ja, kommentar kanske är överflödig...
Generells sett, undvik if, and och or i metodnamn...

Metoder med bool parametrar för att styra flödet

PrintReport(bool toPrinter) kan ju tydligen skriva ut både till printer och någon annanstans
PrintReport(bool toPrinter, bool includeDeleted) - mera bools, mera permutationer....

Metoder som arbetar på flera abstraktionsnivåer

En metod som läser fil från disk, parsar innehållet och agerar därefter utifrån affärslogik arbetar på flera abstraktionsnivåer och gör definitivt många saker...

Det enklaste sättet att kolla sig själv är att alltid försöka beskriva exakt vad metoden gör med enbart namnet. Kan man inte det med enkelhet så luktar det lång väg...

När man väl förstår metodnivån kan man dra det längre och applicera det på klassnivå. En Parser klass har ett tydligare definierat ansvar än en FileHandler. Så att försöka namnge saker exakt efter vad de gör är gångbart även på klassnivå.

Ett annat tips som Hadi Hariri tog upp i sin session i Göteborg och i sitt eminenta blogginlägg är att byta ut parametrarna i sina metoder mot instansvariabler. Kolla sedan hur många metoder i klassen som använder dessa instansvariabler. Är det få har vi låg cohesion i klassen, dvs metoderna hör inte ihop. Arbetar de inte på någon instansvariabel kommer Resharper att vilja göra metoden static. Både cohesion och static metoder kan vara tecken på att man bör bryta isär till fler klasser.

Det här innebär givetvis att vi kommer få många små klasser med många små metoder. Ett argument mot det kan ju vara att man inte vill hålla reda på så många klasser i sitt projekt. Men väg det mot att få i uppdrag att lösa en bugg i en klass på 1500 rader, eller en metod på 300 rader... Och det där med att hålla reda på löser de flesta utvecklingsmiljöer rätt bra, dessutom med verktyg som Resharper är varje klass bara ett CTRL+T bort... Så glöm det!

Hur påverkar SRP testbarhet?

Att skriva test för en metod med tydlig namn och få rader kod är enkelt.
Att skriva test för en klass med begränsat ansvar innebär troligen färre beroenden och kollaboratörer. Därmed färre saker att isolera i en testmiljö.
Små klasser = små testklasser = samma nytta för underhåll som för produktionskod.

Sammanfattning

Håll koll på namn på metoder och klasser. Är det svårt att komma på = varningslampa!
Håll metoder och klasser korta
Granska klassens cohesion
SRP underlättar testbarhet

Det verkar som om jag kan skriva under på S:et i SOLID. Det är en av de enklare principerna att förstå men kan vara lurigt att implementera. Använd några av teknikerna med namngivning eller instansvariabler till hjälp. Ibland går det inte, men jag tycker att vår ambition är det viktigaste. Att vi förstår att SRP är ett perspektiv att granska sina klasser och metoder utifrån.

Sådär ja! One down, four to go. Next stop: Open/Closed.

Over and out!

[Dagens kodarmusik: Jochen Miller - Brace yourself]

Enkelhet - i all sin enkelhet

noreply@blogger.com (Per) — Wed, 08 Dec 2010 21:52:00 +0000

Hej, jag heter Per och jag är en "complexoholic".

Okej, det där låter ju lite udda, men jag lyssnade idag på en fantastisk föreläsning av en av mina husgudar, Dan North. Dan pratade om hur vi utvecklare är beroende av komplexitet, hur vi givet ett ganska enkelt problem gärna gör det mer komplext än det borde vara. Vi är "complexoholics".

En av de saker jag tar med mig från Dans presentation är att komma ihåg att fråga mig själv: "varför?". När vi, av ren vana, väljer en lösning bara för att ramverket finns och kan lösa problemet, är det inte alltid det enklaste sättet att lösa problemet. Därför bör vi som utvecklare vara öppna inför varje ny uppgift och inse att den är just det - en ny uppgift. Bara för att den har vissa likheter med vad vi har gjort förut, är den inte samma som vi gjort förut. Därmed kan vi inte alltid förutsätta att vi ska använda samma verktyg varje gång.

Dan gav ett exempel på hur han vek sig själv ut och in när han försökte sätta upp ett test på sin befintliga kod. Efter ett bra tags böjande och "bändande" kom en kollega fram och ställde den magiska frågan: Varför? Några svar och fler "varför" senare valde han, istället för att skriva världens mest komplexa test, att ändra koden så att både den och testet blev enklare.

Genom att ställa frågan till andra och sig själv öppnar man upp ögonen, tar ett steg tillbaka och inser att man löser fel problem. Komplexa lösningar har oftast en mycket enklare och bättre lösning, det gäller bara att hitta problemets kärna.

En annan bra sak att ta med sig är timeboxing. Jag skrev i mitt förra inlägg om risken för att spåra ur när man försöker vara en för bra scout. Den risken minimeras genom att, inför ett problem, ge sig själv en tidsgräns för hur lång tid man har på sig att lösa det. När tiden går ut tar man ett steg tillbaka och tittar ur ett fågelperspektiv och funderar på vad det är som gör att problemet inte är löst.

Många av dessa saker handlar om att öppna ögonen, att bryta invanda mönster och ett rätt så improduktivt beroende av komplexitet.

Sen finns det ju en baksida på att låta enkelheten ta över. Generaliseringar och strävan efter återanvändning är i grunden bra inställningar som vi inte bara ska slänga åt sidan. Ramverk finns för att förenkla och för att skapa en lösning som ser likadan ut överallt. Bara för att en enkel lösning löser problemet innebär inte att vi ska släppa våra kvalitetskrav. Men låter vi oss vara öppna, diskutera med någon annan och ifrågasätta kommer vi långt. Har vi också ett kvalitetsmedvetet, professionellt perspektiv kommer vi ännu längre.

Att vara utvecklare är fortfarande svårt, men faktiskt bara ännu roligare!

Over and out!

Dagens kodarmusik: Within temptation - The heart of everything

Att vara en (för) bra scout...

noreply@blogger.com (Per) — Sat, 27 Nov 2010 10:19:00 +0000

"The good boyscout rule" betyder att man ska lämna lägerplatsen lite bättre än man fann den. Applicerat till mitt område innebär det att man ska snygga till kod man träffar på lite i taget, så att det successivt blir en bättre kodbas. När jag hörde om denna regel i Robert C. Martins bok "Clean Code" lät det ju helt logiskt. Och det är det. Att hela tiden snygga till den kod man springer på gör saker bättre...

Men (ja, det låg väl ett MEN i luften) det finns problem med att tänka såhär.

Som utvecklare slåss jag hela tiden med instinkten att göra om saker. Göra saker bättre. Göra saker rätt.
Betänk följande situtation och känn om den känns bekant:

Du får i uppdrag att utveckla Feature A. Att göra den rakt upp och ner tar väl någon timme, högst. Men sisådär en kvart in i utforskandet av den befintliga koden har antalet högljudda "nämen va f-n?!" och "WTF!?" blivit så många att du tänker att du kunde gjort det här bättre, snyggare, mer rätt. Ok, du börjar refaktorera. Timme nummer tre in i din omdesign börjar det likna nåt, men det är inte riktigt klart. Bara en stund till... och en till... Till slut har du gjort om designen, men har forfarande inte gjort Feature A klar. Dessutom har du hittat ännu fler saker att göra om och ett antal saker som gör din omdesign omöjlig om inte dessa andra saker också fixas till....

Känns det igen? Här hamnar jag jämt.

Att vara en bra scout som utvecklare kräver en stor dos disciplin. Att kunna göra om lite i taget. Att inse att allt inte kan göras som du vill. Att släppa ifrån dig saker som inte är perfekta. Allt för att få jobbet gjort.

Ok, så vi behöver bli bättre på att lägga band på våra kreativa lust och våra utsvävningar. Men samtidigt är våra instinkter om vad som inte är bra säkerligen befogade. På något sätt måste de komma upp och åtgärdas. Bara inte nu. Inte på bekostnad av Feature A. Inte på bekostnad av sprinten eller projektet.

Kanske är hemligheten att lägga en kvart på att beskriva problemet man hittat i den befintliga designen. Dokumentera det, lägg det i teamets backlog och gå vidare. På det sättet kanske man får ro i den kreativa själen samtidigt som man bibehåller sprinten och projektets fart.

Jag förespråkar inte att man helt bortser från kvalitet, tvärtom. Men rikta insatserna rätt. Exempelvis släpper jag inte på rutiner som unit testing, "clean code" eller "separation of concerns" bara för att trycket är hårt. Det vore bara dumt. Men nyckeln ligger i att ta sig framåt på ett kvalitetsmedvetet sätt utan att helt köra av vägen.

Här ligger vårt paradox:
Vi måste se målet - gå mot det - men utan att tumma på våra principer.
Vi måste bibehålla våra principer - men utan att avvika från målet.

Att vara utvecklare är svårt. Men roligt!

Over and out!
Dagens kodarmusik: Tom Colontonio - Nighthawk (Original mix)

Det vackra i att dölja komplexitet (I'm back!)

noreply@blogger.com (Per) — Fri, 10 Sep 2010 18:28:00 +0000

Okej. Det var minst sagt ett tag sen. Strunt i det nu.

Idag avslutade jag dagen på topp. Vi vet ju alla att långt ifrån alla dagar på kontoret slutar så lyckligt. Ibland är man mitt i "zonen" när dagishämtningen pockar, ibland är hemgången en ren lättnad efter en dag fylld av motgångar och trassel. Men idag slutade jag på topp.

Jag har insett att min verkliga fetisch inom programmering är att gömma komplexitet. Att generalisera, parametrisera och göra den där svåra saken EN gång. För att jag sen ska utföra samma åtgärd enkelt och helst med en one-liner. Nu innefattande den lösning vi byggde en klass med tre generiska argument och en konstruktor med ett predikat, en func och en action. Snacka om generalitet.

Ok, ibland gör vi dom där generiska klasserna och snurrorna bara för att polera våra egon. Ibland drar man till med en tenär operation bara för att vi kan. Men det som verkligen ger tillfredsställelse är när man använder dessa kraftfulla konstruktioner rätt.

Ibland sysslar vi med copy-paste programmering, vi gör om samma sak om och om igen eftersom det löser uppgiften. Men i de lägena ringer klockan. Här finns chans för generalisering och förenkling.

Jag har jobbat en hel del med Silverlight och MVVM det senaste. I en situation insåg jag att vymodell 2 var till 50% en kopia av vymodell 1. Det var vid tanken att på att skriva exakt samma tester igen eller supporta samma kod på två ställen som gränsen var nådd. Därmed fann jag ett rätt användbart mönster som går att applicera på MVVM med, enligt mig, bibehållen abstraktion.

Om man behöver samma beteende i två vymodeller innebär det med all säkerhet att man har samma beteende i två vyer. Hade detta varit på min gamla WinForms tid hade jag skrikit UserControl för full hals. Ok. Jag skapar en UserControl med det gemensamma beteendet. Nu, för att använda denna UserControl behöver mina vymodeller publicera en 6-7 properties som vyn kan binda till. 6-7 properties i varje vymodell som är duplicerade... RRRRIIIIINNGGG!

Vad jag gjorde var att skapa en delad vymodell för min UserControl som var separat. Denna vymodell innehåller då de properties som behövs. Vymodell1 och Vymodell2 publicerar då bara en property, av den delade Vymodellens typ. Jag sätter DataContext på UserControlen till denna property och voila!

Det som var ännu bättre var att jag lät den delade Vymodellen ta in ett generiskt argument (ok, jag gillar tydligen dom) och därmed kunde operationerna se lika ut medan det som vyn hanterade kunde variera.
Initieringen av den delade vymodellen kan ta in Func eller Action eller Predicate för att utföra specifika åtgärder. Detta bestämmer ju den vymodell som är host, men den gör det deklarativt och EN gång.

Detta är ett mönster som jag med en gång fann mer användning för. Det har säkert ett namn, det är säkert välkänt och det finns kanske åsikter om dess legalitet... men det funkar OCH det låter mig göra saker EN gång.

Låt gå för att denna post kanske var lite mer low-level än annars. Låt gå för att den skulle innehållit kodexempel istället för "lilla sagan om koden". Låt gå. För nu skriver jag av mig tankar igen och det känns grymt!

Over and out!

[Dagens kodarmusik: RAMsterdam - Jorn van Deynhoven remix edit]

Ps. Jag hörde att Silverlight 5 är på gång. Kan det vara sant? Hur fort ska vi byta versioner egentligen! Ds.

Topp 5 podcasts för inspiration!

noreply@blogger.com (Per) — Mon, 22 Mar 2010 18:36:00 +0000

De senaste månaderna har jag varit en storkonsument av podcasts. Framförallt har det varit Hanselminutes, .Net Rocks, Herding code och MSDN Radio. Med tanke på all den tid jag lägger på pendling och renovering är just podcasts i hörlurarna ett fantastiskt medium.

Det finns såklart avsnitt som är sådär. Avsnitt som handlar om ämnen långt utanför mitt intresse och utanför vad jag riktigt begriper. Men så ibland dyker de upp - guldkornen. Avsnitt jag kan lyssna på igen, avsnitt som verkligen väcker inspirationen och öppnar ögonen.

Jag tror mycket på att vi utvecklare kan tjäna mycket på att dela med oss av det vi kan till varandra. På det sättet kan vi alla växa och göra branschen bättre. Mitt bidrag här och nu är att dela med mig av några riktiga ess bland podcast-avsnitt.

1. Hanselminutes, avsnitt 169: Roy Osherove on The Art of Unit testing

Roy har blivit en av mina hjältar. Han brinner verkligen för unit testing och kan, till skillnad från andra jag hört, verkligen förklara det på en bra och detaljerad nivå. Jag hade dessutom nöjet att se Roy på SDC 2010 där han drog in en humoristisk växel som podcast avsnittet inte visade. Han har vanan att sjunga en liten sång efter sina föredrag där han satt ny text till kända låtar. Vad sägs om "Please don't code tonight" till tonerna av Guns 'n roses "Don't cry"? Tydligen fanns det en utvecklare i hans team med vissa brister... kanske finns den på youtube någonstans...

Men det här avsnittet av Hanselminutes är ett måste för alla oss utvecklare som inte riktigt har kommit igång med unit testing. Kanske också för de som har kommit igång, men som ändå inte har fattat...

Imagine the person reading your tests is a serial killer. You don't want to piss him off.

- Roy Osherove, SDC 2010

2. .Net rocks, avsnitt 476: Is software development too complex?

Detta är en paneldebatt från konferensen Devlink, där panelen diskuterar hur svår och komplex verkligheten är för oss utvecklare. Jag fastnade mycket diskussionen kring hur vi utvecklare ställs inför högt ställda krav på att förstå och anamma ny teknik i en rasande fart. Det här avsnittet har diskuterats en hel del efteråt i andra avsnitt och är definitivt ett man inte ska missa!

3. .Net Rocks, avsnitt 520: Catching up with Juval Löwy

Alltså, Juval... det är en snubbe med rejäl hjärnkapacitet! Här börjar de i en diskussion om Juvals tes "Every class should be a WCF service". Bara att reda ut vad han menar med det gör det här avsnittet riktigt intressant. Sen hjälper det också att intervjuarna Carl och Richard ifrågasätter Juval rätt spydigt... På det hela taget ett mycket bra avsnitt om hur vi utvecklare lägger så mycket tid på "plumbing" och så lite på verklig affärsnytta.

4. Hanselminutes, avsnitt 145: SOLID principles with Uncle Bob

Bara att Uncle Bob är med borgar för bra innehåll, men här tar han upp sina SOLID principles och förklarar dem på ett bra sätt. Om du inte vet vad SOLID är - lyssna! Om du vet vad de är - lyssna ändå, Uncle Bob pratar om dem på ett så självklart vis att du kanske förstår ännu bättre. Avsnittet satte igång en rätt hetsig debatt mellan Bob och snubbarna bakom Stack overflow. Därav blev det en uppföljare med Uncle Bob i avsnitt 150.

5. .Net rocks, avsnitt 470: Nate Kohari on the Zen of project management

Titeln lockade inte först, men det här handlar om lean inom systemutveckling. Nate tillhandahåller en produkt som stödjer "Kanban boards" som en tjänst på Internet. Det intressanta är kanske inte hans produkt utan hela diskussionen kring lean och hur det förhåller sig till agile och scrum. Jag hade inte riktigt koll på begreppen "lean" och "kanban" före jag lyssnade, men nu fattar jag det hela lite bättre. Det gör du också om du offrar 45 minuter!

Det var de fem jag tänkte tipsa om nu. Men det finns många fler som är väl värda sin knappa timma.

Over and out!

Dagens kodarmusik: In Flames - Moonshield (C64 Version)

Prestationsångest och vikten av engagerade utvecklare

noreply@blogger.com (Per) — Tue, 02 Mar 2010 20:36:00 +0000

WCF, Entity Framwork, MEF, Prism, AJAX, REST, WPF, Silverlight, oData, RIA Services....

Visst har du använt alla teknikerna ovan?
Okej, inte det. Men du VET vad alla går ut på eller?
Nähä! Varför inte då? Det vet ju alla .NET utvecklare, eller?

Nä. De allra flesta av oss har inte koll på alla nyheter som dyker upp inom .NET området. Det är helt enkelt en massiv flod av nya tekniker som sköljer mot oss. Lyssnar man på podcasts eller läser tidningar låter det som om ALLA är helt uppe i senaste 4.0 ramverket och allt vad det innebär, fastän det egentligen inte ens har släppts. Det skapar en hel del prestationsångest för oss vanliga dödliga utvecklare.

Vilket ansvar har jag egentligen för att ta till mig all ny teknik? Om jag jobbar på ett företag som levererar mjukvara vars säljargument är "alltid först med det senaste inom teknik" är det säkerligen en företagspolicy. Det kommer då vara en organisation som ser det som helt normalt att hela tiden hänga med. Men jag tvivlar på att de allra flesta arbetar på det företaget. Många arbetar i organisationer där IT och mjukvara bara är ett verktyg för att hjälpa företaget med dess egentliga brödföda. Hade de kunnat driva verksamheten utan IT hade det varit det bästa, men av många skäl måste de ha IT system. Om man, som jag, sitter på just ett sådant företag är ansvaret mycket otydligare. Ansvaret ligger då på oss utvecklare att hela tiden hänga med i utvecklingen.

Men det finns ju egentligen inget självändamål med att anamma nya tekniker bara för att de är nya. Men om vi inte sätter oss in i dem och förstår dem ser vi inte heller den potential som de kan ge. Vi kanske levererar lösningar som fungerar, de kanske till och med fungerar bra. Men de kunde varit enklare att underhålla, enklare att förändra eller mer användarvänliga om vi valt en ny modernare teknik. Om vi drar på oss skygglappar och fortsätter oförändrat blir vår teknik snart föråldrad och vi målar hjälplöst in oss i ett hörn.

Så min fundering är: Inser dessa företag vilket ansvar som ligger på oss utvecklare? Är de beredda att betala för den tid det tar att bara utvärdera och hänga med i det ständigt pulserande flödet? Jag tror att svaret är nej på båda frågorna.

Enligt min erfarenhet kommer ansvaret falla på en eller ett par tongivande utvecklare som på fritiden, av rent intresse, läser om eller söker information om nya tekniker. Det handlar om eldsjälar som av ren lust slänger ihop en WPF applikation bara för att se hur det funkar. Eller om den som plöjer böcker om WCF istället för romaner innan nattlampan släcks. Jag tror att de flesta små utvecklingsavdelningar är beroende av dessa få personer. Och inte nog med det, de är beroende av att dessa få är villiga att sprida sin entusiasm och nyfikenhet vidare som kunskap till de övriga på avdelningen. Är det rimligt att ställa sådana krav på anställda? Troligen inte. Men dessa personer gör det ändå, för att det är roligt helt enkelt!

Tidigare var jag absolut inte den personen. Jag var nöjd och glad med att hacka på i det som fanns och hade tillräcklig utmaning med att förstå det vi sysslade med just då. Men jag har förändrats. Jag har börjat lyssna på podcasts eller läsa böcker på väg till jobbet. Att veta lite mer om det som finns omkring mig är riktigt spännande och sätter många saker i nya perspektiv. Kanske är jag på väg att bli en av "dem", kanske är det bara en fas som "kunskapssvamp"...

Men att bli varse om vad som finns är egentligen det som leder till den största prestationsångesten. Att veta om vad som finns och hur kort man kommit i jämförelse till allt det andra är värre än att bara hänga med i det man just nu gör. Men glöm det! Det är okej att vara den som "bara" hänger med, det passar inte alla att vara eldsjäl eller evangelist. Vi behöver alla utvecklare! Vi behöver de som är mer fokuserade på verksamhet, är specialister på våra befintliga system och de som "bara" hänger med. Tro mig, det är svårt nog ibland.

Så med det sagt - Hatten av till alla er evangelister, eldsjälar och "überstormmeisters" där ute och en
personlig hatt till Olausson & Olsson, två exempel på kunskapsspridare jag mött i min karriär.
Ni regerar!

Over and out!

Dagens kodarmusik: Jochen Miller - Lost Connection

Ps. Jag skulle gärna vilja veta hur andra företag gör, vad driver er teknikutveckling inom systemutvecklingsområdet? Ds.

Om ambitioner, karriärsval och vår yrkesstolthet

noreply@blogger.com (Per) — Sat, 06 Feb 2010 20:37:00 +0000

Nyligen har jag varit inblandad i rekryteringen av nya utvecklare. Förutom insikten om att vi är ganska sällsynta, fick det mig in på ämnet karriärsval och ambitioner.

När jag började plugga systemutveckling 1998 var den gemensamma uppfattningen hos mig och mina klasskompisar att programmering var kul men inte slutstationen. Ju förr man fick dra på sig slipsen och titulera sig projektledare eller något annat flott, desto bättre! Programmering var något man började med för att senare klättra raskt uppåt för att inte alls ha med kod att göra. Tanken då var att någon annan ju skulle koda det vi bestämt, designat eller arkitektat.

Jag minns tydligt mina formuleringar i mina jobbansökningar: "jag siktar på att en dag lyfta blicken från koden och arbeta mera med projektledning". När jag efter mina första fem år som utvecklare sökte nytt jobb menade jag formuleringen mer än förut och tänkte att mina fem år som utvecklare borde ju ge pay off snart!

Nu inser jag hur fel jag hade. Mina första fem år som utvecklare gav pay off, men inte det jag tänkt. Jag blev bättre - på att utveckla, inte projektleda. Varför skulle det vara då självklart att jag som utvecklare skulle nalkas projektlederi? Varför skulle mina fem års programmerande göra mig till en bra projektledare eller, för den sakens skull, ens intresserad av projektledning.

Nu frågar jag mig istället: vad är roligt och utmanande i mitt arbete? Vad är det som får igång min kreativitet, mitt engagemang och min nyfikenhet? Det är lätt att svara på. Dom stunder jag sitter och programmerar - skapar - är de absolut mest utmanande. Nu, med snart åtta års erfarenhet känner jag mig än mindre fullärd som programmerare än någonsin. Det innebär inte att jag är sämre, bara att jag förstått att allting hela tiden utvecklas. Ju mer man gör sig medveten av vad som finns tillgängligt och vad andra gör, inser man att det finns mycket man inte kan eller inte provat.

Med den bakgrunden, att allting förändras, hur kan vi som programmerare / systemutvecklare då se som självklart att vårt yrke är ett steg mot något annat? Varför kan vi inte bara finna stolthet i vårt yrke och finna glädjen i att bli mer och mer professionella på just det?

Det finns ju två vanliga vägar vi kan välja att gå, som alternativ till att stanna kvar som programmerare / systemutvecklare (vad är skillnaden egentligen, varför skriver jag / mellan dessa titlar?).

Projektledare innebär ju oftast att administrera. Att hålla koll på projektet, planera tid, följa upp arbete och svettas med kunder. Själva rollen erbjuder ju ingen hands-on med koden direkt. Som projektledare handlar det mer om arbetsledning och administration än utveckling. I mina öron lockar det inte.

Arkitekt innebär oftast att koden börjar tyna bort från skrivbordet (nivån av försvinnande beror kanske på typ av arkitekt) och att man mer använder Visio och Outlook som sin utvecklingsmiljö. Visst är det kul att sitta och spåna om lösningar, beskriva dem och eventuellt rita diagram över dem. Men vore det inte trist att inte få skörda frukten och se lösningen växa fram i kod? Dan North pratade på Öredev om arkitektrollen och att det var ett problem att denne ofta inte har kontakt med koden längre. "Code? I am an architecht, can't you SEE my beard?!".

Poängen är inte att dissa dessa andra yrken. Inte alls. Poängen är att se dem som andra yrken. De behövs och förtjänar all respekt, men de är inte en naturlig följd av ett par år som systemutvecklare. De är yrken man kan välja, oavsett om man varit utvecklare eller ej.

Jag har börjat se annorlunda på framtiden. Jag är nöjd med att vara utvecklare, nöjd med att bli bättre på att göra just det. Jag har mycket kvar att lära och är fortfarande gladast när jag får koda. Hade jag varit i en organisation där mitt yrke innebar en serverad lösning som jag, utifrån strikta riktlinjer, skulle koda hade min glädje säkert varit mindre Jag vill ha mer frihet. Men jag undrar om sådana ställen verkligen finns. Med dagens agila trender krävs vi systemutvecklare att göra mer av allt. Vi är lite projektledare, lite arkitekter och en stor portion programmerare. Därför undrar jag hur många strikt uppstyrda "programmerare" det finns idag.

Tyvärr är ju verkligheten att om man blir för bra på att utveckla kommer man i många fall bli erbjuden steg "uppåt", vilket innebär mindre och mindre av det man är så bra på. Man blir "promoted to incompetence", dvs man skickas uppåt så länge man är riktigt bra på sitt jobb tills man stannar på ett man inte är lika bra på... (Kallas också The Peter Principle). Jag skulle vilja se en framtid där karriärsstegen innebar att bli bättre och bättre på att utveckla. Att få erkännande för sitt kunnande, sina färdigheter och sin kunskapsspridning till andra.

Men okej, visst finns det personer som hittar en alternativ karriär genom att befordras. Men jag vill slå ett slag för att värdera de som är riktigt bra utvecklare. Klappa dem på axeln, ge dem högre lön - men skicka inte alla längre bort från koden.

Vad alla andra väljer att göra i sin karriär är ointressant. Det är vårt eget karriärsval som är det viktiga. Är man glad och nöjd med det man gör och ser en framtid i det - fortsätt med det! Det tänker jag göra. Men här och nu stryker jag "siktar på projektledarrollen" ur mitt CV.

Over and out!

Dagens kodarmusik: Pain of salvation - Road salt (Ja, jag är ett melodifestival-freak)

Alla vill bidra med något - vad är vårt bidrag?

noreply@blogger.com (Per) — Mon, 01 Feb 2010 11:54:00 +0000

Tittade på Skavlan i SVT där filosofen Alain de Botton var med. Alain talade om ämnen från sin bok "the pleasure and sorrows of work". En verkligt intressant man med många spännande tankar. En sak han sa fastnade hos mig: i vårt arbete vill vi alla känna att vi har en mening, att vårt arbete gör skillnad för någon annan. Oavsett hur litet bidraget är gör det oss lyckliga.

Jag har länge funderat över vad vårt bidrag egentligen är. Vi levererar ju något väldigt abstrakt, ettor och nollor. I bästa fall syns vår applikation, men vad bidrar det egentligen till? Svaret är användarnytta.
Som utvecklare är inte vårt syfte att skapa teknisk briljans, innovation eller smarta funktioner. Vårt syfte är att göra skillnad för våra användare. Ofta hamnar jag själv i diskussioner oim hur vi kunde bygga det ena eller andra på olika sätt för att göra det så tekniskt smart som möjligt. Mindre ofta handlar diskussionen om på vilket sätt användaren skulle komma till gagn.
Det kan bero på att de flesta av oss sitter ett par led från den nytta vi egentligen förväntar oss. Vi skulle egentligen vilja göra en direkt nytta genom att bidra till företagets välstånd, bättre klimat eller en bättre värld. För de flesta av oss är den direkta nytta vi gör förknippat med hur väl någon annan kan använda vår mjukvara för att göra sin del i kedjan. En användare kan då skapa ett bättre produktsortiment, som sedan kan marknadsföras av marknadsavdelningen som sedan kan säljas av säljledet. Alla har vi vår del i nyttan, det gäller bara att finna vår plats.

Det känns som en lättnad att ha hittat min del i det stora ekorrhjulet. Med andra ord ska användaren bli min bästa kompis framöver, den jag vill göra glad, den jag vill göra mitt bästa för. Självklart måste ett visst mått av teknisk briljans förekonma, både för att göra jobbet på bästa sätt men också för utmaningen, för att polera det professionella egot en smula. Expertkänslan man får av välskriven och vällbyggd mjukvara skapar en professionell lycka. Men det får inte överskugga varför vi egentligen utvecklar. För, lets face it - ingen användare, inget jobb.

Mitt i skrivandet av detta inlägg lyssnade jag på podcasten .Net rocks (som är helt grym, by the way). Man intervjuade Juval Löwy, levande utvecklarlegend och sjukt intelligent snubbe. Han sa något som fastnade, ungefär: Det vi utvecklare producerar hamnar i en av två kategorier. Den ena är affärsnytta. Den andra är "plumbing", rörmokeri, infrastruktur. Användaren bryr sig inte alls om rörmokeriet i mjukvaran, ändå är det där vi gör absolut mest arbete.

Även om Juval hade en annan poäng med uttalandet än just användarnytta, visst låter det bekant? Vår möda ligger mer på hur vi bygger än på vad vi bygger och varför.

Jag bjuder gärna in till ett inlägg om hur vi får den andra sidan att se på oss på samma sätt. Att vi är där för att hjälpa, men att vi behöver veta hur vi kan hjälpa.

I en artikel i Computer Sweden förra veckan tyckte Lars Dahmén att vi skulle sätta oss bredvid användarna i lunchrummet. Det låter som en bra idé. Leta upp en användare, bjud på en kopp kaffe och fråga vad du kan göra för honom/henne! Jag tror det kan vara början till en vacker vänskap...

Over and out!

Dagens kodarmusik: Signum - Push Through (Edit)

Fast i databehandlingsträsket!

noreply@blogger.com (Per) — Tue, 19 Jan 2010 21:58:00 +0000

Förr i tiden kallades vårt yrke för ADB. På 80-talet innebar det Automatisk Databehandling, på 60- och 70-talet Administrativ Databehandling.

För de allra flesta i min generation känns termen ADB som uråldrig. Det luktar lite gammal 70-tals inredning och farbröder med skägg som snackar Turing-maskiner och hackar maskinkod eller lämnar in hålkort för kompilering. Tyvärr känner jag dessa dagar allt för väl igen mig i den ursprungliga innebörden av förkortningen - administrativ databehandling. För den senaste tiden har större delen av min arbetstid gått åt till att just administrera data. Gräva fram och tillbaka i databaser för att manuellt ta reda på information, påverka information eller rätta till information. Det är inte ens lite roligt och påminner mig om devisen att "repetitiva uppgifter gör dig dummare". Vart tog utvecklingen vägen? Vart tog arbetet med att utforma smart och effektivt IT-stöd vägen?

Svaret på detta tror jag ligger i två punkter.

1. För dåliga system
Grejen är att hade systemen vi bygger varit snäppet bättre hade man inte behövt leta i obskyr data för att finna lösningen på problem. Antingen hade systemet inte haft problem eller så hade det åtminstone innehållit tillräckliga felsökningsfunktioner för att slippa dataträsket. Då kunde problemen lämnas till användarna som faktiskt äger datan - vilket för mig till nästa punkt.

2. Fel ägare på data - fel kultur
Som systemutvecklare skapar jag IT-stöd. Det är mitt expertområde. Stödet byggs för användare som av ett eller annat skäl har funnit behov för ett detta stöd. Med hjälp av min applikation ska användaren sköta sin data på ett enklare sätt. Förut kanske användaren hanterade allt manuellt, men nu ska denna alltså föräras ett förstklassigt IT-stöd för uppgiften. Med andra ord - det som systemet hanterar i form av domänbegrepp och data ägs helt och hållet av användaren. Det är sant oavsett om vi bygger ett system eller ej. Jag sitter inte på min kammare och fyller på en massa affärsdata i systemen, det är ju det användaren har tänkt att göra.
Varför då inte bygga system som låter användaren ta det fulla ansvaret? Jag är inte alls intresserad av vad han eller hon matar in, söker fram eller redigerar. Det är ett arbetsverktyg, men det är inte mitt arbetsverktyg.

Kulturen runt omkring oss, iallfall runt mig, andas ibland en form av "expertstämpel" på oss systemutvecklare. Vi blir någon slags mytomspunna orakel med allsmäktig kunskap - om allt. Givet den rollen är det bara vi som har den magiska kraften att på något sätt leta rätt bland den data andra skapar... Passar rätt väl med en bild av skäggig farbror på 70-talet, eller hur?

Nästa gång som du får frågan från en användare om att manuellt gräva i data, fundera över hur du kunde ha undvikit situationen?

Kan användaren använda befintliga, om än krångliga vägar, för att själv hitta rätt? Är sättet allt för krångligt föds behovet av bättre sätt och vi får nya uppdrag.
Kan du med enkla medel automatisera sökandet i en ny funktion? På det viset slipper du iallafall leta manuellt varje gång.
Kan du publicera den nya funktionen till användaren?
Kan du ta bort felet som orsakar behovet att söka fram data? Är modellen för krånglig, funktionerna bristfälliga eller finns det helt enkelt buggar. "We should fix that"!

Det är dags att byta kultur. Datorer och IT-system är inte magiska. De är egentligen inte särskilt spännande alls. Det som är spännande är hur vi kan använda dem och låta dem göra nytta för oss. Där ligger vår expertis, vårt intresse och vår utmaning! Låt oss bli mer IT-avdelning och mindre Data-avdelning!

Over and out!

Dagens ~~kodar~~ ADB-musik: Lady Gaga - Bad Romance

"The pit of despair"

noreply@blogger.com (Per) — Thu, 17 Dec 2009 20:43:00 +0000

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.

bild från http://stevenmsmith.com/ar-satir-change-model/

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.

Dags att spela i samma lag!

noreply@blogger.com (Per) — Sun, 13 Dec 2009 19:43:00 +0000

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

Unit testing success story!

noreply@blogger.com (Per) — Mon, 07 Dec 2009 20:29:00 +0000

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)

En nybörjares syn på unit testing

noreply@blogger.com (Per) — Sun, 06 Dec 2009 19:11:00 +0000

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

Videos från Öredev

noreply@blogger.com (Per) — Fri, 27 Nov 2009 22:12:00 +0000

Missa inte chansen att se dessa guldkorn från Öredev!

Dan North - Our obsession with Efiiciency

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!

noreply@blogger.com (Per) — Fri, 27 Nov 2009 20:37:00 +0000

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)

We are the Commitments!

noreply@blogger.com (Per) — Thu, 26 Nov 2009 20:57:00 +0000

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

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

noreply@blogger.com (Per) — Thu, 19 Nov 2009 21:36:00 +0000

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.

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

noreply@blogger.com (Per) — Tue, 17 Nov 2009 22:15:00 +0000

"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?

Samtal jag behöver färre av

noreply@blogger.com (Per) — Mon, 16 Nov 2009 20:35:00 +0000

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.

Lästips på ämnet effektivitet!

noreply@blogger.com (Per) — Sun, 15 Nov 2009 18:06:00 +0000

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]

Butiken är stängd för Fokustid!

noreply@blogger.com (Per) — Mon, 09 Nov 2009 07:32:00 +0000

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]

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

noreply@blogger.com (Per) — Sun, 08 Nov 2009 13:42:00 +0000

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.