Zolang ik al in de software zit, wordt er al gesproken over de 10x ontwikkelaar. Dit zijn de mensen die je problemen moeten oplossen; ze doen het in 1/10 van de tijd, met 1/10 van het aantal regels code. Ze klinken geweldig.
Maar waar komt die term vandaan? Bestaan ze? En zelfs als ze bestaan, zou je er dan een willen zijn?
Tom DeMarco en Tim Lister hebben sinds 1977 de “Coding War Games” gehouden. Dit is een openbaar productiviteitsonderzoek waarbij teams van software-uitvoerders uit verschillende organisaties het tegen elkaar opnemen om een reeks benchmarks in een zo kort mogelijke tijd met zo min mogelijk fouten te voltooien. Er hebben meer dan 600 ontwikkelaars aan deelgenomen.
Wat hebben zij geleerd?
- De keuze van de programmeertaal had weinig invloed – of het nu COBOL/Fortran was of een taal op hoog niveau zoals Pascal, de spreiding van de resultaten is ongeveer gelijk. De enige uitzondering was assembleertaal.
- Er was geen correlatie tussen ervaring en prestatie, behalve dat degenen met minder dan zes maanden ervaring met een taal het niet zo goed deden als de anderen.
- De ontwikkelaars van zero-defect oplossingen betaalden geen prestatiestraf voor het uitvoeren van nauwkeuriger werk (in feite namen ze iets minder tijd in beslag!).
Ze ontdekten wel dat er enorme verschillen waren tussen de organisaties. De beste organisatie werkte 11,1 keer sneller dan de slechtste. Bovendien ontwikkelden degenen die het snelst werkten code die door de acceptatietest kwam. Zaak gesloten?
Wel, niet helemaal. De studie gaat verder met het correleren van de werkomgeving (die verschilt per organisatie) met de prestaties. Het blijkt dat de groep met een rustige, besloten en speciale werkruimte significant beter presteerde.
Les geleerd – zorg eerst voor een goede werkomgeving voordat je je druk gaat maken over de vraag of je 10x ontwikkelaars kunt vinden of niet!
De netto negatief producerende programmeur
Schulmeyer merkt op dat sommige ontwikkelaars “netto negatief producerende programmeurs” (NNPP) zijn, dat wil zeggen dat ze zoveel defecten produceren dat verwijdering uit het team de productiviteit verhoogt. Dit is bijna het tegenovergestelde van de 10x ontwikkelaar – het is mogelijk om iemand in het team te hebben die het slechter maakt.
Als er negatieve producenten bestaan (- Nx ontwikkelaars?) dan is het duidelijk mogelijk om een 10x ontwikkelaar te hebben (wiskunde daargelaten).
Het is echter niet het beste argument voor de 10x programmeur, of wel? Als ik een schoolkind zou vragen om in een team te komen, zou dat dan een netto negatieve producent zijn? Waarschijnlijk wel, als ik ze in een hoekje laat zitten en wat code in elkaar laat rammen (en als ze op de een of andere manier tot productie kunnen overgaan!). Als je het soort bedrijf bent dat mensen in een hoekje laat zitten, geen feedback geeft en ze naar productie laat duwen, dan denk ik dat je het waarschijnlijk verdient om NNPP’s in je team te hebben!
Meer realistisch, ik hoop dat in elk normaal bedrijf als je iemand in dienst neemt, je ze alle steun geeft die ze nodig hebben om geweldig te zijn in hun rol (peer code-review, feedback, een mentor, geautomatiseerde code-analyse voor feedback, leermateriaal etc.)
Ik denk dat het nog steeds mogelijk is dat je eindigt met een NNPP, maar ik vermoed dat het zeer onwaarschijnlijk is. Dit lijkt me in ieder geval niet het beste verhaal voor het bestaan van 10x ontwikkelaars.
Exploratory experimental studies comparing online and offline programming performance
Sackman, Erikson, Grant publiceerden in 1968 een paper genaamd “Exploratory experimental studies comparing online and offline programming performance”. Een van de citaten aan het eind gaat over individuele verschillen en de studies “onthulden grote individuele verschillen tussen hoge en lage prestaties, vaak met een orde van grootte”. Zou dit het magische artikel zijn waarin dat verschil van 10x wordt beschreven?
Het loont de moeite om de hele studie te lezen en een en ander in de juiste context te plaatsen. Ten eerste werden bij deze tests zowel de prestaties met pen en papier vergeleken als online met behulp van een IBM AN/FSQ-32. Programmeurs schreven hun code (hetzij op pen/papier om aan een operator te geven, of direct in de computer) met behulp van een taal genaamd JTS (een ALGOL derivaat).
Ze moesten twee taken oplossen, de eerste was het interpreteren van algebraïsche vergelijkingen met een enkele afhankelijke variabele. Ze kregen de paper van Samelson en Bauer om te helpen de oplossing te implementeren. Een afbeelding uit het document staat hieronder:
De tweede taak was het oplossen van een 20×20 doolhof dat precies één pad heeft. Het doolhof werd beschreven door een opzoektabel met 400 elementen, waarbij elke invoer informatie bevatte over de uitgangen van elke cel. Voor deze uitdaging werd geen ondersteunend materiaal verstrekt. Het oplossen van doolhoven is een fascinerend probleemgebied en ik denk dat degenen die recent een cursus grafentheorie hadden gevolgd, een groot voordeel hadden!
Nu ik deze opgaven ken, verbaast het me niet dat er grote individuele verschillen zijn. In 1968, was software engineering nog maar net geboren als een discipline. De taken zijn wiskundig van aard en het is niet duidelijk wat de achtergrond van de deelnemers was. Het zou zeker diegenen bevoordelen die wiskundecursussen op een hoger niveau hebben gevolgd.
Ik denk dat de 10x persoon die je hieruit zou vinden, begaafd is in het oplossen van deze problemen. Ik kan geloven dat in de probleemruimte van “het oplossen van een doolhof + lineaire vergelijkingen” er een 10x ontwikkelaar kan zijn, maar het is moeilijk dat dit zou overgaan naar een ander domein.
Zou ik een 10x ontwikkelaar zijn?
Mogelijk. Maar waarschijnlijk 10x beter in het schrijven van code.
Er is een veel betere bespreking van de onderzoeksmethoden achter de 10x ontwikkelaar mythe in dit uitstekende boek. Zelfs als een 10x ontwikkelaar bestaat, moet je er waarschijnlijk niet naar streven er een te zijn; zelfs als je code de eerste keer perfect kunt implementeren, zul je er waarschijnlijk achter komen dat je in de eerste plaats het verkeerde probleem aan het oplossen was.
Zelfs als deze onderzoeken waar zouden zijn, is software engineering verder gegaan (althans in mijn domein van productontwikkeling).
Vroeger deden we misschien één grote release per jaar, hadden we een aantal requirements en spendeerden we een jaar aan de implementatie ervan. Dit is veranderd in een agile aanpak waar er een voortdurende cyclus van eliciting, verbeelden, implementeren en verifiëren. In dit model is implementatie (meestal) niet de bottleneck
Een uur besparing op de niet-bottleneck is een fata morgana. (Eliyahu Goldratt)
Dus wat moet u in plaats daarvan doen? Concentreer u op het verhogen van de waarde voor uw bedrijf. Kun je:
- Waardevolle problemen voor je bedrijf identificeren?
- Een oplossing ontwerpen die mensen kunnen gebruiken?
- Feedback verzamelen om te beoordelen of het waardevol is?
- Software schrijven die echt verschil maakt voor echte mensen?
- Focussen op de echte problemen in plaats van op de interessante?
- Leden in het team laten groeien tot geweldige mensen?
En nog een miljoen en één dingen die waardevoller zijn dan het schrijven van perfecte code in recordtijd (zie t-shaped!).
Dit wil niet zeggen dat coderen niet belangrijk is. Codering is belangrijk! Code wordt 4x meer gelezen dan geschreven, dus als je makkelijk te beredeneren code schrijft dan betaalt zich dat in de toekomst enorm uit (misschien zit er ergens een 10x verhaal in, maar dat laat ik voor een andere dag). Tijd investeren in je vak (of het nu coderen of ontwerpen of projectmanagement is) is een must, maar vergeet niet dat je vak niet op zichzelf staat en bestaat om een hoger doel te dienen.
Focus je niet alleen op het zijn van de beste ontwikkelaar ter wereld, focus je op het grotere geheel (denk aan Product boven Project!). Leer een brede set vaardigheden (vooral die vaardigheden die met mensen te maken hebben) en je zult veel waardevoller zijn en veel dichter bij een echte 10x “ontwikkelaar” komen.