Enkla lösningar

februari 7, 2010

Jerry Weinberg har sagt att: ”Det finns inga svåra problem, bara svåra lösningar.” Som programmerare är alltså din främsta uppgift att hitta enkla lösningar på de problem du ställs inför.

Det finns en stark tro på att verklighetens problem kräver komplexa lösningar.
I själva verket beror den uppfattningen på att vi har för vana att välja tekniker som medför oavsiktlig komplexitet. Företagsstandarder, modeord och svag teknisk kompetens gör att vi väljer tekniker som inte är lämpade för de problem vi ställs inför. ”Här gör vi allt i Java!”, ”Vi löser alla problem med en SOA-lösning!” och ”Vi väntar till dess Microsoft släpper ett verktyg för det här!” hörs systemutvecklare säga, gärna med viss stolthet i rösten.

Själv har jag, bland annat, sett hur man lagt hela applikationer som lagrade procedurer i relationsdatabaser. Ovanpå detta har man kopplat GUI’n som går direkt mot dessa lagrade procedurer. Eftersom man uppfattat det som problematiskt att låta samma GUI-applikation gå mot flera databaser har man dessutom använt en välkänd integrationsprodukt för att kopiera data mellan databaser så att GUI-applikationerna kan få se det data som låg i den främmande databasen. Ibland handlar det bara om en boolesk variabel. En etta eller en nolla. En ensam liten bit. För åskådliggörandet av denna enda lilla bit definieras ett företagsstandardiserat protokoll som en XSD för att beskriva hur ettan (eller nollan) ska serialiseras till text (XML) som sedan ska skickas på en kö så att den kan läsas av en annan integrationsmodul för att av den kunna skrivas ner i den andra relationsdatabasen från vilken GUI-applikationen läser denna etta (eller nolla).

Så vill vi inte ha det. Vi måste lära oss att se att en lösning inte bär sin vikt. Vi får inte skapa lösningar som i sig är större problem än ursprungsproblemet.
Misslyckas man med det har man även misslyckats som systemutvecklare.

Agilt arkitekturarbete

januari 12, 2010

Under den långsamma övergången till ett agilt arbetssätt har en del av de traditionella rollerna och artifakterna visat sig vara problematiska. Inget arbete har stötts och blötts så mycket som arbetet med ”arkitekturen”. Frågan hur man arbetar med en arkitektur i ett agilt sammanhang är ganska knepig att besvara, men jag tänkte göra ett försök.

Arkitekturbegreppet

Ralph Johnson säger (fritt översatt) i Martin Fowlers artikel Who needs an architect:

Arkitekturen omfattar det som utvecklare anser viktigt för att kunna förstå hur systemet fungerar och kunna delta i vidareutvecklandet av det.

Vissa delar av arkitekturen är på låg nivå, andra på högre nivå. Om vi måste anpassa en produkt efter hur den integrerar med befintliga tjänster eller produkter är lösningen för det en del av produktens arkitektur, men även hur vi väljer att kommunicera mellan mindre komponenter inom vår produkt är en del av arkitekturen. På lägsta nivån är språkval och runtime-miljö även där en del av arkitekturen, med det inte sagt att den aspekten behöver vara enhetlig genom hela produkten men det är en arkitekturell aspekt på det vi gör. Kort sagt vi har arkitektur på alla olika nivåer av abstraktion.

Den agila ansatsen

I agila sammanhang är man mån om att man inte ska lita för mycket till gammal kunskap. Under utvecklandet av en produkt är vi i ständigt lärande. Den nya kunskapen vill vi, så fort det är möjligt, införliva i produkten. Därför försöker vi göra allt arbete kontinuerligt under utvecklandet. Kommer man till en situation med okända behov är det egetligen inte något problem, det tillhör det dagliga agila systemutvecklingsarbetet att utreda behov. På samma sätt förhåller det sig med arkitekturarbetet, vi kommer att vara tvungna att kontinuerligt se över vår arkitektur. En agil arkitektur ska svara mot de behov vi uppfyller nu, inte mot de vi kanske uppfyller imorgon, men inte heller mot de vi uppfyllde igår. Arkitekturen är på tok för viktig för att vi ska kunna nöja oss med att bara ägna den uppmärksamhet i början av utvecklingsarbetet.

Med det inte sagt att agila utvecklare inte kan tänka efter före. Många av dem jag känner gör en första, rimligt initierad, gissning innan de sätter igång med utvecklingsarbetet. De aktar sig bara för att tro att den initiala gissningen är rätt arkitektur och förbereder sig istället för att den ska kunna förändras.

Två skrån med olika fokus

Inom den agila rörelsen har det varit stort fokus på tvärfunktionella arbetslag som arbetar koncentrerat med en produkt och att låta arbetslaget gemensamt ta ansvar för det tekniska helhetsperspektivet för produkten.
Arkitektskrået har samtidigt rört sig längre bort från tekniken och man pratar om strategisk IT och verksamhetsutveckling. Här fokuserar man mycket på synergieffekter av olika integrationsstrategier och, i viss mån, verksamhetsmål med IT-förvaltning alltid sett över en hel produktportfölj. Där skiljer sig de åt, olika horisont och olika perspektiv.

Spekulativ och oavsiktlig design

Att dessa två, tillsynes välvilliga, rörelser har svårt att finna gemensam mark beror på följande problematik. De agila arbetslagen vill låta arkitekturen växa fram allt eftersom behoven manifesteras och de vill själva välja hur de tekniskt ska implementera de verksamhetskrav som framställs samtidigt som arkitektskrået gärna ser sig som ett kompetent tekniskt roder för hela verksamheten där de bidrar med tydliga riktlinjer för hur vissa aspekter av systemet ska implementeras.

Arkitekterna uppfattar här de agila utvecklarnas process som något som leder till en oavsiktlig design eftersom designen bara blir det som behoven påkallar. Agila utvecklare, å sin sida, tycker att det arkitekterna gör sig skyldiga till är spekulativ design som, allt som oftast, visar sig vara onödigt komplex och tungrodd.

Agilisterna uppfattar att arkitekterna fråntar utvecklarna designansvaret vilket leder till osäkerhet bland utvecklarna när man upptäcker svagheter i designen. Arkitekterna å sin sida tycker att utvecklarna inte är kompetenta nog att förvalta helhetsdesignen.

Det är alltså inte en argumentation om huruvida arkitekturkompetens är viktig eller ej – båda läger tycker att den är av avgörande betydelse. Konflikten ligger i hur den ska tillämpas.

Fördomarnas ursprung

För att förstå vad dessa ömsesidiga fördomar bottnar i måste man se till de olika grupperingarnas vardag. I lite mer traditionellt ledda systemutvecklingsorganisationer tillhör det god sed att uppmärksamma talangfulla programmerare och genast göra dem till arkitekter eller, t.o.m. projektledare (ja, jag har sett det hända). Kvar blir, generaliserat, oerfarna och mindre engagerade programmerare som inte har erfarenhet nog att själva fatta goda designbeslut. Faktum är att de ofta inte heller är kapabla att förstå och följa de direktiv som överlämnas från arkitekterna. För att komma till rätta med utvecklarnas tillkortakommanden har man typiskt en designfas. Ett par arkitekter samarbetar (i bästa fall) för att fixera grundtankarna i produktens arkitektur. Vikten av att tänka efter före är enorm – just eftersom man inte kan lita på att utvecklarna kommer att själva kunna förvalta designen aktivt.

I agila sammanhang ser det lite annorlunda ut, som talangfull programmerare blir man inte arkitekt, istället är den viktigaste uppgiften att agera designcoach och parprogrammeringspartner i arbetslaget. Kompetensen inte bara uppmärksammas, den anses t.o.m. så viktig att man inte vill isolera den till någon viss person. Man tar den initiala kostnaden för att sprida kompetensen eftersom man vet att det kommer att betala sig på kort tid. Faser finns inte inom agil utveckling, istället strävar man efter att kontinuerligt hålla uppmärksamheten på produkten som helhet.

Som vanligt kan vi konstatera att båda läger har kommit till en insiktsfull, men fördomsfull, slutsats baserat på den vardag man befinner sig i. Den stora skillnaden är att de agila arbetslagens vardag kan beskrivas som samarbetsorienterad och platt medan arkitekternas vardag baseras på en traditionell ledarskapssyn enligt command-and-control och top-down hierarkier.

Agila Sverige 2009

maj 13, 2009

Förra året hade jag, tillsammans med ett par goda vänner, förmånen att få arrangera en agil konferens om agil systemutveckling. Under två dagar träffades ca. 150 personer, från hela Sverige, i Stockholm för att utbyta erfarenheter via blixttal och open space.

I år återkommer konferensen och jag är stolt över att åter få stå som medarrangör. Ett huvudmål med konferensen är att vara tillgänglig. Det kostar bara 1000:- för två dagar inklusive en trevlig och god middag. Som deltagare kan man räkna med att få träffa engagerade och kunniga systemutvecklare som, mer än gärna, delar med sig av sina erfarenheter i drygt 50 blixttal och i ett 20-tal open space-sessioner. Förra året gavs deltagarna konferensen betyget 9,3 av 10. Kom och hjälp oss göra årets upplaga ännu bättre.

Jag arrangerar agila sverige 2009

Adaptiv startar

mars 25, 2009

Den 1:a april börjar jag på nytt jobb. Egentligen är det inget nytt jobb för jag kommer göra precis samma saker som tidigare. Agila införandeuppdrag och teknikkonsulting är det som jag gjort de senaste 5 åren och det är det jag kommer att fortsätta med. Det är snarare ett nytt liv. Joakim Holm, Johan Lind och jag kommer att tillsammans starta Adaptiv Sthlm AB (vi kallar det bara Adaptiv).

Det är naturligtvis spännande, roligt och stimulerande att få chansen att jobba med så duktiga medarbetare som Johan och Jocke, men jag tänkte ta tillfället att besvara de frågan som jag oftast får om detta.

Varför nu när krisen bryter över oss!?

Ptja, spelar det någon roll egentligen? Visst kan det bli så att krisen kan komma att pressa priser eller att man får gå någon månad utan uppdrag, men samma kris gäller ju även om man är kvar hos sin arbetsgivare. Dessutom är min uppfattning att kriserna blir mindre för mindre företag. Man behöver inte ta på sig några stora fasta kostnader och att hitta uppdrag åt tre seniora konsulter är betydligt enklare än att göra det åt 15 oerfarna.

Som konsulter med 10+ års arbetslivserfarenhet tror vi att det blir lättare för oss att märkas under en lågkonjunktur. Kostnadsskillnaden mellan en junior konsult och en seinor är skrattretande liten och vi kan visa på att vi kan utgöra en investering med hög avkastning vilket är det som efterlyses när marknaden är svag.

Även om det finns många fantastiskt duktiga och intressanta teknikgurus i Stockholm så är jag väldigt tacksam för att vi blev tre och att det blev vi tre. Det är tillräckligt svårt att hitta tider då alla tre kan ses och Johan och Joakim kommer att kunna stimulera mitt lärande under många bra år framöver. Det blir spännande att prova alla de mer eller mindre nya och galna idéer som vi har för företaget och jag hoppas på att vi kommer att få tillfälle att samarbeta med många andra mindre konsultfirmor i Sverige.

Ses!

Nytt kurstillfälle i TDD/BDD

februari 16, 2009

Tillsammans med Joakim Holm har jag, under hösten, arbetat hårt med att vidareutveckla vår kurs i TDD/BDD. Våra elever har varit nöjda med våra tidigare kurser, men vi har hela tiden ansträngt oss för att hitta nya och inspirerande sätt att lära utt TDD och BDD. En nyhet är att vi delat upp kursen i flera kurser som riktar sig till personer på olika nivå. Vi har en kurs för nybörjare, en för erfarna och en för experter. I vår nybörjarkurs har vi utökat tiden för praktik, för det går inte att lära sig TDD utan att få utföra momenten själv.

Om du eller någon du känner är intresserad så kan jag tipsa om att kursen för nybörjare kommer att ges publikt igen, 9-10 mars i Stockholm, i arrangemang av Jaybis. Den här kursen är lämplig både om man är helt ny på området eller om man är erfaren på enhetstestning men inte på TDD. Vi kör i javamiljö, men det är inte viktigt, vi har haft många dotnetutvecklare som har gått kursen utan problem. Under de två dagarna får du en inblick i hur experterna arbetar framgångsrikt med TDD/BDD. I viss mån innebär TDD/BDD en kunskap om rätt verktyg och hur och när man bör använda dem. Men det är också en samling relaterade arbetssätt och tekniker som kräver studier och övning för att bemästra. Vissa arbetssätt kan finslipas under en livstid. Sett ur ett ännu högre perspektiv är TDD/BDD en attityd, ett sätt att se på hantverket att utveckla goda system och produkter. Vi vill tipsa om verktygen, få deltagarna att prova arbetssätten och utstråla attityden.

Det här blir, tror jag, ett avsteg från mitt vanliga agilevangiliserande. Istället tänker jag summera lite tankar om den civiliserade människans relation till robotar.

Sedan en tid tillbaka har jag hört flera av mina vänner prata varmt om sina små dammsugarrobotar (Roomba från IRobot). De klarar trösklar, hittar till sin laddningsstation när den behöver ladda upp sig och kan dammsuga när ingen är hemma. Jag kände att det nog är en klassisk robottillämpning. Den befriar oss från en av veckans tråkigaste sysslor så att vi får mer tid för varandra.

Samtidigt har jag förundrats över den städmani som följt i dess spår, det verkar som att det finns ett extra intresse av att städa nu när det är en robot som utför sysslan. Först tolkade jag det som att man kanske alltid velat ha rent och fint omkring sig men att man hade saknat tiden för att leva upp till detta ideal, men nu har jag svängt över till en annan tolkning. Jag tror att dessa robotars ägare vill spendera tid med sin robot. Det verkar finnas en underliggande kärlek till roboten. Tydligast blir det när man hör dem säga: ”Idag hittade jag min Roomba intrasslad i en hög av sladdar klagandes på tyska, franska och engelska” eller: ”Igår såg jag hur Roomba närmade sig trappen, blev rädd och gav ifrån sig ett pip”. Eller en annan vän som nästan kärleksfullt deklarerade att han skulle Roomba-säkra sitt hem.

Kanske är det inte så konstigt att man utvecklar känslor för ett ting som lojalt ställer upp på att dammsuga när ingen är hemma?

Som av en händelse har jag sett ett antal TED-tal som handlade om hur våra liv kommer att förändras av robotar och påfallande många robotidéer verkar tala till vår förmåga till empati med dem istället för tvärtom. En av ideérna var en robot som gör allt det där som du saknar hos en partner när du separerat efter ett långt förhållande, tar täcket på natten, gnäller och tjatar på dagen… (talet på TED det jag refererar till är drygt 14 minuter in på talet).

Dessutom slog det mig att det här är redan ”old news”, vem minns inte tamagotchin? Tamagotchin som ter sig väldigt omodern i åsynen av den gulliga leksaksdinosaurien Pleo som är föremål för ett annat TED-tal.

Faktum är att även Roomba från IRobot har presenterats på TED och där har de påfallande intressanta klipp om hur vi kan komma att interagera med robotar baserat på våra emotionella kvaliteter.

Roboten kanske blir din ”low-maintenance-friend” när du inte har tid för riktiga vänner längre. Jag som trodde att vi skulle skaffa robotar för att få mer tid för varandra…

Sluta chansa

november 8, 2008

Det finns en ihärdig fördom runt lättrörliga metoder som säger att lättrörliga metoder är till för de slarviga. De som inte orkar tänka efter först, de som inte gillar att ta fram en genomtänkt systemdesign, de som inte vill dokumentera först utan bara slarva fram något utan att tänka efter först.

Även om det finns ett litet, litet korn sanning i det ovanstående så tänkte jag rikta ljuset mot de stora missförstånden istället.

Agila metoder ser gärna att man tänker till innan man börjar arbetet, men inte på bekostnad av att tänkandet under och efter arbetet. Med den komplexa problematik som vi ställs inför under ett utvecklingsarbete kan man inte kosta på sig ”lyxen” att bestämma sig återkalleligt för någonting innan implementationsarbetet är igång. Vi måste utnyttja all information vi har för att kontinuerligt fatta så bra beslut som vi kan.

Gårdagens eller dagens?

Tidiga beslut skänker en viss trygghet, men den tryggheten är bedräglig. Ofta kan beslut som fattats tidigt visa sina baksidor sent i projektarbetet och då måste vi vara förberedda på att omvärdera besutet. Har vi då istället byggt upp en projektkultur som säger: Först kommer den smarta gruppen att tänka, sedan ger de oss en design och efter det implementerar vi den, ignorerar man den lärdom som man förvärvar under projektarbetet och baserar då lösningen på gårdagens kunskap istället för dagens.

Man kan fortfarande säga att ”vi använder MySQL” eller ”vi implementerar det i Ruby” dag ett men man kan försöka fundera på hur man förhåller sig så neutral som möjligt trots de besluten. Vi kanske inte ska kasta oss över de specifika mysql-funktionerna innan vi verkligen behöver dem. Kanske ska vi välja JRuby för att kunna hålla oss mer öppna mot Java-världen?

Så det är inte en benägenhet att slarva som driver oss till att inte göra en alltför genomarbetad förstudie, det är vetskapen om att vi imorgon kommer att ha så mycket bättre förutsättningar för att fatta bra beslut.

Traditionellt har vi föredragit att dra till med en ”best guess” och kallat den en plan för att sedan bli mäkta irriterade när denna plan inte håller. Vi agila förespråkare säger: Sluta chansa, låt oss fatta de beslut som vi är kapabla att fatta för tillfället och vara förberedda på att omvärdera när vi vet bättre.

Skäms på dig hjälte!

november 3, 2008

Många är de gånger då jag har bevittnat hjältar i arbetssituationer. Folk som burit hela projekt på sina axlar. Folk att lita på, som får saker gjorda. De är projektledaranas gunstlingar. De hyllas som räddare i nöden och som värdefulla projektmedlemmar.
Det finns dock en baksida med dessa hjältedåd. De är det yttersta beviset på att du har en dålig dynamik i gruppen. För att bli en hjälte måste du nästan vara dålig på att samarbeta. Hade du varit bra på att samarbeta hade du snabbt lyft din omgivning till en nivå där du kanske inte varit en så tydlig hjälte. Däremot hade du varit orsaken till att ett högeffektivt team skapats.

Varje gång man ser en hjälte ska man fundera på vad som skulle kunna få denne hjälte att börja samarbeta. Varje gång du själv känner dig som en hjälte borde du fundera på vad du gjorde för fel.

Man bör vara tacksam för att man har duktiga medarbetare, men man ska skämmas om man är beroende av dem liksom de ska skämmas för att de inte samarbetar.

Att bilda de bildade

september 8, 2008

Vi behöver ett nytt sätt att se på högre utbildning av redan bildade systemutvecklare. Idag förutsätter vi att det alltid finns någon som kan skedmata oss med sin kompetens. Det är en strategi som främst är gångbar för oerfarna systemutvecklare, men när man som mer erfaren systemutvecklare ska fortbilda sig så är man, i hög grad, hänvisad till solitära självstudier.

Det finns uppenbara nackdelar med den här strategin.

Jag har tänkt göra ett, måhända fåfängt, försök att formulera en ny strategi, främst riktad mot högre utbildning av redan hantverksskickliga systemutvecklare. De idéer som jag formulerat, tillsammans med ett par av mina systemutvecklarvänner, bygger i mångt och mycket på konferensformen Open Space. Som så många andra framgångsrika strategier så bygger utbildningsformen på att:

  • Maximera samarbetet
  • Öka utbytet mellan olika kompetenser
  • Minska overhead-kostnaderna
  • Möjliggöra anpassning till snabb förändring

Först tänker jag redogöra för grundupplägget för utbildningsformen, sedan tänkte jag redovisa en samling vanor som jag tror kan komma att beskrivas som frivilliga ”best practices”. Sist tänker jag argumentera för hur formen löser de problem som idag finns med högre vidareutbildning av systemutvecklare.

Ett nytt upplägg

En utbildning modereras av en eller flera moderator(er).

Gruppen av deltagare får först en snabb förevisning om formatet på utbildningen.

Varje medlem i gruppen får sedan chansen att föreslå ett eller flera ämnen som man vill ta upp. Dessa ämnen presenteras inför gruppen och representeras av indexkort eller likn. på en tillgänglig vägg.

Sedan anmäler man sig till det ämnet som man helst vill arbeta med under den närmsta sessionen. Ämnen godkänns genom den acceptans som ämnet får när deltagare anmäler sitt intresse.

Den sista delen av sessionen håller varje grupp en kort presentation inför samtliga deltagare där man formulerar vad man lärt sig under sessionen.

Faciliterarnas roll är att se till att ingen grupp hindras av tekniska problem eller av att man inte begripit formen för utbildningen.

Rekommenderade vanor

Här följer ett par vanor som kan tjäna som insipration till den som utformar kurstillfällen.

Ämnesformuleringar

När man formulerar ett ämne så ska man formulera ämnen som man kan tänka sig att själv bidra aktivt till i imperativ (ex. ”Att skriva förvaltningsbara testfall.”). Om det istället är så att man har väldigt begränsade kunskaper i ämnet så kan man formulera sig som en fråga (ex. ”Hur skriver man förvaltningsbara testfall?”)

Gruppstorlekar

Om ämnet kräver programmering så bör inte större grupper än tre personer tillåtas. Bättre är då att dela upp de, exempelvis, 5 personerna i en grupp om tre och en om två personer. Sedan finns det ju inget som hindrar dem från att samarbeta nära mellan undergrupperna. Diskussionsämnen påverkas inte i samma grad, men det kan vara värt att även försöka hålla de grupperna mindre än sex deltagare så att alla känner att man hinner bidra och delta.

Sessionslängd

Man bör hinna med minst 5 sessioner på en dag där varje session tar ca. 90 minuter varav de sista 15 minuterna går till att presentera vad man gjort.

Tema

Inför en utbildning kan det vara bra att göra en grovsortering genom att slå fast ett tema ex. ”agil systemutveckling” eller ”systemintegration”.

Kalendarium

Utbildningstillfällen bör ges med förutsägbara intervall så att man kan som deltagare kan välja att förvarna sina uppdragsgivare om frånvaro.

Utrustning

Deltagaren ska själva ta med en bärbar dator alternativt, med god framförhållning, avisera att han/hon behöver låna dator för dagen.

Faciliteraren ska tillhandahålla trådlöst och trådat nätverk med internetanslutning.

Faciliteraren ska hålla med blädderblock, whiteboards, indexkort, post-its och lämpliga filtpennor.

Lokaler

Om akustiken är olämplig så bör flera rum tillhandahållas så att grupperna inte stör varandra.

Motivering till upplägget

Kunskapsnvåerna Shu, Ha, Ri lär oss att vi med stigande grad av bildning får en ny attityd till vårt kunnande och även nya förutsättningar för vårt lärande. Ett utbildningsformat som fungerar för en nybörjare fungerar inte nödvändigtvis för någon som redan hunnit fördjupa sig i ämnet och tvärtom.

Kollektivt ägarskap

Som redan bildad kan tid för reflektion tillsammans med andra bildade vara effektivt. Som nybörjare kan det mest verka förvirrande, då vill man istället ha handfasta recept på framgång. Dessutom har man som mer avancerad utvecklare börjat tillämpa egna vanor som kan vara intressant att få återkoppling på tillsammans med andra lika avancerade yrkesutövare. Det motiverar varför man inte ska ha lärarledd undervisning. Vi vill alla bidra och lära oss av varandra och när vi redan har tiotalet erfarna utvecklare samlade så är det slöseri att bara förlita sig på en eller två av dem.

Öppen agenda

Som engagerad utvecklare får man ständigt stimulans att prova nya verktyg, ansatser och attityder till att angripa välkända problem. Det som saknas är den där avsatta tiden då man i lugn och ro kan koncentrera sig på att leva ut de nya idéerna. Jag vill att den nya utbildningsformen ska fånga upp de aktuella intressen som man går omkring med. Därför är det av stor vikt att man har en öppen agenda för utbildningen. Vi vill bli av med attityden att läraren vet bättre vad du behöver lära dig än du själv.

Pris/prestanda

Kurser idag är tämligen dyra. Det är inte ovanligt att man får betala 10.000:- för en  endagsutbildning. För IT-konsulter som har en alternativinkomst på 1000:-/tim ger det en totalkostnad på ca. 18.000:-. En, inte obetydlig, del av det man betalar för är lärarens förberedelsetid. Med detta nya format krävs i stort sett ingen förberedelsetid alls. I princip borde man kunna komma ner i en kostnad på ca. 3000:-/deltagare och dag (11.000:- inklusive inkomstbortfallet) för en grupp om ca. 15 personer. Med en sådan kostnad är det rimligt att kunna ha råd med en tvådagarsutbildning minst två gånger om året.

Framtidssäker

Att kunna förändra kursen snabbt är en viktig framgångsfaktor. Genom att kursen utformas på plats och med hjälp av alla deltagares kunnande kan man garantera att kursen ständigt uppdateras med de senaste idéerna.

Noterbart

Kanske lite förmätet att tacka de som inspirerat till en blogpost men jag känner att jag vill sända ett stort tack till Peter Krantz och Niklas Lindström som förstod mitt hypomaniska tillstånd och snabbt avbröt sina respektive arbetsuppgifter för att ta en fika på Drottninggatan bara för att höra mig redogöra lite osammanhängade för min idé. Ett stort tack även till Joakim Holm som nästan missade sin tvättid för att ta sig tid att ge återkoppling på idén.

Till er tre: er respons var, som vanligt, klarsynt och mycket givande. Utan er hade min idé fortfarande varit luddig och ogripbar som ett cumulusmoln.

Tack även till Mats Oldin som var den som ställde mig frågan hur man ska utforma en utbildning som inte löper risken att bli inaktuell en månad efter att den tagits fram.

Noll fel

augusti 26, 2008

När jag gick min systemvetarutbildning så var man tydlig med att något som skulle kunna kallas buggfri programvara det finns inte. Även de enklaste av program är behäftade med buggar, helt enkelt för att även de är så komplexa.

Nu med agila (lättrörliga) metoder är noll fel en värdering och helt plötsligt anser vi att vi visst kan leverera buggfri programvara – hur kommer det sig?

Jag tänker försöka förklara vad vi menar med noll fel och sedan förklara i vilken utsträckning det idag är möjligt att komma dit.

Bugg eller brist

För att förstå hur vi kan börja tänka tanken på att leverera buggfri programvara så måste vi först fundera på vad en bugg är. En bugg i den här bemärkelsen är när programvara inte uppför sig som förväntat. En enkel variant skulle kunna vara att en svensk kalenderapplikation missar skottdagen eller att den tror att första dagen i veckan är en söndag (vilket är sant i många länder, men inte i Sverige). Detta skiljer sig från en brist som i kalenderapplikationen skulle kunna vara att man bara kan se innevarande månad. Många skulle idag kalla brister för buggar, men det tycker jag är konceptuellt fel. Att ha brister i programvara är ett normaltillstånd och allteftersom vårt användande utvecklas uppstår brister som vi kan välja rätta till i programvaran eller välja att leva med.

Med agil systemutveckling så har vi blivit väldigt duktiga på att uttrycka exakt vilket beteende som stöds av vår applikation. Alla de specifikationer i form av exekverbara tester som vi skapar under framtagandet av koden kan tala om för oss exakt hur vi kan förvänta oss att applikationen fungerar. Skulle något sätt att använda koden på vara odokumenterat så kan man säga att det beteendet inte stöds av applikationen.

Förutsatt att alla våra tester ”är gröna” så kan vi säga att vi inte har buggar i vår applikation, eventuellt har vi brister, men inte buggar.
Ok, då var det alltså klarlagt, vi kan ha noll fel. Nej, så enkelt är det inte.

Agila buggar

Först ett självklart undantag. När vi skriver våra exekverbara programspecifikationer så försöker vi helatiden göra det i så små isolerade enheter som möjligt, helt enkelt för att kunna ta så små och kontrollerade steg som möjligt. Skulle vi bara lita till de tester som vi har på lägsta nivå (och många gör det fortfarande) så kan vi inte uttala oss om hur de små enheterna fungerar tillsammans. Därför proklamerar agila metoder för att man ska låta de små testerna komma av större tester som baseras på användarscenarier. Men även för de lyckliga få som använder den typen av automatiserade scenarietester så finns små kryphål. Idag utvecklas nästan alla applikationer för användande på Internet. Det innebär att vi är många användare som samsas om appliktionsresurserna. Även tämligen avancerade scenarietester kan komma att missa konsekvensen av väldigt många samtidiga användare och det gäller inte bara prestanda utan även logiska fel som i hanterandet av tillstånd. Att hantera tillstånd trådsäkert är inte svårt i sig men misstag är svåra att upptäcka. Klart mest problematiskt är dock det faktum att våra specificerande tester bara tjänar som exempel på användandet. Vi kanske tror att vi har kommunicerat all funktionalitet när vi i själva verket har missat delar, eller missförstått i det tysta. NLP lär oss att det kan bero på att vi inte lyckats avtäcka de djupstrukturer som döljer sig bakom beställarens ord alternativt att vi omedvetet väljer att förstå beställningen på ett sätt som är felaktigt för att det förenklar lösningen.

Ögonbrynshöjare

Sammantaget får vi nog vänja oss vid att, även i framtiden, se buggar dyka upp i våra applikationer. Min erfarenhet säger mig dock att buggar kommer att vara ögonbrynshöjare. Vi kommer inte behöva buggrapporteringssystem där vi registrerar de hundratals buggar som upptäcks under användandet. Istället kan en whiteboard med uttrymme för 1 – 10 buggar noterade på Post-Its eller indexkort vara tillräckligt.

Följ

Få meddelanden om nya inlägg via e-post.