Meerdere agents tegelijk

Als drie agenten tegelijk werken, krijg je drie wijzigingen tegelijk terug. Die moet je alle drie begrijpen voordat je ze samenvoegt. Beoordelen kost meer aandacht dan produceren, en dat deel kun je niet uitbesteden zonder de controle kwijt te raken.

Daar komt bij dat parallelle agenten elkaars werk niet zien. Twee agenten die allebei een hulpfunctie nodig hebben, schrijven er allebei een. Je krijgt geen conflict, je krijgt dubbel werk dat er allebei redelijk uitziet.

Er zit ook een minder zichtbaar effect in. Als één agent werkt, bouw je terwijl je meeleest een beeld op van wat er in je project verandert. Bij drie tegelijk verdwijnt dat beeld. Je krijgt drie resultaten en moet ze los van elkaar reconstrueren, zonder dat je het ontstaan hebt gevolgd. Dat kost aantoonbaar meer moeite dan drie keer achter elkaar meekijken.

Dat is de reden dat teams die dit een tijdje doen, meestal terugvallen op twee: één die werkt aan de klus waar de aandacht ligt, en één die iets uitzoekt of voorbereidt waar je later naar kijkt. Dat past nog binnen wat een mens kan volgen.

Er is één vorm van parallel werken die in de praktijk vrijwel altijd wint, en dat is: één agent bouwt, de andere bereidt voor. Terwijl jij met de eerste aan het werk bent, laat je de tweede uitzoeken hoe een koppeling werkt, welke bibliotheek geschikt is, of hoe de foutmelding van gisteren te reproduceren is.

Dat werkt omdat de tweede agent niets aanraakt. Hij levert informatie op, geen code. Daarmee vervallen alle conflicten in één klap, terwijl je wel het voordeel houdt dat er twee dingen tegelijk gebeuren. De beoordelingslast blijft laag, want een verslag lezen is iets anders dan een wijziging nakijken.

Wie hierin een ritme vindt, komt verder dan wie drie agents tegelijk laat bouwen. Het is minder spectaculair en het levert meer op, wat vaker geldt dan mensen leuk vinden.

Twee agenten die allebei een gebruiker moeten opslaan, verzinnen allebei een eigen naam voor hetzelfde veld. Je krijgt geen foutmelding; je krijgt twee stukken code die naast elkaar bestaan en pas botsen als iemand ze koppelt. De oplossing is saai en werkt: leg de gedeelde namen vooraf vast in één bestand dat allebei de agenten als uitgangspunt krijgen.

Hetzelfde geldt voor afhankelijkheden. Spreek af welke versies je gebruikt en laat geen agent zelfstandig pakketten bijwerken terwijl een ander doorbouwt op de oude versie. Eén bijgewerkt pakket kan het werk van de ander onbruikbaar maken zonder dat er iets rood wordt.

En leg vast wie waar mag schrijven. Niet als bureaucratie, maar omdat het de enige manier is waarop parallel werken zonder samenvoegconflicten verloopt. Eén agent per map is de simpelste regel die werkt.

Kijk elke wijziging apart na voordat je iets samenvoegt, en doe dat in de volgorde van klein naar groot. Begin met de agent die het minste heeft aangeraakt: die is het snelst te beoordelen en zijn resultaat verkleint de ruis waarin je de volgende leest.

Zoek daarna gericht naar overlap. Twee dingen die hetzelfde doen met een andere naam, twee plekken waar dezelfde waarde is vastgelegd, twee versies van dezelfde hulpfunctie. Dat vind je door te zoeken op de kern van wat er gebouwd is, niet door de wijzigingen naast elkaar te leggen.

En draai alles pas samen als het los is nagekeken. De verleiding is om drie takken tegelijk samen te voegen en dan te kijken of het nog werkt. Als er dan iets stuk is, weet je niet meer welke agent het deed, en ben je meer tijd kwijt dan je met parallel werken hebt gewonnen.

Alles wat nog niet vastligt, doe je serieel. Als je nog aan het uitzoeken bent hoe iets moet werken, verandert het antwoord op vraag één de vraagstelling van vraag twee. Drie agenten die tegelijk aan een onopgeloste vraag werken, leveren drie antwoorden op een vraag die je verkeerd hebt gesteld.

Hetzelfde geldt voor werk dat over hetzelfde scherm of hetzelfde stuk logica gaat. De verleiding is groot, want het lijkt op te knippen in 'de knop' en 'het formulier'. In de praktijk delen die één stuk toestand en loop je vast in het samenvoegen.

De vuistregel die overblijft: parallel werken is voor werk dat je vooraf kunt beschrijven zonder naar de andere taak te kijken. Kun je dat niet, dan is het geen twee taken maar één taak die je nog niet doorziet.