Enkelhet - i all sin enkelhet

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...

"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!)

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!

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

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

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?

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!

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