Vier voordelen van samen programmeren

In een serie blogs kijkt Dennis van der Salm, senior Pega-architect bij BPM Company, naar efficiënt versus effectief werken, naar werken op basis van rollen versus werken op basis van vaardigheden en naar verschillende programmeerstijlen. Hij vroeg zich in een eerdere blog af in hoeverre werken op basis van rollen nog werkt binnen de IT-branche. In deze blog zoomt hij in op programmeerstijlen en vertelt hij wat het samenbrengen van disciplines je kan brengen.

Werken op basis van rollen

‘Dus jullie werken samen en focussen op hetzelfde? Dat is niet erg productief!’ Deze opmerking krijg ik regelmatig als ik mensen uitleg hoe ik werk. Daar denk ik anders over. Aan het begin van mijn carrière werkte ik in een team waar we een vrij standaard manier van werken hadden. Product-owners schreven de user-stories. De bedrijfsanalist onderzocht die stories. Tijdens refinement-sessies werden de details overgedragen aan de rest van het team en ging een ontwikkelaar solo aan de slag met een van die user-stories. Zodra de ontwikkelaar klaar was, beoordeelde de meest ervaren ontwikkelaar van het team de code. Tenslotte werd het geheel aan een tester overhandigd waarna het uiteindelijk door mensen van operations naar de productieomgeving werd doorgezet. Een manier van structureren die is gebaseerd op The principles of Scientific Management, zoals ik ook beschreef in mijn eerdere blog. Hoe efficiënt is het werken op basis van rollen eigenlijk? Laten we eens inzoomen op de rol van de ontwikkelaars.

Pair-programmeren niet zo extreem

Een paar jaar geleden las ik de artikelen van Kent Beck over Extreme Programming. Tja, je bent jong en het woord ‘extreem’ trekt dan natuurlijk je aandacht. Mijn verwachtingen waren hooggespannen, maar toen ik het boek uit had, was ik op z’n zachtst gezegd een beetje teleurgesteld. Bijna niets in zijn boek leek extreem. Het leek allemaal gezond verstand! Een van de belangrijkste topics van het boek is ‘pair programming’: twee ontwikkelaars werken samen naar een oplossingen toe. Maar wat brengt dat eigenlijk voor voordelen met zich mee? Ik zie er vier.

De vier voordelen van pair-programmeren

1. Voortdurende beoordeling van code

Het beoordelen van code verhoogt – uiteraard – de kwaliteit van de code en vermindert de kans op bugs. Bij pair-programmeren wordt de code in feite continu beoordeeld.

2. Kennis delen ‘on the job’

Bij pair-programmeren begeleidt de senior ontwikkelaar de minder ervaren programmeurs. Junior ontwikkelaars en nieuwe toetreders kunnen op die manier meteen aan de slag en zijn direct productief.

3. Kennisborging

Doordat meerdere mensen uitgebreide kennis over de applicatie hebben, gaat er minder kennis verloren als iemand vertrekt. Dit is nog handiger voor externen, zoals ik, die een paar jaar voor een klant werken.

4. Een breder verantwoordelijkheidsgevoel voor de hele applicatie

Een solo-ontwikkelaar die aan een stukje code werkt, voelt zich alleen verantwoordelijk voor dat stuk code. Als er op een later moment in het traject een verandering nodig is, moet die specifieke persoon het doen omdat ‘hij het heeft gebouwd’. Bij pair-programmeren voelen beide ontwikkelaars zich verantwoordelijk voor de volledige code van de applicatie.

Hoe dichter bij de oplossing, hoe minder waarde

In een van zijn Tweets, stelt Beck dat pair-programmeren het best werkt als er nog weinig bekend is over wat er gedaan moet worden. Hoe dichter bij een oplossing je komt, hoe minder pair-programmeren toevoegt. Een terecht punt. Hoe meer er bekend is, zowel in termen van wat er gedaan moet worden als waar het gaat om de kennis van de ontwikkelaar, hoe minder pair-programmeren je zal helpen. Ik heb het zelf ervaren toen ik aan het begin van een onderwerp stond, de pair-programmeersessies intenser waren en dus meer impact hadden. Zodra de details bekend waren en de ontwerpen en oplossingen duidelijk waren, nam de impact van pair-programmeren af. In dat stadium ging het vooral om het vermijden van fouten, wat nog steeds erg waardevol is omdat je flink hoofdpijn kunt krijgen van debuggen!

Niets te verbergen

Pair-programmeren kan best moeilijk zijn. Je moet je ego loslaten. Je kunt immers niet verbergen als je iets niet weet. Daar is op zich niets mis mee, maar dat kan lastig zijn. Experimenteren en voortdurend met elkaar in gesprek zijn, staat centraal. Dat kan vanaf moment één tot een geweldig resultaat leiden, maar het kan ook zijn dat je dingen nog een paar keer moet verbeteren om het te laten werken. Martin Fowlers schreef een waardevol artikel over pair-programmeren, met praktische tips. Wil je nog een stap verder gaan in het samen ontwikkelen van applicaties? Dan is mob-programmeren wellicht een goede optie.

Wondermiddel

Is pair-programmeren een wondermiddel? Nee. Het is een waardevol hulpmiddel dat je kunt inzetten om uitdagingen effectief aan te pakken. Probeer te experimenteren met de tools, probeer ze onder de knie te krijgen en gebruik ze in de juiste context.

Meer weten?

In toekomstige blogs ga ik dieper in op dit onderwerp. Ik kijk naar efficiënt versus effectief werken, naar werken op basis van rollen versus werken op basis van vaardigheden en naar verschillende programmeerstijlen. Heb jij ook het gevoel dat de afdelingsoverstijgende processen efficiënter en beter kunnen en wil je snel een eerste inzicht in de mogelijkheden? Neem vrijblijvend contact met ons op. We leren je graag kennen!