Parprogrammering i praktiken

2006-06-05 Parprogrammering i praktiken Abstrakt: IT-branschen är just nu starkt på frammarsch och det talas om en brist på erfarna systemutvecklare. Det är dock svårt för nyutexaminerade att få dessa jobb då de saknar yrkeserfarenhet. I denna uppsats undersöktes möjligheten om parprogrammering kan vara en genväg för en oerfaren praktiker att komma in i en verksamhet och på så sätt bli mer attraktiv på arbetsmarknaden. Parprogrammering är en utvecklingsmetod där två programmerare jobbar med samma kod vid samma dator. Detta påstås generera ett antal synergieffekter som på ett positivt sätt påverkar utvecklingen och utvecklaren. Uppsatsen bygger på en kvalitativ studie av ett case baserat på ett verkligt utvecklingsprojekt med oerfarna praktiker på ett större företag. Studien visade på att alla synergieffekterna som uppstod med parprogrammering direkt eller indirekt påverkade den oerfarne programmeraren på ett positivt sätt i en professionell kontext. Nyckelord: Parprogrammering, Extreme Programming, Systemutveckling Författare: Albert Örwall, Karl-Fredrik Ottermark Handledare: Urban Nuldén Examinator: Lennart Petersson Magisteruppsats, 20 poäng

Innehållsförteckning 1 INLEDNING... 1 1.1 PROBLEMOMRÅDE OCH SYFTE... 1 1.2 BAKGRUND... 2 1.3 AVGRÄNSNING... 2 1.4 DISPOSITION... 2 2. SYSTEMUTVECKLING... 3 2.1 EXTREME PROGRAMMING... 4 2.1.1 XP's tolv praxis... 5 2.2 PARPROGRAMMERING... 7 2.2.1 Synergieffekter av parprogrammering... 7 2.2.2 Nackdelar med parprogrammering... 10 2.2.3 Olika parkonstellationer... 11 3. TEORI... 14 3.1 REFLECTIVE PRACTIONER... 14 3. 2 TYST KUNSKAP... 15 3.2.1 Överföring av tyst kunskap... 15 3.3 COMMUNITIES OF PRACTICE... 17 3.3.1 Hur en community of practice verkar... 18 3.3.2 Skepnader... 20 3.3.3 Struktur... 20 4. METOD... 21 4.1 VETENSKAPLIGT SYNSÄTT... 21 4.1.1 Kvalitativ metod... 21 4.2 PRAKTISKT TILLVÄGAGÅNGSSÄTT... 21 4.2.1 Case... 21 4.2.2 Dagböcker... 22 4.2.3 Analys... 23 5. RESULTAT OCH DISKUSSION... 24 5.1 ITERATION ETT... 24 5.1.1 Iteration ett sedd ur synergieffekternas perspektiv... 25 5.2 ITERATION TVÅ... 27 5.2.1 Iteration två sedd ur synergieffekternas perspektiv... 28 5.3 ITERATION TRE... 30 5.3.1 Iteration tre sedd ur synergieffekternas perspektiv... 32 5.4 ITERATION FYRA... 33 5.4.1 Iteration fyra sedd ur synergieffekternas perspektiv... 35 5.5 SAMMANBINDANDE DISKUSSION... 36 6. SLUTSATS... 40 6.1 Studiens svagheter... 40 6.2 Vidare forskning... 41 7 REFERENSLISTA... 42 7.1 Böcker... 42 7.2 Artiklar... 43 7.3 Tidningsartiklar... 43 7.4 Webbaserade källor... 43 BILAGA: SYSTEMDOKUMENTATION... 43 ii

Figurförteckning FIGUR 1: NONAKAS KUNSKAPSSPIRAL... 17 FIGUR 2: ÖVERSIKTSBILD AV EN COMMUNITY OF PRACTICE... 20 iii

1 Inledning I detta kapitel presenteras problemområdet och syftet med uppsatsen. Vi försöker även kortfattat beskriva bakgrunden till studien samt avgränsning på frågeställningen och en beskrivning av disposition. 1.1 Problemområde och syfte Det är idag brist på kompetenta systemutvecklare på arbetsmarknaden (Brundin, 2006) men det är svårt för nyutexaminerade från universitet och högskolor att få dessa jobb (Westerholm, 2006). Det beror till stor del på att nyutexaminerade systemutvecklare inte har de kunskaper och den erfarenhet som krävs; de är nybörjare. Erfarenhet tar givetvis tid att bygga upp och det är också viktigt hur det görs. En vanlig form för detta är att nybörjare får lära sig av någon som är mer erfaren, en mentor. I en sådan relation delar den erfarne personen med sig av sina kunskaper och erfarenheter till den andra personen. Detta sker ofta situerat i den specifika praktiken som mentorn behärskar. I denna studie fokuseras intresset istället på hur två nybörjare kan stötta varandra i processen att bygga upp kunskap och erfarenhet. Denna studie undersöker därför om parprogrammering kan vara användbar teknik för att snabbare komma in en verksamhet och där igenom bli accepterad som en kompetent utvecklare. Parprogrammering är en del av Extreme Programming (XP) som innebär att två utvecklare jobbar tillsammans med samma uppgift vid samma dator, men med olika roller. Den ena personen fungerar som "förare" och skriver koden medan den andra blir en "navigatör" som sitter bredvid och granskar koden. Meningen är att föraren skall tänka kortsiktigt och fundera över de praktiska problem som finns just för stunden, medan navigatören skall förhålla sig mer strategiskt till det föraren skriver. De växlar sedan plats vid lämpliga tillfällen, så navigatören tar över förarens roll och vice versa (Willams & Kessler, 2002). Parprogrammering sägs generera sju väsentliga synergieffekter; press, dialog, självförtroende, granskning, felsökning, lärande och förtroende (Williams & Kessler, 2002). Med problembeskrivningen ovan och dessa sju synergieffekter formuleras följande forskningsfråga: Kan parprogrammeringens sju synergieffekter vara till fördel för nybörjare i en professionell kontext? 1

1.2 Bakgrund För att svara på forskningsfrågan har ett mindre utvecklingsprojekt med två nybörjare studerats och analyserats. Projektet genomfördes nära andra projekt med mer erfarna utvecklare på uppdrag av AstraZeneca. De två nybörjarna är även författare till denna rapport så utvecklingsprojektetet har fungerat som ett case för att: dels kunna studera och analysera sin egen praktik, och dels för att kunna svara på forskningsfrågan. Det fanns ett behov av att tillämpa en systemutvecklingsmetod för att kunna arbeta på ett professionellt sätt. XP var då det självklara valet. Parprogrammering är redan en integrerad del av metodologin och det är anpassat för mindre projektgrupper. 1.3 Avgränsning Studien är enbart inriktad på hur parprogrammeringens synergieffekter kan påverka nybörjare i en nybörjare-nybörjare parkonstellation. 1.4 Disposition I kapitel ett presenteras problemområdet och en kortare bakgrund till undersökningen. I kapitel två presenteras och beskrivs de utvecklingsmetoder vi utgått ifrån i vårt case; XP och parprogrammering. I kapitel tre presenteras de teorier vi använt oss utav för att analysera resultatet av studien. I kapitel fyra presenteras den metod vi valt att använda för att angripa frågan. Därefter följer en beskrivning av vårt praktiska tillvägagångssätt; att studera att case och samla in empirisk data genom dagböcker. I kapitel fem presenteras resultatet från den åtta veckor långa undersökningen uppdelat i fyra iterationer, samt diskussioner kopplade till parprogrammeringens sju synergieffekter. I kapitel sex presenteras slutsatser från undersökningen, självkritik samt förslag på vidare forskning. 2

2. Systemutveckling Detta kapitel förklarar behovet av en systemutvecklingssmetod och går igenom metoden XP i allmänhet och dess praktik parprogrammering i synnerhet. När man utvecklar komplexa system eftersträvar man att hålla en viss struktur över utvecklingen för att säkerställa kvalitén på det färdiga systemet. Man utgår därför från en systemutvecklingsmetod. En systemutvecklingsmetod beskriver hur något i utvecklingsarbetet ska utföras. Man kan beskriva det som en samling tillvägagångssätt, tekniker, verktyg och dokument som syftar till att understödja projektgruppen vid utvecklingen av system. På grund av att dessa praxis är gemensamma för alla i gruppen ökar förståelsen mellan de inblandade då alla talar samma språk. Det finns ett flertal olika tillvägagångssätt och man kan dela in metoderna i olika subkategorier beroende på specifika egenskaper. Vanligast är att jämföra hur livscykeln ser ut i metoden, då kan man särskilja tre distinkta skillnader, vattenfallsmetoder, iterativa metoder och anpassningsbara metoder. I en vattenfallsmetod radar man upp alla delar i systemutvecklingslivcykeln och börjar inte på nästa process förrän den förra är färdig. Detta leder till att man först analyserar, sedan designar, implementerar och testar systemet. I vattenfallsmetoden finns ett stort behov av en korrekt analys, då det blir dyrt om man inte upptäcker brister i analysen förrän i slutstadierna av utvecklingsprojektet. I en iterativ metod går man likt vattenfallsmetoden i en trappa, men återgår till tidigare steg under utvecklingsprocessen. Slutligen finns de anpassningsbara metoderna som anpassas under arbetets gång och inte ställer samma krav på en grundläggande design och kravdokumentation. Genom den stora flexibilitet det ger passar dessa metoder bäst i mindre projektgrupper, medan iterativa metoder som till exempel RUP lämpar sig bättre i större projekt där man behöver ett mer strukturerat tillvägagångssätt. [1] Utvecklingsarbetet som ligger till grund för det case som studeras i denna rapport utfördes i en väldigt liten projektgrupp. Det fanns också krav på utvecklingsarbetet att kunna anpassa sig under arbetets gång, utefter användrepresentantens krav och de lärdomar man erhåller från omgivningen. Därför valdes en anpassningsbar utvecklingsmetod, nämligen Extreme Programming. 3

2.1 Extreme Programming Extreme Programming är en anpassningsbar programutvecklingsmetodik baserad på agile manifesto och utvecklad av Kent Beck. Agile manifesto kännetecknas av att utveckla program i små iterationer, oftast endast mellan två och fyra veckor. Med iteration menas en upprepning, under ett specifikt tidsintervall, där ett visst antal regler följs för att förfina systemet, exempelvis kravanalys, design, kodning, testning och dokumentering. Meningen är att man ska kunna släppa en buggfri release efter varje iteration. [2] Anledningen till namnet XP är att man använder sig av redan existerande och beprövade praxis men för dem till extrema nivåer. Man försöker använda dem hela tiden under utvecklingsarbetet, till exempel granskar man koden hela tiden (parprogrammering), testar koden hela tiden (enhetstest), designar om systemet hela tiden (omfaktorisering) osv. Allt för att få till en så kvalitativ kod som möjligt och för att slippa tidskrävande och dyrt efterarbete med buggrättningar och omspecificeringar av systemet (Beck, 2000). Beck (2000) liknar den anpassningsbara utvecklingsmetodologin med att köra bil. Det handlar inte om att sikta in bilen mot ett mål och sedan köra, utan det handlar om att hela tiden vara uppmärksam och göra små korrektioner, svängar. På samma sätt fungerar anpassningsbara utvecklingsmetodologier, man ska hela tiden ha möjlighet att ändra planeringen efter hur kundkraven förändras. Beck (2000) beskriver XP som en utvecklingsmetodologi med tolv olika praxis som grundar sig i de fyra värderingarna kommunikation, enkelhet, feedback och mod. Kommunikation Problem i mjukvaruutvecklingsprojekt beror ofta på dålig kommunikation. För att främja en bra kommunikation bland deltagare i ett projekt har man flera aktiviteter i XP som är beroende av just detta. Effekten av aktiviteter så som enhetstestning och parprogrammering är att programmerare, kunder och ledare måste kommunicera. Enkelhet XP uppmuntrar att man hela tiden ska göra den enklast möjliga lösningen. Beck menar att det är bättre att göra den enklaste lösningen för idag och möjligen betala mer imorgon för att ändra den om det behövs, istället för att göra en komplicerad lösning från början som kanske aldrig kommer användas. 4

Feedback Med feedback syftar man på feedback i olika nivåer av utvecklingsprojektet. Genom att skriva enhetstest kan programmeraren få omedelbar feedback på hur bra koden fungerar. När kunden lämnar beskrivningar på önskade funktioner kan programmerarna värdera dem så kunden kan få konkret feedback på kvalitén på sina beskrivningar. Mod Många av aktiviteterna i XP kräver mod. Man menar att det är viktigare att kunna ändra en plan än att följa en plan. Till exempel att man ska designa och koda så enkelt som möjligt för de behov man har just för tillfället, men ändå vara medveten om att man kan bli tvungen att ändra designen - eller i värsta fall kassera den - dagen efter. 2.1.1 XP's tolv praxis Följande är de första tolv praxis som XP baseras på (Beck, 2000), utöver dessa så har det tillkommit tolv ytterligare praxis på senare tid. Men dessa anses mer som ett komplement än obligatoriska, därför kommer vi att utesluta dem här. Vi har valt att, i den utsträckning som går, använda de svenska översättningarna som arbetats fram på den svenska XP-wikin OopsWiki[3]. Planeringsspel Planeringsspelet kan ses som en strukturerad förhandling mellan användarrepresentanten och programmeringsteamet. Kundens ansvar är att skriva ner korta beskrivningar på de funktioner han/hon vill ha i systemet. Programmeringsteamet uppskattar sedan tidsåtgången och kunden bestämmer prioriteringen för dessa, vilket gör att man sedan kan placera dem i iterationer. Små releaser Varje release ska vara så liten som möjligt och bara innehålla de viktigaste affärskraven. Detta betyder dock inte att man bara går halvvägs i att implementera en funktion för att göra releasecykeln kortare, releasen måste ha ett vettigt innehåll för helheten. Metafor Att kunna skapa en metafor för hela systemet, som beskriver i helhet hur det fungerar. Enkel design Den rätta designen ska följa fyra enkla regler. 1. Hela tiden kunna köras och godkännas i alla test 2. Inte ha återkommande logik 3. Ha med alla intentioner som är intressanta för programmerarna 5

4. Ha så lite klasser och metoder som möjligt. Det är viktigt att alla delar i designen kan uppfylla dessa krav. Med andra ord ska designen göras så enkel som möjligt utan att inkräkta på de tre första reglerna. Testning XP uppmuntrar programmeraren att skriva enhetstest med alla testfall som kan tänkas finnas innan han/hon skriver koden. Det är även meningen att kunden själv skall kunna skriva funktionstest för att testa de funktioner man tänkt ha systemet till. Omfaktorisering Omfaktorisering handlar om att ändra den ursprungliga designen i ett program för att enklare kunna lägga till en ny funktion men ändå kunna köra alla test. Målet är att i längden ha en så enkel kod som möjligt. När samma kod återkommer två gånger i programmet är det tid för omfaktorisering. Parprogrammering Parprogrammering är när två programmerare utvecklar samma kod tillsammans vid samma arbetsplats, vilket närmare gås igenom i nästa kapitel. Kollektivt ägande Alla ska äga all kod i systemet tillsammans, vilket innebär att alla tar ansvar för hela systemet. Meningen är inte att alla ska känna till allt om alla delar i systemet, men alla ska veta något om varje del. Om ett par ser en möjlighet att förbättra koden i en del av systemet så ska de ges möjlighet till detta. Kontinuerlig integrering Systemet ska integreras och testas minst en gång varje utvecklingsdag. Detta fungerar bäst genom att ha en server dedikerad till just detta, där man kan ladda in sina nya funktioner eller förändringar i koden och testa dessa tills allt stämmer. 40-timmarsvecka Meningen med detta är inte att jobba exakt 40 timmar varje vecka, utan att man ska ges möjlighet till fritid så att man kan återhämta sina krafter. Anledningen är att man omöjligt kan hålla uppe sin kreativitet, noggrannhet och självkänsla efter att ha arbetat väldigt mycket övertid flera veckor i sträck. Kund på platsen En riktig kund, slutanvändaren, måste sitta med programmeringsteamet och vara tillgänglig för att svara på frågor, lösa dispyter och bestämma mindre prioriteringar. 6

Kodstandarder För att programmerare ska kunna jobba med helt olika delar i systemet, byta partner ofta och omfaktorisera varandras kod så är det viktigt att ha en kodstandard. En kodstandard innebär att alla utvecklare skriver kod på ett liknande sätt, meningen är att det ska vara omöjligt att urskilja vem som skrivit en viss kodsnutt. 2.2 Parprogrammering För att få en klar definition av parprogrammering i denna studie utgås det ifrån den beskrivning Williams och Kessler gör i sin bok Pair Programming Illuminated (2002). Man kan kortfattat säga att parprogrammering går ut på att två programmerare sitter vid samma dator och jobbar med samma design, kod och test. Den ene programmeraren, skriver koden och tänker över de praktiska problem denne ser just för stunden medan den andre, sitter bredvid och observerar kodskrivandet och försöker tänka ur en mer strategisk synvinkel, om lösningen kommer fungera i längden, finns det onödig komplexitet som kan tas bort etc. Man brukar kalla den person som skriver för förare (driver) och den som sitter bredvid för navigatör (navigator). Genom att jobba med samma kod får man en gemensam uppfattning av kodlogiken som i sin tur ska leda till att det blir lättare att uppfatta felaktigheter i koden och man får en klarare bild över i vilken riktning arbetet är på väg. När det låser sig för föraren som sitter vid tangentbordet, eller navigatören får en idé hon lättast kan formulera i kod, så byter man roller och får på detta sätt ett dynamiskt flöde i rollbytandet. 2.2.1 Synergieffekter av parprogrammering Willams och Kessler (2002) hävdar först och främst att parprogrammering ger sju synergieffekter; press, dialog, självförtroende, granskning, felsökning, lärande och förtroende. Press Den första av dessa är pressen att prestera två personer känner när de jobbar tillsammans. Man vill inte göra den andre besviken utan man vill prestera sitt bästa för att göra ett gott intryck. Man tenderar att inte göra så mycket onödigt kringarbete, till exempel ringa långa samtal, skriva och svara på e-mail och ta långa fikapauser. I och med att man förkortar dessa små tidsödare så hamnar man lättare i ett flow av effektivt programmerande, för att styrka detta påstående hänvisar Willams och Kessler till en studie av DeMarco T. och Lister T. (1987) där det bevisas att 7

programmerare som har en förmåga att ta bort dessa störande moment är upp till elva gånger mer produktiva än de som har dem kvar. Även det faktum att man sätter upp klarare mål för när man ska vara färdig gör arbetet effektivare, har man till exempel bara två dagar på sig att göra det man ska i paret innan man byter programmeringspartner så kommer man att vara klar med jobbet inom den tidsramen, jämfört med om man skulle jobba själv och då har mer flytande tidsramar. Som stöd för detta hänvisar Willams och Kessler till Parkinsons Lag vilken säger att arbetet anpassas efter den tid som finns till förfogande. 1 Dialog Den andra synergieffekten av parprogrammering är nyttan av att ha en dialog med någon annan när man programmerar, vilket ska leda till bättre fattade beslut. Willams och Kessler hänvisar sina teorier till en teori inom psykologin kallad distribuerad kognition, och specifikt från en studie av Flor N. V. och Hutchins E. L. 2 De kunde sätta utmärkande verbala och ickeverbala beteenden, av två parprogrammerare, i samband med kända distribuerade kognitionsteorier med vilka man enligt utsago ska bearbeta information effektivare i paret. För att bevisa att deras påståenden även är statistiskt vedertagna så hänvisar de till en studie av Michaelsen et al. (1989) som studerade 222 grupper involverade i 25 organisationsbeteendekurser. Först fick alla utföra varje test individuellt för att sedan utföra samma test gemensamt. Alla 222 grupper presterade bättre än deras genomsnittsmedlem och 215 grupper fick bättre resultat än deras bästa medlem. Självförtroende Tredje fördelen med parprogrammering är att man får bättre självförtroende när man programmerar i par. Om paret hela tiden ställer frågor angående deras tillvägagångssätt sinsemellan får frågeställaren bekräftelse om att det hon gör är riktigt, något som i sin tur leder till bättre självförtroende. Bättre självförtroende leder till att den enskilde kodaren vågar sig in på sådant som denne inte skulle vågat angripa eller undvikit sen tidigare. Willams och Kessler argumenterar för detta genom att jämföra med en lärares erfarenhet från att ge en klass en svår uppgift vilken de ska lösa individuellt; när läraren ber om svaret är det oftast bara ett par elever som räcker upp handen. Ställer däremot samme lärare samma fråga men ber eleverna att dela upp sig i par för att lösa frågan kommer nästan alla vara villiga att svara på frågan. Detta 1 Parkinson C. N., Parkinson s Law: The Pursuit of Progress (London: John Murray, 1958) refererat i Willams & Kessler, 2002 2 Flor N. V. och Hutchins E. L., Analyzing Distributed Cognition in Software Teams: A Case Study of Team Programming During Perfective Software Maintenance. Empirical Studies of Programmers: Fourth Workshop, (1991), 36-63, refererat i Willams & Kessler, 2002 8

därför att man resonerat fram ett gemensamt svar. Man känner sig då mer självsäker när man har en till person som resonerat likadant som en själv att falla tillbaks på. Granskning Fjärde punkten på Willams och Kesslers lista över fördelar med parprogrammering är att koden hela tiden går igenom granskning per automatik av personen som inte skriver kod och ger liknande effekt som en officiell inspektion skulle ge (Fagan M. E, 1976). Koden blir då automatiskt mer felfri än om den skrivits av enbart en person. The human eye has an almost infinite capacity for not seeing what it does not want to see. ( ) Programmers, if left to their own devices, will ignore the most glaring errors in their output-errors that anyone else can see in an instant (Weinberg G. M., 1998). Med andra ord ska fyra ögon vara bättre än två då de mest uppenbara felen uppmärksammas vid ett tidigare skede av utvecklingen. Felsökning Femte synergin som förklaras är fördelen när man debuggar en kod i par. Att förklara en buggig kodsnutt för någon annan brukar per automatik ofta leda till att man själv ser felet innan man hunnit förklara hela koden (Kerninghan B.W. & Pike R.,1999). Är personen med en hela tiden kan denne se problemet ur andra synvinklar och kommer då kontinuerligt att ställa frågor som den andre måste svara på, vilket ofta leder till att svårfångade buggar uppdagas lättare enligt Willams och Kessler. Lärande Som den näst sista fördelen med parprogrammering nämner Willams och Kessler lärandet i par. Något som de hävdar ger större fördelar än om man utvecklas enskilt. Antingen turas paret om att vara lärare och elev, så att de lär sig den andres kunskaper, till och med tysta kunskaper och beteende ska utväxlas mellan paren (Cockburn A. & Williams L., 2001). Eller så är situationen sådan att den ene i paret är nybörjare inom området och kan då kan då ta rollen som elev eller lärling till den mer erfarna i paret, eleven får då en aktiv deltagande roll i lärandet och lär sig effektivare (Lave J. & Wenger E., 1991) än om denne skulle bara ha suttit i en skolbänk. Förtroende Sjunde och sista fördelen med parprogrammering enligt Willams och Kessler ska vara det förtroendet som utvecklas sinsemellan par när de jobbar ihop. Gruppsamhörigheten som uppstår ska göra att man öppnar upp sig mer för andras kunskaper och erfarenheter och slutprodukten blir upplevd som något avsevärt mycket bättre än något som man som ensam individ ha kunnat skapa. 9

2.2.2 Nackdelar med parprogrammering Det finns ett antal nackdelar med parprogrammering som är nämnvärda (Williams & Kessler, 2002). Beroende En av nackdelarna med parprogrammering är att när man väl börjar är man väldigt beroende av sin partner. Blir man frånvarande på något sätt, på grund av till exempel sjukdom eller möten, så har man en tendens att inte göra något arbete alls under dennes frånvaro för att man inte vill göra något utan partnerns godkännande. Schemaläggning Ger man en person en uppgift och en deadline kommer denne person lätt kunna lägga upp arbetet själv och jobba när han/hon själv vill. Är man två blir det direkt mer problematiskt att försöka anpassa sina scheman runt sin partners preferenser och det blir ännu mer komplext ifall man byter partner ofta. Närvaro vid samma tid Vissa personer vill till exempel börja sent på morgonen för att jobba längre på kvällen medan andra vill börja tidigt för att komma hem tidigt till sina barn. Vissa gillar att jobba hemifrån när de kan. Om man startar upp ett projekt och ska använda sig av parprogrammering kommer projektdeltagarnas arbetstider bli en het potatis och man måste hitta en balans mellan parprogrammering och verksamhet som inte kräver parprogrammering för att inte förlora projektdeltagare. Ljudnivån Effektiva parprogrammerare som jobbar ihop låter. En livlig dialog är att föredra och skapar bra kommunikation i paret. Detta kan dock vara störande för omgivningen ifall paret sitter i ett kontorslandskap med andra runt omkring sig. Koncentration Vissa personer klarar inte av att uppnå samma nivå av koncentration och kreativitet när de jobbar i par. Willams och Kessler erkänner att alla personer inte fungerar i en renodlad parprogrammeringsmiljö men anser ändå att man ska ha en partner som man visar sina idéer för som kan ge en feedback och kanske ser alternativ de inte själva har uppfattat. Meningsskiljaktigheter Meningsskiljaktigheter uppstår alltid när man jobbar ihop och går sällan att undvika ifall man ska fungera bra i par. Willams och Kessler anser att man bör ta itu med problemen efter att man gett varandra lite lugn och ro var för sig. 10

Självsäkerhet Willams och Kessler påstår att ett par som jobbar ihop lätt kan uppleva att vad de än gör så är det rätt. Vilket inte alltid är säkert. Är man inte grundlig och försiktig kan flera veckors arbete vara till ingen nytta. Kunskapsskillnader Den ideale lagspelaren vet att det bästa för laget är att få upp alla till samma kunskapsnivå. Men alla människor har inte det tålamodet som krävs för att låta någon annan lära sig av dem. För att parprogrammering ska fungera effektivt måste den som innehar mest kunskap låta sin partner få skriva mesta delen av tiden så att hon kan lära sig genom att deltaga och inte bara sitta och se på, enligt Willams och Kessler. Samtidigt måste den mindre erfarna vilja lära sig för att få någon nytta av parprogrammeringen. Något som inte fungerar för alla Alla personer vill eller kan inte jobba i par på grund av sin personlighet. Till exempel klarar inte en för självcentrerad person att parprogrammera eller så kan exempelvis en egocentrerad person känna sig hotad att blotta svagheter för en partner. Parprogrammering kräver mycket tålamod och en öppenhet och ett tålamod inte alla har eller klarar av att uppmana. Andra nackdelar med parprogrammering som till exempel har framförts av Pete McBreen i boken Questioning Extreme Programming (2003), är bristen på vetenskapliga undersökningar om parprogrammering i en verklig produktionsmiljö. McBreen menar att om man ser mjukvaruutveckling som en automatiserad uppgift kommer parprogrammering bara vara ett slöseri med resurser då två personer jobbar med samma uppgift. Denna mekaniska metafor dominerar mjukvaruutveckling enligt McBreen P. (2002) och det är en öppen fråga om när den kommer att upphöra. 2.2.3 Olika parkonstellationer Anledningen vi tar upp olika parkonstellationer är för att det kan ha en stor påverkan på hur väl parprogrammeringen utfaller (Willams & Kessler, 2002). Vissa personer passar sämre med varandra än vad andra gör, beroende på personlighet och erfarenhet. Detta kan enligt Willams och Kessler kompenseras och vi kommer även att ta upp hur de anser att detta ska göras. 11

Följande är de vanligaste parkonstellationerna som kan uppstå: Nybörjare - Nybörjare Nybörjare parade med varandra är en parkonstellation som bäst passar när det handlar om en enkel bit i ett projekt där man ändå behöver utbilda oerfaren personal. De påstår att nybörjare parade med varandra lär sig snabbare och kan ta in mer information än när de är ensamma, då de kan leta igenom material snabbare och båda tänker på samma problem samtidigt. Problemen skapas mest i att de kan börja fokusera på fel saker och lägger ner hela sin tid på irrelevanta aspekter. Willams och Kessler rekommenderar att nybörjare alltid ska ha en mentor eller liknande att fråga hela tiden för att inte detta problem ska uppstå. Expert - Expert Utmärks av att båda personerna är erfarna programmerare med lång erfarenhet, men inte nödvändigtvis av samma teknologier. Relationerna sinsemellan är ofta märkta med ömsesidig respekt för det gemensamma arbetet. Enligt Willams och Kessler leder deras interaktion ofta till att de utvecklar sitt kunnande på ett mycket effektivare sätt än ifall de skulle programmera var för sig. Den enda nackdelen som Willams och Kessler ser med denna kombination av programmerare är, förutom att ledningen på ett företag sällan är villiga att para ihop två så erfarna programmerare med varandra, att det kan leda till en egokonflikt. Det vill säga antingen så gör vi det på mitt sätt eller inte alls, med talang brukar ofta ego följa. Willams och Kesslers lösning på detta problem är att man ska inse vad det är man håller på med och lämna sitt ego hemma. Expert - Medelbra Utmärks av att en person är expert på området och den andra är antingen i ett utvecklingsstadium till att bli expert eller har en hel del erfarenhet men är ändå medelbra. Relationen blir då snarare den att experten tar på sig en mentorroll för den medelbra programmeraren och får sakta ner på sitt kodande för att lära den andra precis vad de håller på med. Men det framhävs starkt att den medelbra programmeraren även behöver ta ton, ställa frågor och visa framfötterna. De nackdelar som finns är: I det fallet då det handlar om en medelbra programmerare som verkligen inte vill utvecklas, något som experten inte kan råda över och parprogrammeringen kommer inte att leda någonvart, för ingen kommer att lära sig något. Ett annat scenario är i det fallet den medelbra programmeraren inte interagerar med den erfarna programmeraren, de frågar inte tillräckligt med frågor och lär sig inget vilket leder till att den erfarne programmeraren bär den medelbra programmeraren. Något som slutar i ett resursslöseri och ett arbete experten lätt hade 12

klarat av för sig själv. Sista scenariot man kan hamna i är när den medelbra programmeraren inte förstår, så hon ställer samma fråga om och om igen, vilket kan leda till att experten blir frustrerad och minska chansen att paret blir klar med sin uppgift i tid. Ofta är det expertens fel som inte kan svara på ett enkelt pedagogiskt sätt. Eller så har bara paret kommunikationssvårigheter för de kan inte relatera till varandras bakgrund. Svaret på att lösa dessa situationer är att få de två programmerarna att kommunicera sinsemellan. Expert - Nybörjare En expert som jobbar med en nybörjare är en kombination som inte är helt självklar. Det även finns dock fördelar med detta val. Expertens roll blir per automatik att lära upp nybörjaren så denne kommer snabbare in i sin roll jämfört med om hon hade arbetat för sig själv, samtidigt kommer nybörjaren hela tiden att fråga experten självklara frågor vilket leder till att inte experten får lika mycket fel i koden, då hon hela tiden berättar om vad hon skriver. Det är även viktigt att experten skapar en så bekväm miljö som möjligt för nybörjaren för att inte avskräcka denne. Vill inte experten verka som mentor så fungerar inte parkonstellationen och det samma gäller om inte nybörjaren blir för hämmad för att kunna lära sig något. Den enda nackdel med detta val av parkonstellation är att experten inte kommer jobba så snabbt som om denne skulle parprogrammera med någon mer erfaren, vilket leder till att det inte är ett bra val om man har lite tid. Andra konstellationer Utöver dessa utvecklarbakgrunder kan även personlighet spela in vilka kan delas upp i introverta programmerare och extroverta programmerare. Extroverta programmerare sitter hela tiden och kodar med en livlig dialog medan introverta programmerare sitter tysta den mesta delen av tiden de kodar. Dessa kan paras ihop sinsemellan hur som helst bara de kan föra en klar dialog och ställa frågor till varandra utan att motparten blir irriterad. Kön, kultur, dåligt själförtroende och kontrollberoende kan också spela in i parprogrammeringen och Willams och Kesslers lösning av dessa problem är att i största mån belysa att det är ett problem och få båda parter att acceptera, försöka anpassa sig, kommunicera med varandra och lämna sina egon hemma. 13

3. Teori I detta kapitel beskrivs de teorier som använts, vilka är Reflective Practioner, som bakomliggande teori till metoden, samt teorier kring tyst kunskap och communities of practice för att kunna besvara frågeställningen. 3.1 Reflective Practioner Uttrycket reflective practioner, eller reflektiva praktiker översatt till svenska, myntades av Donald S. Schön 1983 i boken The Reflective Practitioner: How professionals think och är en modell för att utvärdera och utveckla sina arbetsmetoder genom att reflektera över dessa själv. Han menar att den professionelle praktikerns kunskap inte kan utvecklas förrän denne tydliggjort kunskapen för sig själv, genom att reflektera över den. Schön menar att den traditionella uppfattningen av vad kunskap är inte räcker till för att beskriva hur praktikern hanterar problematiska situationer i sin yrkesroll. Denna traditionella uppfattning av kunskap menar han baseras på teknisk rationalitet. Teknisk rationalitet definierar han här som en applicering av standardiserad vetenskaplig kunskap vilken används i professionell praktik som verktyg för problemlösning. Denna tekniska rationalitet finns inbakad i den institutionella kontexten i yrken. Teknisk rationalitet är ett effektivt sätt att organisera forskning och praktik inom ett yrke, men det är beroende av sina klara verktyg och metoder. När det inte finns en klar lösning på ett problem är det svårt för en praktiker att finna rätt metod för att lösa problemet. När praktiker misslyckas med att engagera sig i ett problemområde, löper de risk att missförstå situationen och inte se dess unika karaktärsdrag. Som motsats till problematikhantering med hjälp av rationella problemlösningsverktyg ser han metoderna reflection-in-action och reflection-onaction. Schön börjar sitt resonemang med att vi besitter en tyst kunskap, som vi själva inte märker, men ligger till grund för de handlingar och bedömningar vi gör i vår vardag utan att tänka på det. Men ibland händer det att denna knowing-in-action, som Schön väljer att kalla det, inte räcker till och man börjar funderar över vad man gör. Alltså, man reflekterar över sina handlingar, reflection-in-action, och efter sina handlingar, reflection-on-action. Schöns tanke med dessa metoder är att praktikern i sin yrkesutövning ska reflektera över de rutiner och tillvägagångssätt han/hon har och hur han/hon applicerar sin kunskap på ett problemområde. Genom att kritisera dessa, sina arbetsmetoder, blir man således en forskare i en praktikkontext och kan ur sitt 14

resultat och agerande dra slutsatser som kan förbättra ens rutiner och de sätt man applicerar sina kunskaper. Schön talar om ett sorts artistiskt kunnande och nyskapande av kunskap på en och samma gång. Hamnar praktikern i unika eller ostabila situationer kan hon, med hjälp av reflektion, kritisera sin ursprungliga uppfattning av fenomenet och kan med hjälp av resultatet från denna reflektion se och förbättra de delar av sin arbetsmetod som inte ger den utgång hon förväntat sig att få. 3. 2 Tyst kunskap Uttrycket tacit knowledge myntades av Polanyi (1967), detta kan på svenska närmast översättas till tyst eller implicit kunskap. Enligt Polanyi är tyst kunskap sådan kunskap som inte kan uttryckas i ord. Han uttrycker detta med att vi vet mer än vi kan säga. Han menar att den kunskap som vi kan förmedla endast är en mycket liten del av den totala kunskap vi besitter. Vidare menar Polanyi att den tysta kunskapen är unik för varje individ, vilket gör den svår att formalisera och kommunicera. Man kan se tyst kunskap som både känslomässig och teknisk. Den känslomässiga delen ligger till grund för hur vi uppfattar vår omvärld och väljer att agera i den. Den tekniska delen är kopplad till handling, engagemang och i specifika sammanhang. När man talar om tyst kunskap brukar man även nämna explicit kunskap, som kan ses som dess motsats. Med explicit kunskap syftar man på kunskap man kan få genom att samla in och bearbeta information. Det är kunskap som lätt kan vidareförmedlas med ett formellt språk via exempelvis databaser eller böcker och är inte knutet till de personer som tagit fram den. Polanyi menar att det inte går att särskilja den tysta kunskapen från den explicita. Den tysta kunskapen kan ses som den kulturella, emotionella och kognitiva bakgrunden som vi bara är delvis medvetna om och är en förutsättning för den explicita kunskapen. Polanyi anser därför att tyst kunskap är högst individuell och kan bara uppnås genom personliga erfarenheter och därför kan den inte spridas vidare. Enligt Polanyis syn på tyst kunskap så kan denna inte heller konverteras till explicit kunskap då den inte kan återskapas eller skrivas ner i explicit form. Att omvandla tyst kunskap till explicit kunskap skulle kunna jämföras med att beskriva något obeskrivbart. 3.2.1 Överföring av tyst kunskap Till skillnad från Polanyis syn på tyst kunskap och att denna inte går att överföras mellan människor, lade Nonaka 1995 fram en teori om att det går att överföra tyst kunskap och genom detta kunna skapa ny kunskap. Han har i sina undersökningar av 15

innovationsförmågan i japanska företag visat att om förmågan att utveckla nya idéer ska slå igenom måste man gå längre än att bara se till den explicita kunskapen som man kan samla in och bearbeta. Han har därför utvecklat ett flertal modeller för att påvisa att det är möjligt att överföra tyst kunskap i en organisation även om den inte omvandlas till explicit kunskap. Nonaka ser tyst och explicit kunskap som komplement till varandra. De interagerar med varandra i en människas sociala aktiviteter. Nonaka kallar denna interagering för kunskapskonverteringsprocess där ny kunskap kan skapas. Konverteringsprocessen består av fyra stadier; socialisation, förkroppsligande, sammanställning och internaliserande (Nonaka, 1995). Det första steget, socialisation, överför tyst kunskap mellan individer genom observation, imitering och praktik. Tyst kunskap kan alltså överföras utan man behöver uttrycka den, detta genom att man exempelvis praktiserar samma sak och delar på erfarenheter inom samma kontext. På så sätt skapar man ny tyst kunskap såsom delade mentala modeller och praktiska tekniska kunskaper. Ett exempel på detta är en lärling som lär av sin mästare, men även mer likvärdiga praktiker i en community of practice. I nästa steg, förkroppsligande, förvandlas tyst kunskap till explicit kunskap genom dialog eller kollektiv reflektion. Den tysta kunskapen blir då explicit i formen av metaforer, likheter, koncept, hypoteser eller modeller. Detta är det enda sätt för utomstående att ta del av den ursprungliga tysta kunskapen. Sammanställning syftar på överföringen av explicit kunskap inom organisationen, detta kan ske genom exempelvis dokument, databaser och möten. Genom att sortera, addera och kombinera den explicita kunskapen kan ny kunskap skapas och standardiseras. Slutligen sker internaliserande då den explicita kunskapen översätts till tyst kunskap genom handling. Detta kan relateras till learning by doing, att kunna införliva sitt tänkande. Nonaka beskriver detta fenomen med en kunskapsspiral, där hela tiden ny kunskap bildas. 16

Tyst kunskap Socialisation Explicit kunskap Förkroppsligande Tyst kunskap Explicit kunskap Internaliserande Sammanställning Figur 1: Nonakas kunskapsspiral Genom dessa fyra steg ökar hela tiden kunskapen mellan människor i en organisation och nya innovationer kan skapas. 3.3 Communities of Practice Communities of practice kan definieras som människor som är informellt bundna till varandra och praktiserar samma sak. I en community of practice fokuserar man på de praktiska aspekterna av verksamheten så som alldagliga problem, nya verktyg, utveckling inom ens gemensamma intressefält, vad som fungerar och vad som inte gör det. Människor deltar i nätverket för att det förmedlar värde och kunskap för ens personliga utveckling, man kan säga att en community of practice drivs framåt av dess medlemmars strävan efter ny kunskap snarare än av själva resultatet av det man gör (Brown, J & Duguid, P., 1991). Medlemmar av nätverket hjälper varandra att lösa problem och utvecklar nya tillvägagångssätt och verktyg för sitt område. Detta gör det enklare för medlemmarna av communityn att visa sina svaga sidor och tillsammans lära sig nya saker inom communityns område. För att definiera en community of practice har E. Wengers bok Communities of practice: learning, meaning, and identity (1998) och hemsida [4] använts som grund. Communities of practice har funnits så länge människor lärt sig saker gemensamt. Man kan vara medlem av flera community of practice, ibland kanske utan att egentligen veta om det, både hemma, på jobbet, i skolan, osv. Man kan säga att Communities of practice finns överallt, de är ett så vanligt fenomen i vardagen att man inte noterar dem. Det är när man ger dem ett namn som man först noterar dem 17

och ser förbi de formella strukturer som finns, exempelvis företag, och istället uppfattar strukturer definierade av engagemang i praktiken, det vill säga communities of practice. För att tydligare avgränsa communities of practice delar vi upp teorin i tre utmärkande egenskaper som definierats av E. Wenger på dennes hemsida om communities of practice [4]. Domänen En community of practice är mer än ett nätverk eller en umgängeskrets. Den definieras av en gemensam intressedomän. Medlemskap i communityn kräver därför ett engagemang inom domänen och därmed en delad kompetens som utmärker medlemmar från andra människor. I större företag är till exempel oftast driftpersonal och utvecklare två olika communities of practice, trots att de kanske geografiskt sitter nära varandra och de båda håller på med datorer, men har olika expertis och olika intressesfärer. Communityn I sin strävan efter att fullfölja sina intressen i sin domän så deltar medlemmarna i gemensamma aktiviteter och diskussioner, hjälper varandra och delar information. De skapar relationer som möjliggör att de kan lära av varandra. Att ha samma jobb eller samma titel innebär inte direkt att man tillhör samma community of practice om inte medlemmarna interagerar och lär sig av varandra. Men detta betyder inte att medlemmarna i en community of practice nödvändigtvis måste jobba tillsammans dagligen. Praktiken En community of practice är inte enbart ett nätverk baserat på en intressesfär. Medlemmar av en community of practice är praktiker. De utvecklar en delad repertoar av resurser; erfarenheter, verktyg och sätt att behandla återkommande problem, det vill säga de delar på en gemensam praktik. Att skapa en gemensam sfär tar tid och kräver kontinuerlig interaktion. Det är dessa tre element som utgör grunden i en community of practice och det är genom att utveckla dessa tre element parallellt som man kan utveckla en sådan community. 3.3.1 Hur en community of practice verkar Målet med en community of practice är främja communityn genom att utveckla individerna. Communities of practice består av olika delar för att hjälpa individen i sin utveckling. Det finns enligt E. Wenger ett antal återkommande vanliga aktiviteter som är utmärkande för en community of practice. 18

Problemlösning Om en person fastnar och inte kan komma vidare med ett problem så söker hon upp någon med liknande kunskaper i sin community som kan hjälpa honom genom att se på hans problem ur en annan synvinkel. Informationssökning Informationssökning är en annan form av problemlösning. Man saknar central information för att gå vidare och istället för att leta upp det genom formella kanaler som kan ta längre tid så frågar man någon i sitt nätverk som man vet innehar informationen och snabbt kan förklara för en. Söka erfarenhet Erfarenhetssökning är i sin tur besläktat med informationssökning, fast på ett mer komplext plan. Man söker kunskap om erfarenhet istället för kunskap om ett objekt. Har någon gjort det här förut? Återanvända tillgångar Här menas att man återanvänder kunskapen någon innehar från ett gammalt projekt i ett aktuellt. Det vill säga man vet att någon innehar liknande erfarenheter och ber därför denna att hjälpa en optimera sitt eget projekt för att spara tid. Diskutera utvecklingar Man jämför åsikter och försöker finna gemensamma svar utifrån sina individuella kunskaper och erfarenheter om nya utvecklingar i sin community of practice. Dokumentera projekt Har man stött på ett problem förut i en community of practice, brukar man oftast försöka dokumentera hur man löst det eller var det uppstår så att hela communityn kan få ta del av informationen. Besök Man besöker varandra på plats för att vinna erfarenheter och kunskap från den andres situation om den på något sätt kan hjälpa en själv. Kartlägga kunskap och identifiera brister Man försöker kartlägga vem som vet vad inom ens intressesfär och vilka kunskaper som saknas så man kanske kan komplettera dem ifall en möjlighet uppstå. 19

3.3.2 Skepnader Förutom de tre egenskaperna domän, nätverk och praktik kan en community of practice ha många olika skepnader. Det kan vara stora skillnader i storlek mellan olika communities of practice, vissa är lokala medan vissa är globala och det går att interagera i sin Community of Practice både på plats som online på internet. Det finns även stora skillnader i hur välkänt och väldefinierat en community of practice är, vissa kan vara väl erkända men det är även möjligt för en community of practice att vara helt informellt och inte synas alls. Nya personer som vill komma in i ett community of practice Figur 2: Översiktsbild av en community of practice Ju längre tid man spenderat i en community of practice och lärt sig nya kunskaper desto närmre kärnan får man komma, där man tillåts ta ansvar för mer avancerade/riskfyllda uppgifter 3.3.3 Struktur Lärandet är en central del av en community of practice och det som driver communityn framåt. När en ny person kommer in i en community of practice brukar hon för det mesta vara relativt okunnig inom det område communityn verkar inom, målet för de flesta nya medlemmar i en community of practice är att lära sig. Ju mer man verkar inom sin nya community desto mer lär man sig och man rör sig närmre den innersta kärnan. När man närmar sig den inre kärnan i en community of practice får man ta på sig mer och mer ansvarsfyllda uppgifter för communityn, till exempel fatta beslut som är vitala för communityns fortsatta existens. Ju närmre centrum man kommer desto mer kommer man dessutom att lära sig. Kunskap föder kunskap. 20

4. Metod I detta kapitel redovisas först vårt val av vetenskapligt synsätt följt en redovisning av den metod vi använt för att besvara vår frågeställning. 4.1 Vetenskapligt synsätt Med tanke på problemområdets natur, att det inte finns någon objektiv sanning, valde vi att utgå från ett kvalitativt hermeneutiskt synsätt. Enligt det kvalitativa hermeneutiska synsättet (Dahlbom & Mathiassen, 1993) förutsätts alla situationer vara unika, varför generella beskrivningar lätt blir missvisande. Man sätter subjektet i fokus framför objektet. Tyngdpunkten läggs således vid att studera vad som händer vid enskilda tillfällen, samt händelsernas bakomliggande orsaker. Vidare anses världen vara mångfacetterad och för att förstå det normala måste även det onormala studeras. 4.1.1 Kvalitativ metod Då svaret på vår frågeställning inte utgår från ett mätbart resultat utan snarare kommer baseras på våra egna observationer och tolkningar så valde vi att helt rikta in oss på en kvalitativ metod. Hade vi inriktat oss på en mer hård objektiv frågeställning där vi till exempel skulle ha mätt effektiviteten med parprogrammering hade en kvantitativ undersökning med ett positivistiskt synsätt förmodligen varit att föredra. 4.2 Praktiskt tillvägagångssätt Då problemområdet kan anses ligga mellan praktik och forskningsvärlden så fanns ett behov av en forskningsmetod som gick att applicera i ett praktiskt sammanhang. Valet föll därför att på studera ett case där parprogrammering användes under ett professionellt programutvecklingsprojekt med en riktig kund och krav på en produkt av så hög kvalitet att den skulle kunna produktionssättas. Då det case studien bygger på utgår från författarna av denna uppsats, alltså oss själva, valde vi att använda oss av Schöns teorier kring reflekterande praktiker (Schön, 1983). Detta för att minska avståndet mellan forskning och praktik. Schön menar att praktikern, genom reflektion, kan ifrågasätta sitt tillvägagångssätt och på så sätt bli en forskare i ett praktiskt sammanhang. 4.2.1 Case Caset som användes var ett uppdrag ifrån AstraZeneca vilka var i behov av ett nytt bokningssystem för labbinstrument på deras site i Mölndal. För att få ut ett så autentiskt resultat som möjligt nyttjades det utav XP som utvecklingsmetod, för att 21

efterlikna samma struktur som en verklig nybörjare skulle få i ett liknande projekt på företaget. Utvecklingen av bokningssystemet tog totalt 10 veckor och involverade enbart de två nybörjarna som studerades samt en användarrepresentant ifrån AstraZeneca. Utvecklingen delades in i två faser. Först en planeringsfas på två veckor, med framställning av kravspecifikationer tillsammans med AstraZenecas användarrepresentant (Bengt Ohlsson, Medicinal Chemistry, AstraZeneca R & D Mölndal), vilka utvecklades till beskrivningar för vad systemet skulle ta upp. Följt av en analys för att uppskatta tidsåtgång och prioritetsordning för dessa. Följt av en utvecklingsfas av systemet; vilken delades upp i fyra iterationer på två veckor vardera, det vill säga 8 veckor totalt. I de olika iterationerna delades systemet upp i mindre delmoment baserade på de beskrivningar användarrepresentanten tagit fram och den prioritet dessa hade fått enligt föregående fas. 4.2.2 Dagböcker Ur utvecklingsfasen utvanns det empiriska material, i form av dagböcker med anteckningar och reflektioner på parprogrammering, vilken studien baseras på. Dagböcker har länge varit en nyckelkälla för insamling av data för levnadstecknare, historiker och litteraturvetare (Plummer, 1983) men på senare tid har denna datainsamlingsteknik även använts i forskning inom andra forskningsområden, bland annat forskning kring informationssystem (exempelvis Toms, G.T., & Duff, W. (2002). När de tidigare studerat redan skrivna dagböcker, har man inom ISforskningen snarare använt dagboken för att registrera vissa saker från en viss period i en persons liv. En forskningsdagbok, för att fånga detaljerad information om beteenden, händelser och andra aspekter i individers vardag. Jepsen et. al (1989) hävdar att man kan använda dagböcker som medium för att reflektera över de situationer man hamnar i. Därför menar de att dagboksskrivande kan få stöd av Schöns teori kring reflective practioner. På grund av den nära kontakt som finns mellan en händelse och dagboksföring av händelsen blir det empiriska data som uppstår mer trogen sitt sammanhang. Reflektioner kring en händelse skrevs ner direkt i dagboken för att ge en tydlig dokumentering över vilka tankarna kring parprogrammering var för ögonblicket, 22