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)

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)