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.
tisdag 2 mars 2010
lördag 6 februari 2010
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)
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)
måndag 1 februari 2010
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)
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)
tisdag 19 januari 2010
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?
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!
Dagenskodar ADB-musik: Lady Gaga - Bad Romance
Over and out!
Dagens
torsdag 17 december 2009
"The pit of despair"
Nyligen har vi i vårt team gjort en ansats till att göra mera unit tests. Det är en grym känsla när vi alla verkar få samma "tända glödlampa" över våra huvuden, när insikten om att det här är vad vi borde göra slår oss alla samtidigt. Att vara överrens underlättar ju helt klart.
Men vägen till ett bättre och förändrat arbetssätt är motig. Jag har flera gånger den senaste tiden varit på god väg att ta en liten genväg för att slippa ta den jobbiga vägen över unit tests. Jag vet ju självklart innerst inne att vi inte kan fortsätta koda på utan tester, alla de buggar jag kämpat med är ju ett bevis på att något måste bli bättre. Men ändå kryper den gamla vanan fram ibland och man kommer på sig själv att argumentera för att försvara sitt tillfälliga undantag. "Ja men den HÄR grejen kan jag ju inte testa... den är ju trivial och dessutom svinjobbig att testa!"
Som tur är finns det fler än jag i teamet. Hade det bara varit jag hade min monolog enkelt kunnat låtit logisk och ja själv hade säkert accepterat ursäkten för att tillfälligt undvika från planen. Tillfällena hade nog blivit fler... och ännu fler. Till slut sitter man där igen, inte ett dugg bättre och med samma gamla buggar som välkomnar en på morgonen. Men har man människor runt sig som ifrågasätter undantaget (ja ibland räcker det med en tveksam blick för att fånga samvetet...) så blir det inte så.
Nä, det är bara att bita ihop! Under Dan Norths föreläsning på Öredev pratade han om "the Satir Change Model". Den beskriver ungefär hur vi hanterar förändring och hur vi tar oss vidare. Det är en stegvis process.
Steven Smith beskriver den bra i sin blog.
Men vägen till ett bättre och förändrat arbetssätt är motig. Jag har flera gånger den senaste tiden varit på god väg att ta en liten genväg för att slippa ta den jobbiga vägen över unit tests. Jag vet ju självklart innerst inne att vi inte kan fortsätta koda på utan tester, alla de buggar jag kämpat med är ju ett bevis på att något måste bli bättre. Men ändå kryper den gamla vanan fram ibland och man kommer på sig själv att argumentera för att försvara sitt tillfälliga undantag. "Ja men den HÄR grejen kan jag ju inte testa... den är ju trivial och dessutom svinjobbig att testa!"
Som tur är finns det fler än jag i teamet. Hade det bara varit jag hade min monolog enkelt kunnat låtit logisk och ja själv hade säkert accepterat ursäkten för att tillfälligt undvika från planen. Tillfällena hade nog blivit fler... och ännu fler. Till slut sitter man där igen, inte ett dugg bättre och med samma gamla buggar som välkomnar en på morgonen. Men har man människor runt sig som ifrågasätter undantaget (ja ibland räcker det med en tveksam blick för att fånga samvetet...) så blir det inte så.
Nä, det är bara att bita ihop! Under Dan Norths föreläsning på Öredev pratade han om "the Satir Change Model". Den beskriver ungefär hur vi hanterar förändring och hur vi tar oss vidare. Det är en stegvis process.
Steven Smith beskriver den bra i sin blog.
I stort går det ut på att vi befinner oss i ett nuläge, trygga i det vi kan, det vi är vana vid och vårt beteende, även om det är ett destruktivt beteende. En förändring introduceras och genast föds ett motstånd mot det nya där vi, medvetet eller omedvetet, motarbetar förändringen. Nästa steg är KAOS. I botten av detta kaos finns "the pit of despair". Nu är vi på botten och har svårt att se hur vi ska kunna ro iland förändringen.
Men - låter vi oss komma förbi denna grop väntar integrering och nya insikter, när vi ser hur det nya faktiskt hjälper oss i vårt arbete. Och fullföljer vi integreringen väntar ett nytt nuläge där vi förbättrat oss och vant oss vid nya, mindre destruktiva beteenden.
Tänker jag efter känner jag klart igen mitt eget beteende. Fastän jag var fullt delaktig i initiativet till förändringen har jag gjort motstånd med mina lama ursäkter om att slippa undan. Just nu befinner vårt team sig i gropen och med sprattlande armar försöker vi gräva oss upp. Men att bara inse att det är där vi är hoppas jag är ett bra tecken.
Det är dags att släppa motståndet och låta kaoset styra ett tag.
Snart är vi på väg upp igen. Åtminstone lagom till nästa förändring...
Over and out!
Dagens kodarmusik: Ingen musik, utan lite Hanselminutes med Roy Osherove om Unit Testing.
söndag 13 december 2009
Dags att spela i samma lag!
Min uppfattning om vårt yrke, systemutvecklare, har alltid varit att vi gör mer än att knacka kod. Vi gör mer än att designa mjukvaruarkitekturer. Vi löser behov. Vi utvecklar verksamheten tillsammans med de som arbetar i och med den. Utan dem skulle det inte finnas någon verksamhet, inga behov och inget berättigande för vårt yrkes existens. Tyvärr upplever jag att vi ganska sällan kommer till vår fulla rätt.
Den "färdiga" lösningen på ett fat
Allt för ofta kommer en färdig lösning till oss från användare eller ledning. Det innebär att någon annan än vi har tänkt ut vilket systemstöd som ska finnas och när det måste vara klart. Vi kommer in allt för sent i processen när viktiga beslut redan är fattade som på många sätt inskränker i vår möjlighet att utöva det vi är bäst på - att utveckla IT-stöd. Om vi redan tidigt fanns med i processen kunde vi bättre förstå skäl och bakgrund till det man vill åstadkomma och kanske finna bättre vägar eller ännu bättre lösningar. Men när man får en färdig lösning finns det oftast varken tid eller mandat för att gå tillbaka och riva upp beslut eftersom någon annan ju redan "vet" att det är den enda och bästa vägen. Sen sitter man som utvecklare och knackar ihop något man egentligen inte tror på.
Två månader på IT-kammaren och sen är det klart
Ett annat vanligt scenario är att vi IT-människor får allt för fria händer. Vi tolkar lite tunna uppgifter vi fått för att sedan stänga in oss och designa en lösning som ur vårt perspektiv verkar klockren. Tyvärr slutar det ju ofta med väldigt komplicerade funktioner som användarna inte förstår eller tycker fungerar i deras vardag. De vet inte vad de ville ha, men det som levererades var inte rätt. Lösningen har fått för stort IT-fokus. Fundera en stund över den där dialogen du designade med lite väl "data-nära" termer här och var...
Det här är två ytterligheter, men de pekar båda på samma område där vi allt för ofta brister - samarbete.
Vi måste på ett bättre sätt lyckas använda varandra. De har kunskap om verksamheten och lever i den varje dag. De är beroende av det vi levererar och måste leva med det, varje dag. Vi har kunskap om hur man gör bra IT-stöd, hur man kan samverka med befintliga lösningar och vilka tekniker som är aktuella idag. Var för sig kommer vi till korta, men tillsammans har vi ju en rätt bra laguppställning. Vi täcker ju in alla väsentliga områden! Vore det då inte bättre om vi blev lite mindre DE och lite mera VI?
VI jobbar gemensamt eftersom vi har ett gemensamt mål, en verksamhet som fungerar bra och presterar på topp. Genom att utnyttja våra olika kompetenser och roller på bästa sätt kan vi få mycket bättre effekt och undvika feltolkningar. VI är större än meningslösa motstridigheter, vi bryr oss om vårt gemensamma arbete och vårt gemensamma resultat. Det spelar ingen roll vem eller vad som är skälet till att något inte fungerar eller brister, vi har ett gemensamt ansvar för att få det att fungera.
Det här är några punkter jag tänker arbeta mer för framöver:
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?
Så vad är problemet?
Over and out!
Dagens kodarmusik: Europe - New love in town
måndag 7 december 2009
Unit testing success story!
Jag var bara tvungen att skriva en liten glädjepost om mitt första riktiga äventyr med unit testing.
Jag har under de senaste dagarna lagt till några nya funktioner i en grafisk kontroll. Den består i stort av en datagridview med ett antal rader och kolumner. Vissa rader är summor av ovanstående rader, vissa kolumner är summa av radens värden. Alltså, det finns lite relationer raderna och kolumnerna emellan.
I samband med att jag gjorde de nya funktionerna skrev jag i princip om hela kontrollen och dess affärslogik för att göra den mera testbar. Det verkade som en liten lagom prototyp. Och det var det.
För att bara beskriva läget före min unit testing refactoring, såg det ut ungefär så här:
Och så efter...
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:
Over and out!
Dagens kodarmusik: Riva - Time is the healer (Armin van Buuren remix)
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)
Prenumerera på:
Inlägg (Atom)
Inlägg
