Po celou dobu, co se pohybuji v oblasti softwaru, se mluví o 10x vývojáři. To jsou lidé, po kterých chcete, aby řešili vaše problémy; zvládnou to za 1/10 času a s 1/10 počtu řádků kódu. Zní to úžasně.
Ale odkud se tento termín vzal? Existují vůbec? A i kdyby ano, chtěli byste se jím stát?
Tom DeMarco a Tim Lister od roku 1977 pořádají „Coding War Games“. Jedná se o veřejný průzkum produktivity, v němž týmy implementátorů softwaru z různých organizací soutěží o dokončení série benchmarků v minimálním čase s minimem chyb. Zúčastnilo se jich přes 600 vývojářů.
Co zjistili?
- Výběr programovacího jazyka měl jen malý vliv – ať už to byl COBOL/Fortran nebo vysokoúrovňový jazyk jako Pascal, rozptyl výsledků je přibližně stejný. Jedinou výjimkou byl jazyk assembler.
- Nebyla zjištěna žádná souvislost mezi zkušenostmi a výkonem, kromě toho, že ti, kteří měli s jazykem méně než šest měsíců zkušeností, si nevedli tak dobře jako ostatní.
- Vývojáři řešení s nulovou chybovostí neplatili žádnou výkonnostní pokutu za preciznější práci (ve skutečnosti jim to trvalo o něco méně času!).
Zjistili však, že mezi organizacemi byly obrovské rozdíly. Nejlepší organizace pracovala 11,1krát rychleji než nejhorší. Navíc ti, kteří pracovali nejrychleji, vyvinuli kód, který prošel akceptačním testem. Případ uzavřen?
No, ne tak docela. Studie pak pokračuje korelací pracovního prostředí (které se v různých organizacích liší) s výkonností. Ukázalo se, že klidná, soukromá skupina s vyhrazeným pracovním prostorem dosahovala výrazně lepších výsledků.
Poučení – nejprve si zajistěte správné pracovní prostředí, než se začnete starat o to, zda najdete 10x více vývojářů!
Čistě záporně produkující programátor
Schulmeyer poznamenává, že někteří vývojáři jsou „čistě záporně produkující programátoři“ (NNPP), tj. produkují tolik chyb, že jejich odstranění z týmu zvyšuje produktivitu. To je téměř opak 10x vývojáře – je možné mít v týmu někoho, kdo ho zhoršuje.
Pokud existují negativní producenti (- Nx vývojáři?), pak je zjevně možné mít 10x vývojáře (matematiku stranou).
Není to však zrovna nejlepší argument pro 10x programátora, že? Kdybych požádal školáka, aby se připojil k týmu, byl by čistým záporným producentem? Pravděpodobně ano, pokud bych je nechal sedět v koutě a mlátit do kódu (a pokud by se nějakým způsobem dokázalo prosadit do produkce!). Pokud jste typ společnosti, která nechává lidi sedět v koutě, nedává jim zpětnou vazbu a nechá je tlačit do produkce, pak si myslím, že si pravděpodobně zasloužíte mít ve svém týmu NNPP!
Reálněji řečeno, doufám, že v každé normální firmě, pokud někoho zaměstnáte, mu poskytnete veškerou podporu, kterou potřebuje, aby byl ve své roli úžasný (vzájemné hodnocení kódu, zpětná vazba, mentor, automatická analýza kódu pro zpětnou vazbu, výukové materiály atd.)
Hádám, že je stále možné, že byste mohli skončit s NNPP, ale mám podezření, že je to velmi nepravděpodobné. Rozhodně to nevypadá jako nejlepší příběh pro existenci 10x vývojářů.
Exploratory experimental studies comparing online and offline programming performance
Sackman, Erikson, Grant publikovali v roce 1968 článek s názvem „Exploratory experimental studies comparing online and offline programming performance“. Jeden z citátů na konci se týká individuálních rozdílů a studie „odhalily velké individuální rozdíly mezi vysokým a nízkým výkonem, často řádově“. Mohl by to být ten kouzelný článek, který popisuje onen desetinásobný rozdíl?“
Vyplatí se přečíst si celou studii a dát si to do souvislostí. Zaprvé, tyto testy porovnávaly jak výkonnost pera a papíru, tak i online pomocí IBM AN/FSQ-32. Na základě těchto testů se dá říci, že se jedná o výkonnostní testy. Programátoři psali svůj kód (buď na tužku/papír, který předávali operátorovi, nebo přímo do počítače) pomocí jazyka JTS (derivát jazyka ALGOL).
Měli za úkol vyřešit dvě úlohy, první z nich byla interpretace algebraických rovnic s jednou závislou proměnnou. Na pomoc při realizaci řešení dostali práci Samelsona a Bauera. Obrázek z článku je uveden níže:
Druhou úlohou bylo vyřešit bludiště 20×20, které má přesně jednu cestu. Bludiště bylo popsáno 400prvkovou vyhledávací tabulkou, kde každá položka obsahovala informaci o východech z každé buňky. K této úloze nebyl poskytnut žádný podpůrný materiál. Řešení bludiště je fascinující problémový prostor a hádal bych, že ti, kteří v nedávné době absolvovali kurz teorie grafů, měli velkou výhodu!“
Znalost těchto úloh mě nepřekvapuje, že existují velké individuální rozdíly. V roce 1968 se softwarové inženýrství jako obor teprve rodilo. Úlohy jsou matematické povahy a není jasné, jaké bylo vzdělání účastníků. Určitě by to zvýhodňovalo ty, kteří absolvovali kurzy matematiky na vyšší úrovni.
Myslím, že 10x by se z toho našel člověk nadaný na řešení těchto úloh. Dokážu uvěřit, že v problémovém prostoru „řešení bludiště + lineárních rovnic“ může být 10x vývojář, ale těžko by se to přeneslo do nějaké jiné oblasti.
Měl bych být 10x vývojář?
Pravděpodobně. Ale pravděpodobně 10x lepší v psaní kódu.
Daleko lépe se o metodikách výzkumu, které stojí za mýtem 10x vývojáře, píše v této vynikající knize. I kdyby 10x vývojář existoval, pravděpodobně byste neměli usilovat o to, abyste jím byli; i když dokážete implementovat kód dokonale napoprvé, pravděpodobně zjistíte, že jste v první řadě řešili špatný problém.
I kdyby byly tyto studie pravdivé, softwarové inženýrství se posunulo (alespoň v mé doméně vývoje produktů).
Dříve jsme mohli udělat jednu velkou verzi ročně, mít nějaké požadavky a strávit rok jejich implementací. To se změnilo na agilní přístup, kdy probíhá nepřetržitý cyklus získávání, představování, implementace a ověřování. V tomto modelu není implementace (obvykle) úzkým hrdlem
Ušetřená hodina u neúzkého hrdla je přelud. (Eliyahu Goldratt)
Co byste tedy měli dělat místo toho? Inu, zaměřte se na to, abyste byli pro svou firmu hodnotnější. Dokážete:
- Identifikovat cenné problémy pro váš podnik?
- Navrhnout řešení, které mohou lidé používat?
- Sbírat zpětnou vazbu a vyhodnocovat, zda je hodnotné?
- Napsat software, který má skutečný význam pro skutečné lidi?
- Soustředit se spíše na skutečné problémy než na zajímavosti?
- Vychovávat členy týmu tak, aby byli úžasní?
A milion a jedna věc, které jsou cennější než napsat dokonalý kód v rekordním čase (viz t-tvar!).
Tím nechci říct, že kódování není důležité. Kódování je důležité! Kód se čte 4x častěji, než se píše, takže pokud napíšete kód, který se dá snadno zdůvodnit, pak se to v budoucnu dramaticky vyplatí (možná je tam někde příběh 10x, ale to si nechám na jindy). Investovat čas do svého řemesla (ať už jde o kódování, design nebo projektové řízení) je nutnost, ale nezapomeňte, že vaše řemeslo neexistuje izolovaně a existuje proto, aby sloužilo vyššímu cíli.
Nesoustřeďte se jen na to, abyste byli nejlepším vývojářem na světě, soustřeďte se na širší souvislosti (pamatujte na Product over Project!). Naučte se širokou sadu dovedností (zejména těch, které souvisejí s lidmi) a budete mnohem cennější a mnohem blíže skutečnému 10x „vývojáři“.