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)

Meny:

Sök
Bläddra

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

- Men vilket år är den från?
- iTunes Exclusive -- nu även via Spotify
- Konstiga fordon

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

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

[1] Williams, Laurie & Kessler, Robert (2002). Pair Programming Illuminated. 1. uppl. Boston, USA: Addison-Wesley Professional. 288 s. ISBN 0-201-74576-3.
[2] Beck, Kent & Andres, Cynthia (2004). Extreme Programming Explained: Embrace Change. 2. uppl. Boston, USA: Addison-Wesley Professional. 224 s. ISBN 0-321-27865-8.
[3] Tomayko, James E. (2002). A Comparison of Pair Programming to Inspections for Software Defect [pdf]. Hämtat från <http://xpdata.distance.cmu.edu/papers/>. Hämtat 27 mars 2005.
[4] Williams, Laurie (2000). The Collaborative Software Process [pdf]. Hämtat från <http://collaboration.csc.ncsu.edu/laurie/>. Hämtat 7 april 2005.
[5] Lui, Kim Man & Chan, Keith C.C. (2003). When Does a Pair Outperform Two Individuals? Lecture Notes in Computer Science, 2675, 225--233.

1) Den intresserade rekommenderas att läsa Extreme Programming Explained: Embrace Change [2]. [tillbaka]

2) Vad det gäller den huvudsakliga frågan vi försökte få svar på, huruvida parprogrammering är lika effektivt som kodgranskning för att minska antalet defekter, verkar svaret vara 'ja'. XP-gruppen gjorde 9,6 fel per tusen rader kod, medan TSP-gruppen gjorde 19,7. (Min översättning.) [tillbaka]

3) Den intresserade rekommenderas att läsa The Collaborative Software Process [4]. [tillbaka]

4) Samarbetande par [de som tillämpade CSP] uppnådde en högre kvalitetsnivå på programmeringsprodukter. Par hade 15 % färre defekter i sin kod. Den högre kvalitén är statistiskt signifikant. (Min översättning.) [tillbaka]

5) Det intuitiva omdömet hos många människor är att parprogrammerare använder ungefär 100 % mer tid för att skriva programmet än individer. Enligt det ovanstående [undersökningsresultatet], då kvalitén ignoreras, behövde par mycket mer tid. (Min översättning.) [tillbaka]

6) Samarbetande par [de som tillämpade CSP] utnyttjade ungefär 15 % mer tid än individer för samma uppgift. Den extra tiden är dock inte statistiskt signifikant. (Min översättning.) [tillbaka]

7) En av förevändningarna mot parprogrammering är att den halverar den effektiva programmeringen. Den faktiska tiden som behövs för mig att färdigställa en uppgift ensam mot i par, medräknat avlusningstid, är mer än dubbel. Genom att parprogrammera producerar du mer färdig, ren kod. Vid jämförande av värdet av par mot individer, måste man inkludera både tid och produktivitet i kod redo för leverans. (Min översättning.) [tillbaka]

8) parprogrammering inte är mindre produktivt än icke-parprogrammering (Min översättning.) [tillbaka]

9) Genomgående försäkrade 95 % av de samarbetande programmerarna [de som tillämpade CSP] att de uppskattade sitt jobb mer och är mer säkra i sitt jobb än när de programmerar ensamma. (Min översättning.) [tillbaka]

10) Detta går naturligtvis att komma till rätta med även om parprogrammering tillämpas. I exempelvis XP förespråkas omstrukturering (eng. refactoring). Den intresserade rekommenderas att läsa Extreme Programming Explained: Embrace Change [2]. [tillbaka]