Sedan jag började jobba med mjukvara har det talats om 10x utvecklare. Det är dessa personer som du vill ha för att lösa dina problem; de kommer att göra det på en tiondel av tiden, med en tiondel av antalet rader kod. De låter fantastiska.
Men var kommer termen ifrån? Finns de? Och även om de finns, skulle du vilja vara en sådan ändå?
Tom DeMarco och Tim Lister har sedan 1977 genomfört ”Coding War Games”. Detta är en offentlig produktivitetsundersökning där grupper av programvaruimplementatörer från olika organisationer tävlar om att slutföra en rad benchmarks på minimal tid och med minimala fel. De har haft över 600 utvecklare som deltagit.
Vad lärde de sig?
- Valet av programmeringsspråk hade liten inverkan – oavsett om det var COBOL/Fortran eller ett högnivåspråk som Pascal är spridningen av resultaten ungefär densamma. Det enda undantaget var assemblagespråk.
- Det fanns ingen korrelation mellan erfarenhet och prestanda förutom att de som hade mindre än sex månaders erfarenhet av ett språk inte klarade sig lika bra som de andra.
- Utvecklarna av nollfelslösningar betalade ingen prestandabestraffning för att de utförde ett mer precist arbete (faktum är att de tog något mindre tid på sig!).
Det visade sig att det fanns stora skillnader mellan organisationerna. Den bästa organisationen arbetade 11,1 gånger snabbare än den sämsta. Dessutom utvecklade de som arbetade snabbast kod som klarade acceptanstestet. Ärendet avslutat?
Nja, inte riktigt. Studien fortsätter sedan med att korrelera arbetsmiljön (som skiljer sig åt mellan organisationerna) med prestationen. Det visar sig att gruppen med tysta, privata, dedikerade arbetsutrymmen presterade betydligt bättre.
Lärdomar – få ordning på arbetsmiljön först och främst innan du börjar oroa dig för om du kan hitta 10x utvecklare eller inte!
The Net Negative Producing Programmer
Schulmeyer observerar att vissa utvecklare är ”nettonegativt producerande programmerare” (NNPP), det vill säga att de producerar så många defekter att det ökar produktiviteten att ta bort dem från teamet. Detta är nästan motsatsen till 10x-utvecklaren – det är möjligt att ha någon i teamet som gör det sämre.
Om det finns negativa producenter (- Nx-utvecklare?) så är det helt klart möjligt att ha en 10x utvecklare (matematik bortsett från).
Det är dock inte det bästa argumentet för en 10x programmerare, eller hur? Om jag bad ett skolbarn att gå med i ett lag, skulle de då vara en nettonegativ producent? Förmodligen, om jag låter dem sitta i ett hörn och slå in lite kod (och om de på något sätt kan gå till produktion!). Om ni är ett företag som låter folk sitta i ett hörn, inte ger någon feedback och låter dem gå i produktion så tycker jag att ni förtjänar att ha NNPP:s i ert team!
Mer realistiskt sett hoppas jag att om du anställer någon på ett normalt företag så hoppas jag att du kommer att ge honom eller henne allt stöd som han eller hon behöver för att bli fantastisk i sin roll (kollegial kodgranskning, återkoppling, en mentor, automatiserad kodanalys för återkoppling, läromedel etc.)
Jag antar att det fortfarande är möjligt att du skulle kunna hamna i en NNPP, men jag misstänker att det är mycket osannolikt. Detta verkar verkligen inte vara den bästa berättelsen för existensen av 10x utvecklare.
Exploratory experimental studies comparing online and offline programming performance
Sackman, Erikson, Grant publicerade 1968 en artikel med titeln ”Exploratory experimental studies comparing online and offline programming performance”. Ett av citaten i slutet handlar om individuella skillnader och studierna ”avslöjade stora individuella skillnader mellan hög och låg prestanda, ofta med en storleksordning”. Kan detta vara det magiska dokumentet som beskriver den 10 gånger större skillnaden?
Det lönar sig att läsa hela studien för att få ett sammanhang kring detta. För det första jämfördes i dessa tester både prestanda med penna och papper och online med hjälp av en IBM AN/FSQ-32. Programmerarna skrev sin kod (antingen på papper och penna för att ge den till en operatör eller direkt i datorn) med hjälp av ett språk som heter JTS (ett ALGOL-derivat).
De hade två uppgifter att lösa, den första var att tolka algebraiska ekvationer med en enda beroende variabel. De fick Samelsons och Bauers papper som hjälp för att genomföra lösningen. En bild från uppsatsen visas nedan:
Den andra uppgiften var att lösa en 20×20 labyrint som har exakt en väg. Labyrinten beskrevs av en uppslagstabell med 400 element där varje post innehöll information om utgångarna i varje cell. Inget stödmaterial tillhandahölls för denna uppgift. Labyrintlösning är ett fascinerande problemområde och jag skulle gissa att de som hade gått en kurs i grafteori nyligen hade en stor fördel!
Med tanke på dessa uppgifter är jag inte förvånad över att det finns stora individuella skillnader. År 1968 var programvaruteknik bara nyss född som en disciplin. Uppgifterna är av matematisk karaktär och det är oklart vilken bakgrund deltagarna hade. Det skulle säkert gynna dem som läst matematikkurser på högre nivå.
Jag tror att den 10x person man skulle hitta från detta är begåvad för att lösa dessa problem. Jag kan tro att det inom problemområdet ”lösa en labyrint + linjära ekvationer” kan finnas en 10x-utvecklare, men det är svårt att detta skulle överföras till något annat område.
Skulle jag vara en 10x-utvecklare?
Troligtvis. Men förmodligen 10x bättre på att skriva kod.
Det finns en mycket bättre diskussion om forskningsmetoderna bakom myten om 10x utvecklare i denna utmärkta bok. Även om det finns en 10x-utvecklare bör du förmodligen inte sträva efter att bli en sådan; även om du kan implementera kod perfekt första gången kommer du förmodligen att upptäcka att du löste fel problem från början.
Även om dessa studier skulle vara sanna har programvarutekniken gått vidare (åtminstone inom min domän för produktutveckling).
Förr i tiden kunde vi kanske göra en enda stor utgåva per år, ha några krav och spendera ett år med att implementera dem. Detta har ändrats till ett agilt tillvägagångssätt där det finns en kontinuerlig cykel av att ta fram, föreställa sig, genomföra och verifiera. I denna modell är genomförandet inte (vanligtvis) flaskhalsen
En timme som sparas vid den icke-bottleneck är en hägring. (Eliyahu Goldratt)
Så vad ska man göra i stället? Jo, fokusera på att bli mer värdefull för ditt företag. Kan du:
- Identifiera värdefulla problem för din verksamhet?
- Utforma en lösning som människor kan använda?
- Samla in feedback för att bedöma om den är värdefull?
- Skriva mjukvara som gör en verklig skillnad för verkliga människor?
- Fokusera på de verkliga problemen snarare än de intressanta?
- Förbättra medlemmarna i teamet så att de blir fantastiska?
Och det finns en miljon och en sak som är värdefullare än att skriva perfekt kod på rekordtid (se t-formad!).
Det här betyder inte att kodning inte är viktigt. Kodning är viktigt! Kod läses fyra gånger mer än vad den skrivs, så om du skriver kod som är lätt att resonera kring så lönar det sig dramatiskt i framtiden (kanske finns det en 10x-historia där någonstans, men det lämnar jag till en annan dag). Att investera tid i sitt hantverk (oavsett om det är kodning, design eller projektledning) är ett måste, men kom ihåg att ditt hantverk inte existerar isolerat och att det existerar för att tjäna ett högre mål.
Fokusera inte bara på att vara världens bästa utvecklare, fokusera på helheten (kom ihåg Product over Project!). Lär dig en bred uppsättning färdigheter (särskilt de som är relaterade till människor) och du kommer att bli mycket mer värdefull och mycket närmare en sann 10x ”utvecklare”.