Denna sida uppdateras ej längre. Numera bloggar Niklas Udd på Enligt Niklas (enligtniklas.se). För nyare texter och mer aktuell information bör du gå dit.

Gå till Enligt Niklas (Niklas Udds nya blogg)

udd.be

Meny:

• Välkommen
• Om mig
• Artiklar

Sök
Bläddra

• Kontakta

Citera texten

Naturligtvis får du citera denna text, men glöm då inte att lägga in lämpliga hänvisningar. Om du vill får du dessutom gärna skriva en kommentar om att du har citerat texten.

Slumpvalda artiklar

- Hur kan folk misströsta när Ace of Base finns?
- Vad tyckte svenskarna om låtarna? Egentligen
- Ubuntu-problem och deras lösningar (with English abstract)

Kvalitet, tid och pengar i parprogrammeringens värld

Publicerad: 2006-08-01
Skriven: 2005-05-15
Kategori(er): skola, teknik

Den här artikeln är skriven som ett moment i kursen Muntlig och skriftlig presentation som jag har läst som en del av min utbildning på KTH.

Sammanfattning

Parprogrammering innebär att två programmerare sitter vid en dator när de programmerar. Den ena skriver aktivt den kod som ska implementeras och den andra granskar denna kod och tänker strategiskt framåt. De båda byter roller ofta och regelbundet.

I den här rapporten analyseras parprogrammering med avseende på kvalitet, tid och pengar. I slutet av den finns också en diskussion och ett par rekommendationer till dem som har för avsikt att prova parprogrammering.

Innehåll

• Inledning
• Hur parprogrammering fungerar
• Olika aspekter av parprogrammering
  • Kvalitet
  • Tid
  • Pengar
• Diskussion
• Rekommendationer
• Referenser

Inledning

Parprogrammering, vilket innebär att två programmerare sitter vid en dator, blir vanligare och vanligare [1]. Anledningen till denna utbredning är till stor del genomslaget av utvecklingsprocessen Extreme Programming (XP)1, men parprogrammering tillämpas också i andra utvecklingsprocesser, eller helt fristående. Intuitivt kan det tyckas att parprogrammering torde minska effektiviteten till hälften, eftersom bara en åt gången kan skriva den kod som ska implementeras. Vid närmare analys står dock många fördelar att finna; högre kvalitet på koden och större välbefinnande hos programmerarna är ett par av dessa.

Syftet med den här rapporten är att ge en orientering inom ämnet parprogrammering samt att ge en överblick över de forskningsresultat som finns.

Hur parprogrammering fungerar

Innan fördelarna och nackdelarna med parprogrammering kan analyseras måste först själva begreppet redas ut. Parprogrammering innebär, som det står ovan, att två programmerare sitter vid en och samma dator. Den ene, den så kallade föraren (eng. driver), har hand om tangentbord och skriver aktivt koden. Den andre, kallad kartläsaren (eng. navigator, observer och non-driver), granskar den kod föraren skriver samt tänker strategiskt framåt för kommande uppgifter. Ofta diskuterar de båda vägvalsbeslut och utmanande problem. Rollerna byts ofta och båda två är lika delaktiga i programmerandet.

Parprogrammering handlar således inte om en person som programmerar och en annan som tittar på i väntan på att rollerna ska bytas. Navigatörens roll är viktig, och det är den viktiga rollen som ofta glöms bort när parprogrammering betraktas som tidsineffektivt. I och med att navigatören hela tiden granskar den kod som föraren skriver hittas fel, både skrivfel och logiska fel, snabbare. En annan fördel är att designbeslut fattas kontinuerligt och i samförstånd, vilket gör att mindre tid behöver läggas på dessa beslut innan programmerandet kan komma igång.

Olika aspekter av parprogrammering

Att jämföra parprogrammering vad det gäller kvalitet, tid och pengar är komplext eftersom dessa tre aspekter är intimt förknippade. En programvara med låg kvalitet går troligtvis snabbare att framställa än en med hög kvalitet. Å andra sidan måste troligtvis programvaran med låg kvalitet förbättras senare, vilket gör att tidsåtgången ökar då istället. På samma sätt påverkas kostnaden för denna programvara: låg kvalitet kan ge en relativt låg initialkostnad, men då kanske programvaran senare måste förbättras varpå kostnaden ökar. Att enskilt isolera dessa aspekter är därför mycket svårt.

Trots komplexiteten analyseras dessa tre aspekter ändå var och en för sig nedan. Denna uppdelning är tänkt att hjälpa läsaren att få en överblick över parprogrammeringens för- och nackdelar. Utan uppdelning blir materialet lätt svåröverskådligt.

Kvalitet

Programmerare, liksom alla andra människor, gör fel och för att upptäcka dessa fel i programvara innan den släpps tillämpas ofta kodgranskning, där en eller flera personer skärskådar koden. Vid tillämpning av parprogrammering sker denna granskning kontinuerligt av kartläsaren.

James E. Tomayko utförde ett experiment med målet att undersöka om parprogrammering är lika effektivt som ovan nämnda kodgranskning [3]. En klass skolelever delades upp i två grupper där den ena gruppen använde utvecklingsprocessen Team Software Process (TSP) och den andra XP. TSP litar mycket till kodgranskning medan XP använder parprogrammering för att fylla detta behov. Resultatet av undersökningen blev att XP-gruppen inte bara höll lika hög kvalitet, de höll till och med väsentligt högre kvalitet.

In terms of the main thing we were trying to find out, whether pair programming is as effective as inspections in reducing defects, the answer appears to be 'yes.' There were 9.6 defects per thousand lines of code made by the XP team, with 19.7 made by the TSP team.2 [3]

Detta talar naturligtvis till parprogrammeringens fördel, men en viktig aspekt här är att XP och TSP skiljer sig på många områden. Den högre kvalitén på XP-gruppens kod kan även förklaras med att XP lägger stor vikt vid exempelvis enhetstest (eng. unit test) och kontinuerlig integration (eng. continuous integration).

En annan studie, utförd av Laurie Williams, jämför istället utvecklingsprocesserna Personal Software Process (PSP) och Collaborative Software Process (CSP)3 [4]. Dessa processer är mer lika varandra, men till skillnad från PSP tillämpar CSP parprogrammering. Även här utfördes studier på elever och resultatet pekar åt samma håll.

Collaborative pairs [de som tillämpade CSP] achieve a higher quality level for programming products. Pairs had 15% less defects in their code. The higher quality level is statistically significant.4 [4]

Den femtonprocentiga ökning som här omtalas är lägre än den som noterades av Tomayko, där en TSP-grupp och en XP-grupp jämfördes [3]. Detta skulle kunna bero på de skäl som tidigare anförts: TSP och XP är för olika för att resultatskillnaden enbart ska kunna tillskrivas parprogrammeringen.

Tid

Den högre kvalitet som påvisades i avsnittet ovan har ett pris, och detta pris betalas i form av tid. Eftersom endast en åt gången skriver koden är det intuitivt lätt att tro att tiden fördubblas.

I en studie utförd av Kim Man Lui och Keith C.C Chan lät de arbetande programmerare från olika arbetsmiljöer och med olika kunskaper jobba dels i par och dels ensamma [5]. För att inte resultatet skulle påverkas av att de olika programmerarna hade olika kunskaper i olika programmeringsspråk fokuserades undersökningen på algoritmdesign. Deltagarna fick logiska problem, utformade som flervalsfrågor, att lösa. När de hade svarat på alla frågor fick de lämna in sina resultat varpå de fick reda på hur många fel de hade. Deltagarna fick då se över sina svar och lämna in igen. Inlämningen fortsatte tills alla frågor var korrekt besvarade.

The intuition judgment of many people would be that pair programming spent about 100% more time on the program than the individuals. According to the previous [undersökningsresultatet], when ignoring the quality, pairs did spend much more time.5 [5]

I verkligheten kan kvalitén naturligtvis inte ignoreras, varpå tidsskillnaden tills alla frågor var korrekt besvarade troligtvis är det mest intressanta resultatet. Det visade sig att parprogrammerarna behövde cirka 4 % mindre tid för att besvara alla frågor rätt, men å andra sidan behövde de 21 % mer tid för att över huvud taget besvara samtliga frågor.

I verkligheten finns dock sällan ett facit att jämföra sina resultat med vilket gör att felen kan bli svårare att hitta. Att utföra själva kontrollen, i det här fallet att jämföra med facit, tar i verkligheten tid även den, eftersom den måste ske genom tidskrävande kodgranskning. För att få en mer korrekt siffra borde även tiden för kodgranskningen tas med.

I en studie av Laurie Williams, vilken även omtalades under kvalitetsavsnittet, tar hon mer hänsyn till helheten [4]. Då alla i studien var elever och hade en snarlik kunskapsbas kunde de skriva faktiska program, istället för att endast göra abstrakt algoritmdesign, utan att studien blev lidande. I och med denna realistiska experimentuppställning behöver inget facit kompenseras bort.

Nedan följer ett av undersökningens mest anmärkningsvärda resultat (ett annat redogjordes för redan under kvalitetsavsnittet):

Collaborative pairs [de som tillämpade CSP] spend approximately 15% more time than do individuals on the same task. This additional time, however, is not statistically significant.6 [4]

Williams själv kommenterar detta resultat i ett annat sammanhang [1]. Hon förklarar då att tidsökningen i princip endast berodde på ett enda par, och att det är därför resultatet ej är statistiskt signifikant. De båda eleverna i det specifika paret medgav båda två att de inte hade varit fokuserade på uppgiften utan ofta diskuterat fritidsintressen istället för att programmera.

Kent Beck, en av grundarna till XP och en erfaren parprogrammerare, skriver så här:

One of the objections to pairing is that pairing cuts effective programming in half. In my experience, pairs are more than twice as effective. The actual time required for me to complete tasks solo versus paired, accounting for debugging time, is more than double; so by pairing you actually come out ahead in completed, clean code. When comparing the value of pairs to individuals, you need to include both time and productivity in deployable code.7 [2]

Både Williams och Beck är således överens om att den tidsfördubbling som omtalades tidigare är överdriven. Någon mer exakt förändringen av den tid som krävs kan ingen av dem dock presentera.

Pengar

Den mycket intressanta penningaspekten hör i hög utsträckning ihop med kvalitet och tid som tidigare har diskuterats. En programvara med högre kvalitet är naturligtvis värd mer för användarna och kan således säljas för ett högre pris. På samma sätt kan en programvara som levereras snabbt även den säljas för ett högre pris. Att väga dessa aspekter mot varandra är, som sagt, komplext och dessutom olika för olika system.

I studien omnämnd ovan beträffande jämförandet av kodgranskning med parprogrammering görs en intressant notering beträffande produktivitet [3]. Eleverna i undersökningen delades upp i par, där den ena hälften av paren parprogrammerade. Den andra hälften av paren jobbade två och två med att lösa samma uppgift, fast själva programmerandet gjorde de var för sig. Efter halva försökstiden byttes grupperna, så att de som inte parprogrammerat fick göra det och vice versa. Det mest anmärkningsvärda, statistiskt säkerställda resultatet, är att "pair-programming is not less productive, than non-pair-programming"8. Detta skulle kunna tolkas som att införande av parprogrammering åtminstone inte kostar mer pengar genom en lägre produktivitet.

Det är vidare känt att kostnadsökningen ju senare fel hittas är exponentiell [4]. Om ett fel upptäcks direkt när det skrivs är det billigt att åtgärda; den enda tid som förloras är den tid som det tog att skriva felet. Om felet däremot upptäcks när systemet har varit i drift i ett år är det mycket dyrare att åtgärda. Felet i koden måste lokaliseras och någon måste sätta sig in i det gamla kodpartiet. Tyvärr kan dessa båda aktiviteter ta mycket lång tid. Eventuellt kan parprogrammering spara pengar genom att många fel hittas direkt av kartläsaren.

Ytterligare en aspekt som är värd att ta upp är att programmerarna kan bli mer nöjda med sina jobb, och på detta sätt ge företaget ett ökat värde.

Consistently, 95% of collaborative programmers [de som tillämpade CSP] asserted that they enjoy their work more and are more confident in their work than when they program alone.9 [4]

Diskussion

För att få en mer komplett bild av parprogrammering bör även vissa sidoeffekter tas i beaktande. I och med att parprogrammering kan leda till att designbeslut kan göras fortlöpande istället för i början behövs inte lika mycket dokumentation. Om ett par programmerare ska jobba på samma uppgift, men var för sig, behöver de komma överens och arbetsfördela i början. Troligtvis kommer detta arbete resultera i dokumentation, något som skulle vara onödigt i en parprogrammeringssituation. Att ha denna initiala dokumenteringsfas får i huvudsak två följder.

Den ena följden är att dokument kan sparas. Om systemet om fem år behöver uppdateras är det mycket möjligt att de båda programmerarna inte längre minns systemet, om de ens jobbar kvar. I ett sådant fall skulle originaldokumentationen kunna vara till användning.10

Den andra följden är att de som programmerar individuellt i och med denna extra tid i början kommer igång sent. I studien utförd av James E. Tomayko kontrolleras deltagarnas resultat två gånger [3]. Vid den första kontrollen är parprogrammerarnas resultat mycket bättre, men vid den andra kontrollen är resultatskillnaden mindre. Detta skulle, enligt Tomayko, kunna innebära att de som programmerade individuellt slutligen skulle komma ikapp.

I de flesta projekt ändras dock förutsättningarna ofta, vilket kan göra att det är riskabelt att besluta om all design i början av projektet [2]. De som programmerar individuellt, men på samma projekt som någon eller några andra, skulle troligtvis få ha flera designmöten under tidens gång. Dessa förändringar talar således emot att de som inte parprogrammerar skulle komma ikapp parprogrammerarna.

I de flesta situationer verkar parprogrammering gynnsamt. Eventuellt kan en viss extra tidsåtgång uppstå, men med tanke på den höjda kvalitén är detta troligtvis acceptabelt. Eftersom den höga kvalitén kan göra att avlusningstid senare sparas in bör tidsaspekten, i de allra flesta situationer, inte ses som ett argument mot parprogrammering.

Rekommendationer

Parprogrammering är ingen vetenskap, men det har i alla fall forskats mycket på området. Om parprogrammering ska införas bör viss vikt läggas vid att få alla delmoment att fungera. I Pair Programming Illuminated diskuteras hur olika situationer ska behandlas för att parprogrammeringen ska fungera så effektivt som möjligt [1].

Slutligen är det viktigt att komma ihåg att människor är människor. Förändring måste komma inifrån och det är ingen mening att påtvinga någon parprogrammering [2]. Vidare är det också viktigt att förändringen tar tid. Två individuella programmerare kommer inte att bli en perfekt parprogrammeringsgrupp över en natt.

Referenser