· 7 min lezen
Zes maanden pull requests lezen: wat het je vertelt en wat niet.
Zes maanden pull requests is het eerlijkste verslag dat een engineeringorganisatie bijhoudt, maar maar twee dingen erin zijn de moeite waard om te lezen: hoe lang een wijziging op review wacht, en hoeveel mensen elk deel van het systeem kunnen aanraken. Die twee signalen, reviewdoorlooptijd en de spreiding van eigenaarschap, vertellen je waar levering vastzit en waar het bedrijf een ontslag verwijderd is van problemen. Het aantal commits, de regels code en wie de meeste pull requests sloot, vertellen je vrijwel niets, en mensen erop rangschikken maakt de echte problemen moeilijker zichtbaar.
Wat je waarschijnlijk is aangereikt
Als ik een diagnose begin, krijg ik meestal eerst een dashboard. Het telt commits per engineer, tekent toegevoegde en verwijderde regels, en rangschikt mensen op gemergede pull requests. Het ziet eruit als inzicht omdat het van echte gebeurtenissen is gemaakt. Het is geen inzicht. Het meet hoeveel tekst bewoog, niet of de juiste wijziging werd gemaakt, en het beloont stil net het gedrag dat je het minst wil: grote batches, rumoerige refactors, en activiteit om de activiteit. Ik heb een team gezien waar de drukste naam op dat dashboard net de ene persoon was om wie de meeste anderen heen werkten.
De pull request-geschiedenis onder dat dashboard is iets anders, en ze is echt bruikbaar. Elke wijziging die het team maakte staat erin, met een tijdstempel voor wanneer ze werd geopend, wie ze reviewde, hoe lang ze wachtte, en wat ze aanraakte. Rechtstreeks gelezen, in de juiste volgorde, beantwoordt ze twee vragen die meer tellen dan welk productiviteitscijfer ook: waarom voelt levering traag, en waar zou het het meest pijn doen als een persoon vertrok. Het dashboard verstopt beide achter een ranglijst.
Wat de pull requests je echt vertellen
Het eerste echte signaal is de reviewdoorlooptijd: de tijd tussen een wijziging die klaar is en een die gemerged wordt. Hier lekt levering weg zonder dat iemand besliste dat het zo hoorde. Een team kan snel code schrijven en toch traag leveren omdat elke wijziging drie dagen op een review wacht, en dat wachten verschijnt nooit op een roadmap of in een standup. Als de doorlooptijd hoog is en op een of twee reviewers geconcentreerd zit, heb je een knelpunt gevonden dat geen enkele aanwerving oplost, want de beperking is een persoon die de enige poort is geworden, geen tekort aan handen. Soms is het vertrouwen: senior mensen geloven niet dat de rest mag mergen. Soms is het gewoon overbelasting. De geschiedenis vertelt je welke van de twee, door te tonen in wiens wachtrij de wijzigingen staan.
Het tweede echte signaal is de spreiding van eigenaarschap: hoeveel verschillende mensen in elk deel van het systeem wijzigingen schrijven en reviewen. Richt de geschiedenis op mappen in plaats van op mensen en het key-person-risico tekent zichzelf. Een service die zes maanden lang door een naam wordt aangeraakt, is een bus factor van een, op voorhand opgeschreven voor de dag dat die persoon opzegt. Hetzelfde patroon aan de reviewkant is stiller en even gevaarlijk: een gebied waar elke wijziging door dezelfde reviewer wordt goedgekeurd, heeft een enkel punt van oordeel, en als die persoon vertrekt, kan niemand nog zeggen of een wijziging eraan veilig is. Dit is dezelfde leegte in eigenaarschap die ik beschrijf in een lead developer, twee agencies, geen CTO, hier zichtbaar als data in plaats van als een gevoel.
Wat je leest, in volgorde
Een bruikbare lezing kost een namiddag en gaat in deze volgorde.
- De verdeling van de doorlooptijd, niet het gemiddelde. Kijk naar de tijd van klaar-voor-review tot merge over alle pull requests, en kijk dan naar het traagste tiende. Het gemiddelde verbergt het probleem; de staart is het probleem. Een mediaan van enkele uren met een lange staart van wijzigingen die een week wachtten, vertelt je dat sommig werk eersterangs is en sommig stil vastzit, en je wil weten welk.
- Op wie de reviews wachten. Groepeer de trage pull requests op wie ze uiteindelijk reviewde. Zitten een of twee namen onder het meeste wachten, dan is de beperking reviewcapaciteit, niet schrijfcapaciteit. Dat is een andere fix: spreid het mandaat om goed te keuren, werf geen extra schrijver aan om in dezelfde wachtrij te staan.
- Eigenaarschap per gebied. Breng auteurs en reviewers in kaart per map of service. Markeer alles wat over het hele venster door een enkele persoon wordt aangeraakt of goedgekeurd. Elke markering is een benoemd risico om nu aan te kaarten, terwijl die persoon er nog is om op te schrijven wat alleen zij weet.
- De omvang en timing van pull requests. Een geschiedenis van grote wijzigingen die aan het eind van elke sprint in een stormloop gemerged worden, is een team dat werk batcht omdat vaak integreren onveilig aanvoelt. Kleine, gestage wijzigingen zijn een team dat zijn pijplijn vertrouwt. De vorm van de wijzigingen vertelt je hoe het team zich echt voelt bij zijn eigen systeem.
- Herwerk na merge. Wijzigingen die worden teruggedraaid of meteen gepatcht, wijzen op een plek waar het team niet kan zeggen of een wijziging juist is voordat ze live gaat. Dat is meestal een gat in tests of in eigenaarschap, en het verdient meer aandacht dan het volume van wie dan ook.
Geen van deze stappen rangschikt een persoon. Elke stap benoemt een plek in het systeem waar levering traag is, kennis dun, of vertrouwen afwezig, en elke stap wordt een concreet ding om volgende week te veranderen.
Wat je negeert, en waarom het misleidt
Het aantal commits meet een gewoonte, geen output. Een team dat elke branch tot een commit squasht en een team dat veertig kleine commits merget, zien er wild verschillend uit op dit cijfer terwijl ze identiek werk doen. Regels code zijn erger, want ze belonen net de verkeerde dingen: gegenereerde code, een formatteringsveeg en een kopieer-plak scoren allemaal hoog, terwijl de regel die het incident oplost bijna nul scoort. Gemergede pull requests per persoon is een ranglijst, en zodra mensen weten dat je telt, meet ze niets meer behalve wie bereid is zijn werk op te splitsen om het spel te spelen. De engineers die het systeem stil overeind houden, zorgvuldig reviewen, begeleiden, de riskante delen stabiel houden, scoren bescheiden op alle drie en zijn meestal net degenen die je je het minst kan permitteren te verliezen. Rangschik op deze cijfers en je richt je aandacht op precies de verkeerde mensen.
Wanneer de pull requests niet de plek zijn om te kijken
De geschiedenis is een input, geen oordeel. Ze is blind voor alles wat nooit een pull request werd: het goede idee dat in een vergadering sneuvelde, het productie-incident dat om middernacht met de hand werd opgelost, de architectuur die in een direct bericht werd beslist en nooit werd opgeschreven. Ze kan je niet vertellen of het werk het juiste werk was, of het ontwerp deugt, of een individu goed is in de job, en wie je zegt dat ze dat wel kan, verkoopt je opnieuw het dashboard. Is de vraag of het team het juiste ding bouwt, dan beantwoorden de pull requests ze niet. Is de vraag of een bepaalde persoon moet blijven, probeer dat dan niet uit zijn commitgeschiedenis te beslechten; dat is een gesprek, en de data geeft je alleen vals vertrouwen. Lees de pull requests om te vinden waar verandering traag is en waar eigenaarschap dun is, en kruis wat je vond daarna met incidenten, levering, en de mensen zelf. Die triangulatie, geen enkele bron, is waar een gestructureerde diagnose voor dient, en het is dezelfde discipline die het technische team van een koper toepast als het de repositories van een doelwit leest tijdens technische due diligence.
Veelgestelde vragen
Wat leer je uit het lezen van de pull request-geschiedenis van een team?
Twee dingen, betrouwbaar. Ten eerste de reviewdoorlooptijd: hoe lang een wijziging wacht tussen klaar voor review en gemerged, en of dat wachten bij een of twee reviewers ligt. Een trage, geconcentreerde reviewwachtrij is het duidelijkste teken dat het team vastzit op een persoon in plaats van op het werk. Ten tweede de spreiding van eigenaarschap: hoeveel verschillende mensen in elk deel van het systeem wijzigingen schrijven en reviewen. Wordt een gebied door maar een naam aangeraakt, dan is dat key-person-risico dat je in de data ziet voordat iemand het je vertelt. De rest van de geschiedenis is context, geen signaal.
Zijn commits en regels code een goede maat voor productiviteit?
Nee, en ze zo lezen maakt het erger. Het aantal commits hangt af van squash- en rebasegewoontes, niet van output; regels code belonen gegenereerde code, verwijderingen en rumoerige refactors boven de harde, kleine wijziging die het echte probleem oplost. Beide zijn bewust op te krikken zodra mensen weten dat je erop let, en de engineers die erop sturen zijn zelden degenen die het systeem overeind houden. Gebruik de geschiedenis om te vinden waar verandering traag is en waar eigenaarschap dun is, niet om mensen op volume te rangschikken.
Wat is reviewdoorlooptijd en waarom telt ze?
Reviewdoorlooptijd is de tijd tussen een pull request die klaar is voor review en die gemerged wordt. Ze telt omdat levering er stil weglekt: een team dat snel code schrijft maar dagen op review wacht, levert traag, en dat wachten is meestal onzichtbaar op een roadmap. Hoge doorlooptijd die op een of twee reviewers geconcentreerd zit, wijst op een knelpunt, een vertrouwensprobleem, of een senior die de enige poort is geworden. Ze meten vertelt je veel preciezer waar je moet ingrijpen dan het team vragen waarom releases traag aanvoelen.
Wat vertelt de pull request-geschiedenis je niet?
Ze vertelt je niet of het werk het juiste werk was, of de architectuur deugt, of een individu goed is in de job. De geschiedenis legt vast hoe wijzigingen door het systeem bewogen, niet of ze gemaakt hadden moeten worden. Ze is blind voor alles wat nooit een pull request werd: de vergadering die een goed idee doodde, het productie-incident dat met de hand werd opgelost, de ontwerpbeslissing in een direct bericht. Lees ze als een input in een diagnose, gekruist met incidenten en de mensen, nooit als een oordeel over een persoon of een team op zich.
Geschreven vanuit patronen uit eerdere opdrachten. Als iets te specifiek klinkt om algemeen te zijn, is dat de reden.