Aanvallend ontwikkelen of leunen op verdediging?

In een ontwikkelteam is het niet zo gangbaar om over de opstelling te praten als in de voetbalwereld. Toch zijn er veel parallellen te maken tussen beiden. In dit artikel doe ik een voorzet.

Hoewel je het in eerste instantie niet zou verwachten, vertonen sportteams veel overeenkomsten met ontwikkelteams. Dit wordt ook onderschreven door Alistair Cockburn in het boek Agile Software Development met als kernmerkende ondertitel The Cooperative Game . Hij concludeert uiteindelijk dat rotsklimmen het beste te vergelijken is met software-ontwikkeling. Dit komt met name door de twee elementen samenwerking en doelgerichtheid.

Wanneer we kijken naar bijvoorbeeld een voetbal- of hockeyteam, dan zien we dat er veel aandacht wordt besteed aan de samenwerking tussen de spelers. Er wordt daarnaast nagedacht over de rolverdeling: de aanvallers, middenvelders en verdedigers. In een ontwikkelteam is het eigenlijk niet veel anders, daar heb je de projectleiders, testers, ontwerpers en ontwikkelaars.

Nu bestaan er natuurlijk wel roltyperingen zoals de Belbin-groepsrollen: groepswerker, vormer, brononderzoeker, etc.. Maar deze verdeling geeft geen inzicht in de stijl van het programmeren waarmee ontwikkelaars te maken hebben.

Programmeerstijlen

Programmeerstijlen zijn vaak verbonden aan teams en de personen. In dit artikel richt ik mij op twee stijlen. De eerste stijl maakt gebruik van ‘defensive programming richtlijnen', terwijl de tweede die richtlijn niet volgt.

Defensive programming gaat over de hoeveelheid veronderstellingen die gemaakt worden tijdens het ontwikkelen van software. Dit zijn veronderstellingen in de trend van invoerparameters die altijd gevuld zijn of binnen bepaalde minima en maxima blijven. Bij defensive programming worden weinig of geen veronderstellingen gedaan en worden veel controles uitgevoerd die vervolgens leiden tot een keurige foutafhandeling.

Een defensieve ontwikkelaar werkt vaak volgens de handelwijze dat hij een stuk code vooraf goed uitdenkt en vervolgens pas invoert. Vervolgens zal hij tijdens het ontwikkelen blijven opletten dat er geen onverwachte excepties kunnen optreden en dat de exceptie-afhandeling ook goed in elkaar zit. Een kenmerk van deze ontwikkelaars is dat het altijd vrij lang duurt voordat de programmatuur klaar is, maar dat de kwaliteit dan meestal wel goed is. Er worden dan ook weinig fouten gevonden tijdens het testen en ook niet in productie.

Daarnaast zijn er ontwikkelaars die zo snel mogelijk, meestal via trial-on-error, de code in elkaar zetten. Deze ontwikkelaar veronderstelt vaak dat zaken aanwezig zullen zijn of op een bepaalde manier gevuld zullen zijn. Zolang deze veronderstellingen waar zijn levert het programma dezelfde uitvoer als die van de defensieve ontwikkelaar. De niet-defensieve ontwikkelaars vangen pas fouten af op het moment dat die voor het eerste optreden. Er ligt dus veel focus op de functie die het programma moet uitvoeren en minder voor de loodgieterswerkzaamheden eromheen. Van zo'n ontwikkelaar krijg je dus vaak snel een eerste oplevering, maar er zijn mogelijk nog enige bugfixes nodig om te komen tot stabiele programmatuur.

Stelling

Met deze informatie kom ik tot de conclusie dat de verdedigers in het voetbal ook defensieve ontwikkelaars zijn in het ontwikkelteam. De aanvallers bij voetbal komen overeen met de ontwikkelaars die de code in elkaar zetten en doen daarbij veel veronderstellingen. De middenvelders lijken dan de personen te zijn die de opruimwerkzaamheden doen om de aanval en verdediging aan elkaar te knopen. Een klein rondje door het voetbalheden of -verleden van collega's en vrienden lijkt deze stelling alleen maar verder te onderbouwen.

Optimale opstelling

 Wat te doen met deze kennis? De voordelen van deze rolpatronen zijn dat je een optimale teamsamenstelling kunt maken voor het maken van een bepaald programma. In het voetbal gaat altijd veel aandacht uit naar de spitsen die immers de doelpunten maken. Dit is ook in software-ontwikkeling iets waar een projectmanager of opdrachtgever zich toe kan laten verleiden. Veel focus op snelle oplevering van functionaliteit leidt vaak tot een flinke backlog (bijvoorbeeld in de vorm van een verzameling fouten) die later in een ontwikkeltraject terugkomt. Het is dus zaak om ook verdedigers en middenvelders op te nemen in het ontwikkelteam en hen ook zeker werkzaamheden te laten uitvoeren op het gebied van reviews. Ga eens na hoe jouw huidige team is opgebouwd en misschien is het zelfs verstandig om bij een volgende sollicitatie na te gaan of het karakter van de ontwikkelaar op deze manier te ontdekken is.