Je kent ze vast wel, die handleidingen van de IKEA met hun “advies” om het product met z’n tweeën in elkaar te zetten. Negeer jij die ook altijd? En lukt het dan goed? Of denk je halverwege: “had ik maar 4 handen!”. Als er een handleiding was voor het ontwikkelen van software zou er wat ons betreft met koeienletters in staan dat je het werk minimaal met z’n tweeën moet doen. Waarom we hier zo van overtuigd zijn lees je in deze blog.
Het samenwerken van twee ontwikkelaars aan één probleem wordt pair programming genoemd. De twee ontwikkelaars die pairen delen dezelfde computer en kijken naar hetzelfde scherm. Er is één toetsenbord en één muis en er mag maar één ontwikkelaar aan de “knoppen” zitten, de ontwikkelaar die aan de knoppen zit wordt de “driver” genoemd. De andere ontwikkelaar wordt de “navigator” genoemd. Tijdens het ontwikkelproces wisselen de ontwikkelaars regelmatig van rol. Dit is in een notendop wat pairen in theorie is. Hoe dit in de praktijk gaat, terwijl we remote werken, vertel ik hieronder.
Praktijkvoorbeeld
Het is dinsdag en we beginnen met de standup. Mijn collega Vincent vertelt dat hij wil beginnen aan een nieuw stuk functionaliteiten en vraagt of iemand met hem wil pairen. Ik wil dat wel. Nadat de standup is afgelopen belt Vincent mij in via Tuple (een tool om als ontwikkelaars samen te werken). Samen nemen we de functionaliteit door, bespreken we de mogelijke oplossingsrichtingen en eventuele problemen. We zijn bezig een “plan of attack” te maken. Een onderdeel hiervan is het maken van een checklist van de stappen die wij denken te moeten doen om de functionaliteit te ontwikkelen. Wanneer we allebei begrijpen wat de gevraagde functionaliteit precies inhoudt en de oplossingsrichting hebben bepaald, beginnen we met programmeren.
We spreken af dat we om de 30 minuten wisselen van rol tijdens het pairen. Vincent begint als driver en ik als navigator. Ik wil beginnen met het schrijven van een geautomatiseerde test, zodat we kunnen valideren dat wat er gemaakt moet worden werkt. Pas wanneer de test geschreven is beginnen we aan de functionaliteit. Dit principe wordt Test Driven Development (TDD) genoemd. Hier ga ik op een later tijdstip in een andere blogpost meer over vertellen. Als de wekker gaat wisselen we van rol. Met mijn handen aan het toetsenbord ga ik verder waar Vincent gebleven is. Vincent navigeert mij nu door de code en samen ronden we de aanpassingen die nodig zijn af.
De functionaliteit blijkt nog niet goed te zijn. We gaan onderzoeken waarom dit zo is. Vincent oppert ideeën en ik haak daar op in. Al zoekende komen we een stuk code tegen waar we geen rekening mee hadden gehouden. Vincent stelt een oplossing voor en ik probeer daar gaten in te vinden. Op een gegeven moment komen we tot een theoretische oplossing en ik begin met het implementeren ervan. Dit gaat zo door terwijl we elke 30 minuten wisselen van rol. Totdat we een heleboel nieuwe tests en aanpassingen verder zijn, we zeker weten dat de functionaliteit geïmplementeerd is en alles werkt zoals afgesproken. We committen en pushen ons werk. Tien minuten later staat het op productie.
Voordelen
In het praktijkvoorbeeld hierboven gebeurt veel. Een van de meest waardevolle dingen hierin is de continue feedback loop naar elkaar. Vincent en ik zijn continu in gesprek met elkaar. De navigator stelt ideeën voor en de driver voert deze uit of stelt vragen om helder te krijgen wat de navigator bedoelt. Dit is ontzettend waardevol en de kracht van pairen. Een ander groot voordeel is het samen leren en de kennisoverdracht dat in het proces van samenwerken plaatsvindt. Stel nu dat ik in dit specifieke voorbeeld geen ervaring heb met een onderdeel van de applicatie en Vincent wel. Doordat Vincent en ik hier nu samen aan gewerkt hebben, wordt de kennis die Vincent heeft automatisch gedeeld met mij. Win-Win!
Wat ook een groot voordeel is, is dat wanneer we samen vertrouwen hebben in onze gemaakte code, deze direct naar productie gaat zonder een review van een andere collega. Dit is namelijk overbodig geworden omdat we elkaars code (onbewust) continu gereviewd hebben. Er is in dit geval geen noodzaak meer voor een extra paar ogen achteraf, aangezien er al twee paar hersenen gedurende de werkzaamheden over de code nagedacht hebben. Dit is onderdeel van het trunk based development principe waar ik in een ander blogpost meer over ga vertellen.
Teamwork
Je kunt nu de vraag stellen wie er verantwoordelijk is voor deze code. Vincent of ik? Het antwoord kan zijn allebei, maar ook dat klopt niet helemaal. Wij zijn onderdeel van een hecht team van ontwikkelaars. Het zou zomaar kunnen zijn dat Vincent morgen met een andere collega gaat pairen en ik ook. De gemaakte code is een team verantwoordelijkheid. Mocht er toch onverhoopt iets niet kloppen aan de code en andere collega’s komen er niet uit dan kan ik of Vincent helpen de bug op te lossen, of zelfs Vincent en ik samen met de andere collega’s. Maar dat is dan geen pair programming meer maar mobben. Wat mobben is en hoe wij als team daarin aan het leren zijn, daar vertellen we in de volgende blog alles over.
Geschreven door
