DevOpsSamen op een pc werken, hoe kan dat een goed idee zijn?

Samen op een pc werken, hoe kan dat een goed idee zijn?

pairprogramming

Met twee man tegelijkertijd op één PC werken, hoe kan dat een goed idee zijn?
Wanneer ik met mensen in gesprek ga over Pair Programming is de meest gehoord reactie: “Daar hoef ik bij ons niet mee aan te komen, dan ben ik twee keer zo lang bezig om functionaliteit op te leveren”. De vraag is echter of dit inderdaad het geval is, en als het al langer duurt om functionaliteit te realiseren of er dan geen andere voordelen zijn die ervoor zorgen dat je dit zeker wel moet overwegen.

Wat is Pair Programming?

Pair Programming houdt in dat je met twee teamleden achter één PC gaat zitten waarbij één teamlid de code schrijft terwijl de collega meekijkt. Zoals gevisualiseerd is één collega de bestuurder en de andere collega de navigator. De collega die meekijkt, controleert de code terwijl deze wordt geschreven. Daarnaast kan de collega die meekijkt bijvoorbeeld ideeën aandragen en vragen stellen waarom voor een bepaalde oplossing wordt gekozen. Mijn ervaring is dat mensen voor het oplossen van een bepaald soort probleem vaak dezelfde soort oplossing kiezen. Wanneer een collega meekijkt, dan kan dit ertoe leiden dat je uiteindelijk een andere oplossing kiest die misschien wel beter is.

Oorsprong

Het is niet eenvoudig aan te geven door wie en wanneer Pair Programming als manier van werken is geïntroduceerd. In het midden van de jaren vijftig is Pair Programming al genoemd in een essay van Fred Brooks. Als je kijkt naar de toepassing in de Agile manier van werken dan kom je uit in de jaren negentig waarbij het in de eXtreme Programming wereld werd omarmd. Tegenwoordig is het een algemeen geaccepteerde practice, maar ik kom het in de praktijk nog niet heel veel tegen. Het wordt wel gebruikt maar incidenteel. In dit blog wil ik uiteenzetten welke overwegingen er zijn om het juist veel meer te doen.

Mythe: Het kost twee keer zoveel tijd om functionaliteit te realiseren

Allereerst goed om stil te staan bij de weerstand die Pair Programming bij verschillende mensen en organisaties oproept. Rekenkundig zou je kunnen zeggen dat door met twee mensen achter één PC te gaan zitten het inderdaad twee keer zo lang duurt om functionaliteit op te leveren. Uit onderzoek, uitgevoerd in 2001 door Dr. Laurie Williams, blijkt echter dat Pair Programming leidt tot ongeveer 15% productie verlies (oftewel, als je twee ontwikkelaars individueel laat werken dan zijn deze 15% sneller dan wanneer je twee ontwikkelaars laat pairen). Je levert dus iets aan snelheid in, maar niet zoveel als vaak wordt gedacht.

Voordelen van Pair Programming

Maar waarom zou je het dan wel moeten doen? Het kost immers meer tijd dan wanneer je allemaal individueel werkt. Er zijn een aantal reden die ervoor pleiten om het toch te doen.

De Kwaliteit van de software gaat omhoog

Daar waar je meer tijd kwijt bent om functionaliteit te realiseren gaat ook de kwaliteit omhoog. Uit het eerder genoemde onderzoek van Dr. Laurie Williams blijk dat code zonder fouten toeneemt van 70% naar 85%. Dit is een groot voordeel, het oplossen van fouten is kostbaarder dan creëren van nieuwe functionaliteit, en wanneer fouten verder in het proces pas worden gevonden (dus in de test van de ontwikkelaar, of in productie) hoe duurder dit wordt. Code die vrij van fouten is heeft dus een hoge waarde en levert veel meer op dan de extra inspanning dat dit kost (15% langzamer werken voor 15% betere kwaliteit is een zeer goede investering).

Code review wordt direct gedaan

In de meeste organisaties geldt dat er minimaal door één collega een code review moet worden uitgevoerd. Wanneer je Pair Programming doet dan wordt de code review direct uitgevoerd, deze wordt namelijk tijdens het ontwikkelen gedaan. Voordeel hiervan is dat je geen collega hoeft te zoeken die tijd moet vrij maken om een code review te doen van een oplossing waarvan hij of zij niet goed weet wat de correcte werking of het doel is.

Kennisoverdracht

In veel organisaties ontstaan eilandjes met mensen die kennis hebben van bepaalde onderdelen van de software. Door Pair Programming te doen heb je altijd twee mensen die de nieuwe code kennen. Daarnaast kun je ervoor kiezen om voor een gebied waarin maar één collega kennis heeft, deze collega te laten pairen met een collega die hier nog geen kennis van heeft. Door de collega zonder de specifieke kennis het werk te laten doen zorg je er direct voor dat deze de benodigde kennis opdoet.

Doorgroei junior, medior, senior

Wanneer je ervoor kiest om een junior developer en een medior developer te laten Pair Programmen (of een medior met een senior) zorg je ervoor dat de junior developer direct leert van de medior developer. De junior developer zit achter het toetsenbord en gaat de functionaliteit realiseren, de medior developer kijkt mee. Wanneer een junior developer een fout maakt of een verkeerde oplossing kiest moet je niet direct ingrijpen, je wacht tot de junior developer klaar is en laat hem dan de oplossing testen. Vervolgens neem je samen de code door en wacht totdat de junior developer zelf inziet wat er niet goed is gegaan. In het begin zal je hier actief bij moeten begeleiden als medior developer maar naarmate het kennis niveau omhoog gaat wordt dit steeds minder.

Verandering

Wanneer je Pair Programming introduceert is het belangrijk om de context zoals hierboven beschreven mee te geven en de mensen die het betreft mee te nemen in deze manier van werken. Ik heb bij organisaties gewerkt waarbij er werd aangegeven dat Pair Programming werd aangemoedigd, maar of teams dat wel of niet deden werd niet naar gekeken. Ook ontbrak het aan begeleiding van de teams en de teamleden.
Wanneer je een verandering wil doorvoeren is het door Nieuwenhuis beschreven 'Bouwstenen van Groei en Verandering' een goed uitgangspunt (zie afbeelding hieronder).
Bouwstenen van Groei en Verandering
Alle aspecten zijn nodig om een verandering effectief door te voeren. Ik zal twee voorbeelden eruit halen,

Middelen

Wanneer je Pair Programming introduceert hoef je geen grote investeringen te doen. Wel moet je ervoor zorgen dat er bijvoorbeeld voldoende ruimte is om met twee mensen achter één PC te zitten. Ook schermen die groot genoeg zijn om mee te kijken zijn nodig, als je samen achter één laptop scherm moet zitten dan werkt het niet. Zijn de middelen niet op orde dan frustreert dit heel erg en zal men snel geneigd zijn weer achter zijn of haar eigen PC te gaan zitten.

Resultaten

Als we in een organisatie Pair Programming gaan doorvoeren en we meten niet wat de resultaten zijn, dan kan het worden ervaren als nutteloos. Uit onderzoek is dan wel gebleken dat er een verlaging van productiviteit is en een verhoging van kwaliteit, maar is dat bij ons ook wel zo? Niet meten en inzichtelijk maken geeft een voedingsbodem om hieraan te twijfelen en kan ervoor zorgen dat de verandering niet lukt. Mensen ervaren het dan als iets wat geen toegevoegde waarde heeft.

Conclusie

Pair Programming kost inderdaad iets meer tijd, op korte termijn lijkt het individueel werken dan ook een betere oplossing. Echter, de kwaliteit van het geleverde werk gaat significant omhoog en dat betekent dat het al snel meer oplevert dan dat het kost doordat je minder tijd hoeft te besteden aan het oplossen van fouten. Ook de andere voordelen moet je meewegen, Code review, Kennisoverdracht en het opleiden van de junior en medior developers is nog een mooie bonus. Let er wel op dat het introduceren van Pair Programming begeleid moet worden, anders is de kans dat het geen succes wordt heel groot.

Marcel Groennou, DevOps Consultant