Van badeendjes tot developers: geweldige software kan alleen samen ontwikkeld worden
Ben je wel eens urenlang bezig geweest met kruiswoordpuzzels? Je staart je blind en vervolgens loopt er iemand langs die het raadsel binnen enkele seconden oplost. Dan ben je zeker niet de enige. Dit fenomeen staat ook wel bekend onder de term ‘target fixation’. Solo werken aan een diepgaand project zorgt vaak voor blinde vlekken, waardoor je dingen over het hoofd ziet. Voor programmeurs is het belangrijk om zich bewust te zijn van ‘target fixation’ en dit zoveel mogelijk te voorkomen, vooral omdat software ontwikkeling precies het werk is dat snel leidt tot tunnelvisie.
Een goede gewoonte voor developers is om hun code met regelmatige tussenpozen door een tweede paar ogen te laten beoordelen, ook wel een code review genoemd. Veel programmeurs zullen dit waarschijnlijk al doen. Echter, traditionele code reviews zijn vaak erg beperkt omdat ze pas inzicht geven als er al tijd is geïnvesteerd in het schrijven van de code. Laten we met dit in gedachten eens kijken naar een aantal effectieve en efficiëntere routes die kunnen worden genomen om de problemen van solowerken op te lossen.
In de versnelling met Rubber Duck Debugging
De beroemde methode van Rubber Duck Debugging (RDB) van Andrew Hunt en David Thomas lijkt misschien vreemd voor buitenstaanders, maar helpt developers bij het oplossen van coderingsproblemen door ze regel voor regel uit te leggen aan een badeendje. Op deze manier worden developers gedwongen om na te denken over hoe ze problemen kunnen uitleggen aan iemand zonder programmeerkennis. Hierdoor kunnen ze problemen, waar ze zich blind op staren, beter in perspectief plaatsen en sneller oplossen.
Hoewel RDB een handige manier is om te voorkomen dat workflows worden onderbroken door developers die zoeken naar iemand die de code fysiek kan beoordelen, heeft het ook zijn nadelen. Ten eerste kunnen developers die in een kantoor of in een openbare ruimte werken zich ongemakkelijk voelen (erg begrijpelijk) bij het praten tegen levenloze objecten. Ten tweede is RDB meer een hulpmiddel om psychologische barrières voor developers te overwinnen, dan een methode om code te laten beoordelen door iemand anders dan jezelf.
Geprobeerd en getest: realtime code reviews tijdens pair programming
Twee developers, twee toetsenborden en één scherm – dat zijn de ingrediënten van pair programming. Met een paar developers die tegelijkertijd aan dezelfde functie werken, smelten niet alleen problemen zoals target fixation weg, maar neemt de kwaliteit van de code ook aanzienlijk toe als twee koppen samenwerken om een oplossing te bedenken die geen van beiden oorspronkelijk had voorzien.
Teams die actief pair programming toepassen, gecombineerd met het regelmatig wisselen van de paren, begrijpen de voordelen van kennisdelen met het hele team. Hierdoor kunnen teams snel werken aan nieuwe functies en tegelijkertijd productiviteit (velocity) meten en behouden.
Eén van de belangrijkste katalysatoren van innovatie bij het pair programming is diversiteit. Developers met bijvoorbeeld verschillen in ervaring, kennisgebieden en expertise, zullen waarschijnlijk samen innovatieve oplossingen ontdekken. Het is echter niet ongebruikelijk dat teams in dezelfde patronen en routines vervallen wat hun developers betreft als dezelfde groep mensen continu samenwerkt en zo dezelfde mindset erop nahoudt.
Uitbreiden
Een frisse blik erbij halen om feedback te geven kan een uitstekende manier zijn om de code vanuit een nieuw perspectief te bekijken. Jouw team is waarschijnlijk niet het enige technische team binnen de organisatie. Waarom zou je geen code reviews houden met een ander team? Het is nog beter als ze in verschillende technologieën of programmeertalen werken, omdat dit voor extra diversiteit zorgt en kan leiden tot betere inzichten.
Elk team deelt een deel van hun code dat volgens hen innovatief is, evenals een deel van de code waarvan zij denken dat het verbeterd kan worden. In tegenstelling tot een traditionele code review, die gericht is op het bekritiseren van een stukje code, zijn deze sessies gericht op het delen van advies, het opbouwen van wederzijds vertrouwen en openheid tussen collega’s om een grotere mate van kennisdeling aan te moedigen.
Waarom solowerken een grote ‘no go’ is
Communicatie is een fundamenteel principe van softwareontwikkeling. Mensen werken het beste als we openlijk kunnen handelen en ideeën kunnen delen. Om vooruit te komen, is het van cruciaal belang dat we kennis democratiseren en elkaar helpen als developers.
We moeten ons dus niet laten weerhouden door een gebrek aan mensen. Of het nu gaat om een partner, een groep collega’s of zelfs een badeend, het is essentieel om problemen vanuit het perspectief van een ander te bekijken. Blijf dus niet in je eigen wereld zitten. Geweldige software kan alleen samen ontwikkeld worden.
Derek Lee Boire, Senior Software Engineer at VMware Tanzu Labs
