Ännu en dag att lära sig nya saker

Igår lärde jag mig om jUnit, Spring Integration, Enterprise Java Bean, REST, Jersey, Maven, Apache CXF, Tomcat, Data access object, DBMS, Spring MVC, SOAP UI, Selenium remote control, Hudson, annotations, JMS, Apache ActiveMQ, lastballansering och enterprise-arkitektur.

Undrar vad jag ska stöta på idag.

Andra saker jag stött på är: JVM PermGen, heap, HotSpot, Spunk, WSDL, UDDI, Nagios, Xymon.

Underbara automatiska back-up!

Till mitt företag Förnuftkonsult har jag köpt in en härlig mac-dator och kopplat på en Time Capsule som automatiskt tar back-up på allt jag har på datorn en gång om dagen. Det fina med just den här uppsättningen är att det funkar direkt och är superenkelt! Jag behöver aldrig mer vara orolig för att förlora data vid en hårddiskkrasch eller att jag råkar ta bort en fil som jag behöver.

Idag fick jag ett konstigt fel när jag jobbade med Förnuftkonsult.se som jag inte lyckades få bort. Felet uppträdde dessutom bara i Google Chrome och inte i Safari. Istället för att lägga flera timmar i felsökning backade jag bara till hur hemsidan såg ut igår genom att hämta gårdagens filer. Ta en titt på bilden här så ser ni vilket härligt grafiskt gränssnitt Apple har tagit fram. Man stegar fram och tillbaka i tiden genom pilarna i mitten, väljer det datum man vill ha och trycker på återskapa. Lätt och enkelt på the Apple Way, och min hemsida är räddad!



Jag vet att det här funkar i Windows och Linux också, men poängen är att det här är är så enkelt att man tar till sig tekniken. Kan ni förresten tänka er att det finns professionella mjukvaruutvecklingsföretag som inte har stöd för att backa tillbaka i tiden. Helt vansinnigt!

Tankar om management

"När vi tillsätter ledare så är det inte så att vi har en hel drös att leta bland, vi får ta de få vi har." Det svaret fick jag på jobbet när jag ifrågasatte kompetensen på vissa ledare. Och inom just mjukvara är det svårt att hitta ledare av den enkla anledningen att ledarna behöver ha jobbat mycket som programmerare. Som programmerare är man kreativ och skapar saker varje dag. Som ledare är man uppföljande och ser till att saker görs på rätt sätt. Det är helt andra belöningssystem som kickar i gång i hjärnan för de två olika rollerna.

Är man programmerare så är man det för att man gillar att vara kreativ. Att sedan bli befordrad till en position som inte mättar det kreativa behovet kan vara förödande. Paul Grahams åsikt om detta är:

How can I avoid turning into a pointy-haired boss?
The pointy-haired boss is a manager who doesn't program. So the surest way to avoid becoming him is to stay a programmer. What tempts programmers to become managers are companies with old-fashioned corporate structure, where the only way to advance in salary and prestige is to go into management. So if you want to avoid becoming a PHB, avoid such companies, and work for (or start) startups.

Jag är teknisk teamledare för att jag tycker att det är en lagom nivå att jobba på. Mitt uppdrag är att se till att saker utförs i rätt ordning så att vi kan leverera med rätt kvalitet. Jag har folk som gör det vanliga implementationsjobbet och jag trivs med jobbet. Men ändå längtar jag efter att få vara en i gänget som faktiskt kodar och tillverkar grejerna.

Mark Freedman intervjuades i This Developers Life i ämnet och har bloggat om intervjun. Mark var själv nära att fastna i managementspåret. På hans tidigare jobb fick han frågan att ha måste bestämma sig för att bli ledare eller programmerare. Mark grubblade en stund och sedan sa han upp sig. Frågan är om det inte är samma resa jag håller på med. Jag fick samma fråga i mars i år och jag vägrade acceptera den, så utan att förstå det då är det kanske inte så konstigt att jag byter jobb nu.

På nya jobbet har jag sålt in mig som teamledare, men de insisterar på att jag måste kunna fler tekniker och branscher innan jag blir riktigt vass. Och så länge ska jag programmera. Boyakasha! Det är ju exakt vad jag vill göra! Kommer osökt att tänka mitt gamla inlägg om mjukvarunörden slår tillbaka!

Googles kodtest

Jag förespråkar starkt att kodtest eller liknande test görs vid nyanställning av programmerare. Några som har fattat detta och som alltid kör det är Google.

I våras sökte jag en tjänst på Google i Stockholm om nu har jag precis gjort testet. Man fick välja mellan C, C++, Java och Python. Att det inte är språkberoende är vettigt för då testar man mer förståelse för problemlösning med avseende på algoritmer och minnesanvändning, istället för grafisk programmering av specifika GUI-paket eller databaskopplingar.

Uppgifterna var ungefär som vid universitetet i kursen "Analys och konstruktion av algoritmer", de handlar om att processa data på olika sätt utan att använda några standardfunktioner. Man har 90 minuter på sig för tre uppgifter.

Första uppgiften gick finfint och jag fick med bra felhantering. Andra uppgiften tolkade jag fel och fick strukturera om totalt. Tiden gick och när det bara var totalt 20 minuter kvar vågade jag inte fortsätta utan submittade en icke-lösning för att komma vidare till uppgift tre. Uppgift tre var ett skolboksexempel som jag knappade in på tre minuter och hade testat helt och fullt efter ytterliggare tre.

Över lag är jag grymt nöjd med testet och mitt genomförande av testet. Synd att jag tiltade på andra uppgiften och därför bara klarade två av tre. Så även om Google inte vill ha mig så var det riktigt kul att göra deras test och att känna att jag varit med i matchen och fightats!

Manifest för Agil säkerhetskritisk systemutveckling?

Vi finner bättre sätt att utveckla programvara
 genom att utveckla själva och hjälpa andra att utveckla.
 Genom detta arbete har vi kommit att värdesätta:

Individer och interaktioner framför processer och verktyg


Fungerande programvara framför omfattande dokumentation


Kundsamarbete framför kontraktsförhandling


Anpassning till förändring framför att följa en plan

Det vill säga, medan det finns värde i punkterna till höger,
värdesätter vi punkterna till vänster mer.

Dessa ord bygger upp ett manifest som 17 erkända utvecklare kom fram till när de bestämde sig för att hjälpa världen ifrån ej fungerande vattenfallsmetoder. Den erfarenhet jag samlat på mig säger att många småföretag anammat tankesättet väl, medan många storföretag fortfarande värderar orden till höger ovan.

Inom just säkerhetskritisk mjukvara som jag utvecklar tror jag att det behövs en omfattande dokumentation. När det handlar om miljardorders mellan nationer är det kanske rimligt att kontraktsförhandlingar är att föredrag för att slippa kravglidning. När det är många komponenter i ett komplext system som ska integreras är det möjligt att det är viktigt att följa en plan och förbjuda förändringar. Och när det är produkter som spänner över 10-20 år är det möjligt att processer och verktyg som kan bestå är viktigare än individer som försvinner till nya arbeten efter några år.

Om någon av er har tänkt ut vilken sida man bör befinna sig på för säkerhetskritisk mjukvara så tveka inte att maila mig på anders.holmberg@gmail.com eller ännu hellre, posta en kommentar.

Ps: Jag vill gärna applicera det agila manifestet på säkerhetskritisk mjukvara men jag vill även tänka kritiskt om det innan jag gör det.

[Tillagt i efterhand]

Agildiskussionen är het på jobbet och till min hjälp har jag hittat en underbar artikelserie på Open-DO. Snart kommer mina argument att krossa allt motstånd och David ska segra mot Goliat! :)

Operationell effektivitet, schitzofreni och rädsla

Operationell effektivitet är den rörelsehastighet utvecklingen har för stunden. Strategi är den långsiktiga visionen om kompetens, produkter och arbetssätt. Operationell effektivitet är kortsiktig och strategin är långsiktig. För att på lång sikt hitta bästa möjliga kompetens, produkter och arbetssätt kan många ineffektiva kortsiktiga vägar behöva trampas.

Mitt projekt är inte bara ett demonstrationsflygplan, det är även ett forsknings- och utvecklingsprojekt för att forma strategin. Det experimenteras hej vilt med nya verktyg, nya ansvarsuppdelningar, affärspaket/outsourcing etc. Resurser flyttas om för att se vilka effekter som uppstår.

Utan någon som är metodansvarig odlas nytt folk fram som lär sig att hitta nya metoder, och vi får dessutom fram dessa nya metoder samtidigt. Visar metoderna sig inte tillräckligt bra kan vi alltid sätta in någon som kan den gamla metoden. Att bli sen eller skjuta över budget är sekundärt i utforskningen av strategin. Tid och budget är något som de jobbar med i operativ verksamhet, vi experimenterar mot strategimålen.

Hela Förnuftkonsult har odlas fram genom mitt arbete i projektet. Jag lär mig saker varje dag i den här lekstugan och jag borde snart flyttas ut i operativ verksamhet för att sprida kunskapen.

Alla de här insikterna flög över mig idag och jag känner mig just nu som en experimentråtta som insett att den är med i ett experiment. Jag har senaste halvåret fokusera mycket aggression på upper management som verkar ha hål i huvudet. När det i själva verket handlar om att testa råttans gränser och se hur länge den springer efter ostbiten de hela tiden flyttar på.

Troligtvis är det någon som övervakar alla råttor och ser hur de beter sig nere på golvet. Det sätts betyg på oss och de mäter hur vi fungerar. Lite som försäkringsbolagsreklamerna. De kanske till och med följer alla mina steg och läser min blogg. Allt är bara en stor komplott där jag fått en plats i lekstugan för att bevakas. Men jag vägrar, den här råttan ska börja experimentera med experimentledarna.

Och precis när jag kom så här långt i tankarna blev jag uppriktigt rädd för mig själv. Jag känner att jag börjar bli schizofren och paranoid. Am I loosing it? Jag känner mig som professorn i A Beautiful Mind!

Eller är jag en experimentråtta i en experimentvärld? Hjäälp!

Produktiva projekt och team

Förlåt Tapio, jag har pussat på din bok mer än tio gånger men jag är klar med den nu så du får tillbaks den snart. Det här guldkornet gör läsaren till en oändligt mycket mer insiktsfull och krävande medarbetare. Efter du slår igen den här boken vet du vad du ska kräva av management, eller du vet vad som krävs av dig som kallar dig management. Peopleware är anledningen till min revolution där jag ska förbättra arbetet för mina syskon i Saab-familjen.

För dig som tror att teknik bara har med teknik att göra rekommenderar jag verkligen Peopleware. Då kommer du att inse att McDonaldsorganisationstankar inte funkar i kunskapsorganisationer. Kunskapsorganisationer kan mer liknas vid familjer där alla ser om varandra och hjälper varandra att växa. Är det någon i familjen som inte trivs tar vi hand om den personen och reder ut grundorsaken till misstrivseln. Låter det för flummigt får du gärna kämpa på med dina skygglappar ett tag till, men du är välkommen att diskutera bokinnehållet när du är redo.

Nu är det slut, nu får det räcka!

Jag fixar inte det här längre. Vart jag än frågar hör jag folk som hatar sin situation som programmerare. De drömmer sig tillbaka till de fåtal stunder de kan jobba ostört och producera det de utbildat sig ibland i tio år för att jobba med. På Saab, Motorola och Eriksson sitter programmerare oproduktiva av olika anledningar. Anledningar som är ledningens ansvar att ta tag i. Men istället lyssnar ledningen på ekonomerna som jagar synliga kostnader och struntar i arbetsmiljö eller produktivitet.

klicka igång lite musik nedan så får du rätt stämning när du läser resten.

Många struntar i det här och ibland kan jag känna att det är lika bra att vapentillverkning är dyrt, så att det inte blir så många vapen, men jag tänker inte svika alla programmerare som lurats in i tråkiga jobb med bra pensionsavtal. Tyck vad ni vill men i stor frustration och tårar i ögonen skrev jag ett kontrakt med mig själv:

"I have a dream! That one day will all corporate wage slaves be freed! They will be freed in a way that they love their jobs as mush as they loved coding in their youth!"

/Anders Holmberg

Mitt materiel håller!

I Gripen har en undersökning nyligen gjorts för att ta reda på olika förbättringsmöjligheter gällande system- och mjukvaruutveckling. När jag läste den igår gjorde vissa saker mig så arg att jag kokade men efter en härlig dialog med undersökningsledaren är vi så överens att jag ville krama om honom.

Utan att bryta sekretessen och lämna ut personer kan jag meddela att de flesta grundläggande problemen hittas med hjälp av det material jag tagit fram (se bilden), som bygger på The Joel Test. Det intressanta är att mitt test tar 5 minuter och att de andra lagt arbetsveckor på undersökningen. Deras resultat är så klart avsevärt mycket mer anpassat med konkreta lösningar på många stora och fluffiga problem, men mitt test kommer mer åt kärnan.

Efter mötet tackade både jag och undersökningsledaren för en väldigt givande diskussion och konstaterade att här finns oförskämt mycket pengar att spara. Coding is life!

Boktips: Joel on software

Här kommer ytterliggare ett boktips om en fantastisk bok för dig som jobbar med mjukvaruutveckling, design, management eller för dig som av lycka, eller otur, jobbar med sådant folk. Joel har jobbat några år på Microsoft som program manager för Excel, men sedan 2001 har han drivit bloggen som blivit de facto standard över utvecklingsbloggar.

Joel tipsar om när olika affärsmodeller funkar för olika mjukvaruuppstartsföretag. Han nämner mycket om kriget mellan kostymerna och jonerna, alltså management och programmerarna. Men framför allt nämner han The Joel Test som jag baserar Förnuftkonsult på. Hade fler företagsledare läst den här boken hade vi haft färre konkurser i IT-branschen.

Vill du ha en underhållande bok som ger fantastiska insikter som tar decennier att samla på sig annars är det här boken för dig!

Många självklarheter

REWORK är en läsvärd introbok för de som funderar över hur man kan jobba bättre. Den beskriver hur författarnas företag har klarat sig genom kriser och bubblor genom att behålla kärnan och inte sälja ut till investerare. Vill du förändra något konkret i din jobbsituation kan du välja lämpligt stycke på 1-2 sidor att visa din chef.

Förnuftkonsult Holmberg

Det är dags att outa drömmen jag firade med pizza för en månad sedan för idag damp min FA-skattsedel ner i brevlådan och jag har nu en registrerad konsultverksamhet. Målet är att hjälpa mjukvaruföretag att förbättra miljön för utvecklarna så att de kan fokusera på att skapa värde och tvätta bort alla hinder. Jag har material för att utvärdera befintlig miljö, jag har tips på nyttiga förbättringar. Jag hjälper utvecklarna att genomföra förbättringar själv. Det pratas mycket om lean och agile utveckling och andra knepiga begrepp som företag har svårt att ta till sig. Själv så läser jag allt som skrivs men praktiserar bara SBF: Sunt bonnförnuft.

Jag har fyrårig erfarenhet av samspelet mellan utvecklare och ledning och min styrka är att jag ingår i båda lagen och ser till helheten, inte bara verktyg, funktioner, planer eller kalkyler.

Stop being a cogworker

I den här boken förklarar Seth hur Motståndet får oss att fortsätta följa rutiner, förtrycka artisten i oss och att slava i fabrikerna. Vi är skolade att lyda order och att tänka som vi blir tillsagda. Känner du att du inte passar in i dagens slavarbete är det här en omvälvande bok för dig.

För mig blev det en "Den fula ankungen"-saga där jag äntligen känner att det finns fler som jag, fler som vill tänka själva och fler som vill göra skillnad. Läs inte boken om du är mitt i plugget, då är det för tidigt att få upplevelsen. Men lova dig själv att du läser den!

Förbättringsförslag 7: Informell dokumentation

Inom säkerhetskritisk mjukvaruutveckling är dokument en lika viktig leverabel som programmen. Vi har Subsystem Specification, Subsystem Technical Description, Software Requirements Specification, Software Detailed Description, Software Test Description, Subsystem Test Description för att nämna några. Inget av de här dokumenten är (primärt) till för att hjälpa utvecklaren att göra ett säkert system. De är till för att övertyga kund om att det är ett säkert system. Därför är dokumentation för programmerare lika sexigt som rapportskrivande för poliser.

Införs informell dokumentation där utvecklaren kan skriva ner sina tankar och skisser, buggar och arkitekturändringar, så kan detta vara underlag för den formella dokumentationen. Utvecklaren känner då ett mervärde i att dokumentera och risken för tankefel minskas.

Självklart är det utvecklarens ansvar att hålla reda på vad han gör för något men sparas inte denna informationen så försvinner den vid personalomsättningar och kvar finns bara en formell dokumentation som beskriver hur systemet fungerar, inte varför det gör det eller vilka luckor eller buggar som finns.

Förbättringsförslag 6: Släpp fram kreativiteten

Det finns en skröna om en snickare som insåg att ritningen på ett bygge inte fungerade, så snickaren ändrade så att det skulle funka. När arkitekten såg detta ringde han byggherren som sedan skällde ut snickaren efter noter. Snickaren försvarade sig med att säga att han tänkte att om han ändrar lite så kommer inte huset att trilla ihop. Byggherren svarade med: ”Du ska inte tänka, du ska bygga!”

Mjukvaruutveckling är en lika kreativ syssla som snickeri. Många olika idéer behöver prövas innan en bra lösning finns. Gamla tankar måste kunna rivas upp för att testa nya lösningar. Lyckas man inte på de timmar man förutspått behöver man lägga fler timmar. Och utvecklaren måste ha tillåtelse för detta, annars framkommer den farliga attityden: ”Du ska inte tänka, du ska programmera”.

Känner utvecklaren att han vill bra saker men får svårt att motivera dem kanske han väljer att göra dåliga saker som inte behöver motiveras.

Förbättringsförslag 5: Lär av andra

Ibland möts man av en ”Not invented here”-filosofi. Det kan handla om dataprotokoll, kravspårning, dokumentinnehåll eller helt vanligt arbete. Vi är glada ingenjörer som gillar att lösa problem, så när vi ser ett problem så löser vi det, med tillgänglig kunskap.

Tillåter du dina utvecklare att läsa facklitteratur några timmar i veckan kommer deras kunskap öka och de kan snabbare känna igen standardproblem och veta hur dessa ska angripas med standardlösningar.

Jag lägger ca 2h arbetstid och 5h fritid i veckan på att läsa in mig på det jag jobbar med. Utöver det läggs 2h av fikaraster att diskutera vad som har lästs under veckan. Det har gjort att jag tycker att arbetet är avsevärt mycket roligare, jag använder standardlösningar och standardarbetssätt. Jag har dessutom insett att de problem vi har idag inom mjukvaruutveckling är samma som fanns på 70-talet, så vi kommer inte att kunna lösa dem med stressade quickfixar. Lär av andra och du får en avsevärt bättre inblick i ditt eget arbete.

Förbättringsförslag 4: Rätt person på rätt plats

Det här inlägget kan innehålla brist på insikt, och det kan vara därför jag blir förvånad när vi anlitar personer som läst industriell ekonomi, skickar dem på kurs i Las Vegas, och sätter dem på att programmera grafik.

Det kan vara så att storföretag inte kan rekrytera den personal de önskar utan får nöja sig med "the best of what's left" och då är det arbetsplatsens image som arbetsgivaren får jobba på istället.

Men visst är det något konstigt när vi anställer tekniska doktorer inom matematik, ger dem en fyradagars C++-kurs och sätter dem på att programmera hårdvara i en produkt. Eller för den delen tekniska fysiker som läst två kurser programmering på universitetet och som får samma behandling. Jargongen i matsalen är ”nej jag jobbar verkligen inte alls med det jag är utbildad för”. Andra säger ”jag måste byta, jag kastar bort mitt liv på att göra fel saker”.

Steve McConnell och Fred Brooks förklarar i sina böcker att skillnaden på en bra programmerare och en dålig är en faktor 10. Det en bra programmerare åstadkommer på en timme behöver en dålig programmerare 10 timmar på sig. All heder åt den tekniske doktorn som är en stjärna inom sitt område, som han dessutom får lön efter, men det är nog okej att kalla honom en dålig programmerare. En bra programmerare med lägre utbildning blir glad för samma lön som doktorn får, så vi kan räkna på samma timpeng, säg 1000 kr/h. Det doktorn gör på en månad kostar 160 000 kr. Detta gör den duktige programmeraren för 16 000 kr. Alternativt kan du se det som om du anställer rätt person till jobbet kan du friställa 10 andra som gjorde jobbet på fel sätt. Skrämmande att inget händer?

Image: Paul Martin Eldridge / FreeDigitalPhotos.net

Förbättringsförslag 3: Skapa bästa möjliga förutsättningar

Du har anlitat de absolut bästa snickarna, målarna, murarna men bygget står nästan helt stilla. Projektledarna piskar förtvivlat hur mycket Riesen de än trycker i sig. Vad är problemet, du har ju de bästa förutsättningarna? Väl?

Har alla tillgång till ritningen?

Har alla tillgång till bra verktyg?

Har ni en uppdaterad arbetsplanering?

Fixar ni hittade fel innan ni bygger vidare?

Håller ni reda på hittade fel i en lista?

Om inte är det kanske inte så konstigt att det inte går framåt.

Samma frågor bör man ställa inom mjukvaruföretag, och Joel Spolsky har skapat ett enkelt tolvfrågetest för detta. Får du inte 12 poäng gör du det svårt för arbetarna att arbeta.

Projektet jag jobbar i nu får 3 poäng. Till sitt försvar måste jag säga att vi har precis startat mjukvaruutvecklingen och tillsätter testare och fixar daily builds tex. Men det är ändå en viktig indikation på att fokus bör ligga på att skapa bästa möjliga förutsättningar innan vi börja skapa bästa möjliga mjukvara.

Förbättringsförslag 2: Skaffa utbildning på verktygen

Det räcker inte att köpa in en avancerad skruvdragare. Om snickaren inte vet hur den ska användas kommer han nyttja den som en dyr hammare och slår i spik istället.

Det är ungefär vad som hände när vi tog ett beslut att använda Rhapsody för modellbaserad mjukvaruutveckling. Rhapsody har sin styrka i modellering och tillståndsmaskiner. I början visste vi inte hur vi skulle modellera eller använda tillståndsmaskiner. Istället började vi använda Rhapsody som en väldigt dyr och tämligen värdelös programmeringseditor. Det hade i princip gått snabbare att skriva koden för hand på ett papper.

Efter att ha gått en utbildning i verktyget (och lagt ca 100h på egen hand) kan jag arbeta riktigt effektivt och jag kan visa andra hur det ska gå till. Utan kursen hade jag fortfarande använt skruvdragaren som en hammare.

Förbättringsförslag 1: Skaffa bra verktyg

Ibland ser jag konstruktionskonsulter som kostar 1000kr/timme som har fått en 19" skärm och en långsam dator för det är standardutrustningen hos oss. De har inte möjlighet att synka kalendern med telefonen och får inte automatiskt tillgång till snabba servrar.

Jag satt 30 minuter med chefen när jag ville ha 20” istället för 19” som kostar 50kr/månaden. Utan att få det. Jag satt 40 minuter med chefen för att övertala att jag behövde ett program att klippa och klistra i PDF-er, som kostar 100kr/månaden.

I min tidigare karriär som snickare förundrades jag alltid över förmannen som köpte snordyra Hiltimaskiner, specifika för varje tillämpning. Varje skruvdragare hade minst två batterier. Ibland 3. Det gick hur snabbt som helst att jobba med alla dessa verktyg. Roligt var det också.

Ge utvecklarna de verktyg de behöver utan att de ska behöva tjata om det. De ska använda sin energi på att utveckla era produkter istället!

Tillägg i efterhand: Idag har jag en härlig 24" skärm, en superbra Dell-laptop i aluminium, en roller-mouse, höj-och-sänkbart skrivbord, fria arbetstider, ny flashig Sony-Ericssontelefon. Allt är top of the line och varenda dag när jag kommer till jobbet och ser min arbetsplats blir jag glad och känner inspiration. Företaget satsar på mig och då vill jag satsa på företaget!

Image: Michelle Meiklejohn / FreeDigitalPhotos.net