Så længe jeg har været inden for software, har der været snak om den 10x udvikleren. Det er de mennesker, du vil have til at løse dine problemer; de vil gøre det på 1/10 af tiden, med 1/10 af antallet af kodelinjer. De lyder fantastiske.
Men hvor kommer udtrykket fra? Findes de? Og selv hvis de findes, ville du så alligevel have lyst til at være en af dem?
Tom DeMarco og Tim Lister har siden 1977 gennemført “Coding War Games”. Det er en offentlig produktivitetsundersøgelse, hvor hold af softwareimplementatorer fra forskellige organisationer konkurrerer om at gennemføre en række benchmarks på minimal tid og med minimale fejl. De har haft over 600 udviklere til at deltage.
Hvad lærte de?
- Valg af programmeringssprog havde kun ringe indflydelse – uanset om det var COBOL/Fortran eller et højniveausprog som Pascal, er spredningen af resultaterne omtrent den samme. Den eneste undtagelse var assemblagesprog.
- Der var ingen sammenhæng mellem erfaring og præstation, bortset fra at de, der havde mindre end seks måneders erfaring med et sprog, ikke klarede sig lige så godt som de andre.
- De udviklere af nul-fejl-løsninger betalte ingen straf for præstation for at udføre mere præcist arbejde (faktisk tog de lidt mindre tid!).
De fandt dog, at der var store forskelle mellem organisationerne. Den bedste organisation arbejdede 11,1 gange hurtigere end den dårligste. Desuden udviklede de, der arbejdede hurtigst, kode, der bestod accepttesten. Sagen er afsluttet?
Nu, ikke helt. Undersøgelsen fortsætter derefter med at korrelere arbejdsmiljøet (som er forskelligt fra organisation til organisation) med præstationen. Det viser sig, at gruppen med stille, private, dedikerede arbejdsrum præsterede betydeligt bedre.
Lærdommens lektie – få først styr på arbejdsmiljøet, før du begynder at bekymre dig om, hvorvidt du kan finde 10x udviklere eller ej!
The Net Negative Producing Programmer
Schulmeyer observerer, at nogle udviklere er “netto negativt producerende programmører” (NNPP), dvs. de producerer så mange fejl, at det øger produktiviteten at fjerne dem fra teamet. Dette er næsten det modsatte af 10x-udvikleren – det er muligt at have nogen på holdet, der gør det dårligere.
Hvis der findes negative producenter (- Nx udviklere?), så er det klart muligt at have en 10x udvikler (matematik til side).
Det er dog ikke det bedste argument for den 10x programmør, er det? Hvis jeg bad et skolebarn om at deltage i et hold, ville de så være en netto-negativ producent? Sandsynligvis, hvis jeg lader dem sidde i et hjørne og bashe i noget kode (og hvis de på en eller anden måde kan skubbe til produktion!). Hvis du er den slags virksomhed, der lader folk sidde i et hjørne, ikke giver feedback og lader dem gå i produktion, så synes jeg, at du nok fortjener at have NNPP’er på dit hold!
Mere realistisk set håber jeg, at i enhver normal virksomhed, hvis du ansætter nogen, så håber jeg, at du vil give dem al den støtte, de har brug for for at være fantastiske i deres rolle (peer code-review, feedback, en mentor, automatiseret kodeanalyse til feedback, læringsmaterialer osv.)
Jeg tror stadig, at det er muligt, at du kan ende med en NNPP, men jeg mistænker det for at være meget usandsynligt. Dette synes i hvert fald ikke at være den bedste historie for eksistensen af 10x udviklere.
Exploratory experimental studies comparing online and offline programming performance
Sackman, Erikson, Grant udgav i 1968 en artikel med titlen “Exploratory experimental studies comparing online and offline programming performance”. Et af citaterne i slutningen handler om individuelle forskelle, og undersøgelserne “afslørede store individuelle forskelle mellem høj og lav præstation, ofte med en størrelsesorden”. Kunne dette være den magiske artikel, der beskriver den 10 gange større forskel?
Det kan betale sig at læse hele undersøgelsen og sætte noget kontekst omkring dette. For det første blev der i disse tests sammenlignet både pen og papir-ydelse og online ved hjælp af en IBM AN/FSQ-32. Programmørerne skrev deres kode (enten på pen/papir, som de gav til en operatør, eller direkte ind i computeren) ved hjælp af et sprog kaldet JTS (et ALGOL-derivat).
De havde to opgaver at løse, den første var at fortolke algebraiske ligninger med en enkelt afhængig variabel. De fik papiret af Samelson og Bauer som hjælp til at implementere løsningen. Et billede fra papiret er vist nedenfor:
Den anden opgave var at løse en 20×20 labyrint, som har præcis én vej. Labyrinten blev beskrevet ved hjælp af en opslagstabel med 400 elementer, hvor hver post indeholdt oplysninger om udgangene i hver celle. Der blev ikke leveret noget støttemateriale til denne opgave. Labyrintløsning er et fascinerende problemområde, og jeg vil gætte på, at de, der havde gennemført et kursus i grafteori for nylig, havde en stor fordel!
Med hensyn til disse opgaver er jeg ikke overrasket over, at der er store individuelle forskelle. I 1968 var software engineering kun lige blevet født som en disciplin. Opgaverne er af matematisk karakter, og det er ikke klart, hvad deltagernes baggrund var. Det ville helt sikkert favorisere dem, der har taget matematikkurser på højere niveau.
Jeg tror, at den 10x person, du ville finde ud af dette, er begavet til at løse disse problemer. Jeg kan godt tro, at der i problemrummet “løsning af en labyrint + lineære ligninger” kan findes en 10x-udvikler, men det er svært at overføre dette til et hvilket som helst andet domæne.
Skal jeg være en 10x-udvikler?
Sandsynligvis. Men sandsynligvis 10x bedre til at skrive kode.
Der er en meget bedre diskussion af forskningsmetoderne bag myten om 10x-udvikleren i denne fremragende bog. Selv hvis der findes en 10x-udvikler, bør du sandsynligvis ikke stræbe efter at blive en sådan; selv hvis du kan implementere kode perfekt første gang, vil du sandsynligvis opdage, at du løste det forkerte problem i første omgang.
Selv om disse undersøgelser var sande, har softwareudvikling udviklet sig (i det mindste inden for mit område for produktudvikling).
I gamle dage lavede vi måske en enkelt stor udgivelse om året, havde nogle krav og brugte året på at implementere dem. Dette har ændret sig til en agil tilgang, hvor der er en kontinuerlig cyklus med at udtrække, forestille sig, implementere og verificere. I denne model er implementeringen (normalt) ikke flaskehalsen
En time sparet ved den ikke-bottleneck er en luftspejling. (Eliyahu Goldratt)
Så hvad skal man gøre i stedet? Jo, du skal fokusere på at være mere værdifuld for din virksomhed. Kan du:
- Identificere værdifulde problemer for din virksomhed?
- Design en løsning, som folk kan bruge?
- Indhent feedback for at vurdere, om den er værdifuld?
- Skriv software, der gør en reel forskel for virkelige mennesker?
- Fokuser på de virkelige problemer frem for det interessante?
- Vækst medlemmer på holdet til at være fantastiske?
Og en million og en ting, der er mere værdifulde end at skrive perfekt kode på rekordtid (se t-formet!).
Det betyder ikke, at kodning ikke er vigtig. Kodning er vigtig! Kode bliver læst 4x mere end den bliver skrevet, så hvis du skriver let at ræsonnere om kode, så betaler det sig dramatisk i fremtiden (måske er der en 10x historie derinde et sted, men det lader jeg ligge til en anden dag). At investere tid i dit håndværk (det være sig kodning eller design eller projektledelse) er et must, men husk bare, at dit håndværk ikke eksisterer isoleret og eksisterer for at tjene et højere mål.
Fokuser ikke bare på at være den bedste udvikler i verden, fokuser på det større billede (husk Product over Project!). Lær et bredt sæt af færdigheder (især de menneskerelaterede), og du vil være meget mere værdifuld og meget tættere på en ægte 10x “udvikler”.