Mióta a szoftveriparban dolgozom, beszélnek a 10x fejlesztőről. Ezek azok az emberek, akiket a problémáid megoldására akarsz; ők 1/10-ed idő alatt, 1/10-ed számú kódsorral fogják megoldani. Fantasztikusan hangzik.
De honnan származik ez a kifejezés? Léteznek ilyenek? És még ha léteznek is, akkor is szeretnél az lenni?
Tom DeMarco és Tim Lister 1977 óta vezeti a “Coding War Games”-t. Ez egy nyilvános termelékenységi felmérés, amelyben különböző szervezetek szoftver implementátoraiból álló csapatok versenyeznek egymással, hogy minimális idő alatt, minimális hibával teljesítsenek egy sor referenciaértéket. Több mint 600 fejlesztő vett részt a felmérésben.
Mit tudtak meg?
- A programozási nyelv kiválasztása kevéssé befolyásolta az eredményeket – akár COBOL/Fortran, akár egy magas szintű nyelv, mint a Pascal, az eredmények szórása nagyjából ugyanaz. Az egyetlen kivétel az assembly nyelv volt.
- A tapasztalat és a teljesítmény között nem volt összefüggés, kivéve, hogy azok, akik kevesebb mint hat hónapos tapasztalattal rendelkeztek egy nyelvvel, nem teljesítettek olyan jól, mint a többiek.
- A hibátlan megoldások fejlesztői nem fizettek teljesítménybüntetést a precízebb munka elvégzéséért (sőt, valamivel kevesebb időbe telt!).
A szervezetek között viszont hatalmas különbségeket találtak. A legjobb szervezet 11,1-szer gyorsabban dolgozott, mint a legrosszabb. Ráadásul azok, akik a leggyorsabban dolgoztak, olyan kódot fejlesztettek, amely átment az átvételi teszten. Az ügy lezárva?
Nos, nem egészen. A tanulmány ezután összefüggésbe hozza a munkahelyi környezetet (amely szervezetenként eltérő) a teljesítménnyel. Kiderült, hogy a csendes, privát, dedikált munkaterületű csoport jelentősen jobban teljesített.
A tanulság: először a munkakörnyezetet alakítsuk ki, mielőtt azon kezdünk aggódni, hogy találunk-e 10x fejlesztőket vagy sem!
A nettó negatívan termelő programozó
Schulmeyer megfigyeli, hogy egyes fejlesztők “nettó negatívan termelő programozók” (NNPP), azaz olyan sok hibát termelnek, hogy a csapatból való eltávolításuk növeli a termelékenységet. Ez majdnem az ellentéte a 10x fejlesztőnek – lehetséges, hogy van valaki a csapatban, aki rontja azt.”
Ha léteznek negatív termelők (- Nx fejlesztők?), akkor nyilvánvalóan lehetséges, hogy van 10x fejlesztő (a matematikát félretéve).
Ez azonban nem a legjobb érv a 10x programozó mellett, ugye? Ha megkérnék egy iskolás gyereket, hogy csatlakozzon egy csapathoz, akkor nettó negatív termelő lenne? Valószínűleg, ha hagynám őket a sarokban ülni és kódot püfölni (és ha valamilyen módon képesek lennének a termelésbe tolni!). Ha olyan cég vagy, amelyik hagyja, hogy az emberek a sarokban üljenek, nem ad visszajelzést, és hagyja, hogy a gyártásig nyomják, akkor szerintem valószínűleg megérdemled, hogy NNPP-k legyenek a csapatodban!
Reálisabban remélem, hogy minden normális cégnél, ha valakit alkalmazol, minden támogatást megadsz neki, amire szüksége van ahhoz, hogy fantasztikus legyen a szerepében (peer code-review, visszajelzés, mentor, automatikus kódelemzés a visszajelzéshez, tananyagok stb.)
Azt hiszem, még mindig lehetséges, hogy egy NNPP-vel végzed, de gyanítom, hogy ez nagyon valószínűtlen. Ez biztosan nem tűnik a legjobb történetnek a 10x fejlesztők létezésére.
Exploratory experimental studies comparing online and offline programming performance
Sackman, Erikson, Grant 1968-ban publikált egy tanulmányt “Exploratory experimental studies comparing online and offline programming performance” címmel. Az egyik idézet a végén az egyéni különbségekről szól, és a vizsgálatok “nagy egyéni különbségeket mutattak ki a magas és alacsony teljesítmény között, gyakran nagyságrendekkel”. Lehet, hogy ez az a varázslatos tanulmány, amely leírja ezt a 10x-es különbséget?
Megéri elolvasni a teljes tanulmányt, és némi kontextusba helyezni a dolgot. Először is, ezek a tesztek összehasonlították mind a tollal és papíron, mind az online teljesítményt egy IBM AN/FSQ-32 segítségével. A programozók egy JTS nevű nyelv (egy ALGOL-származék) segítségével írták a kódot (vagy tollra/papírra, hogy odaadják egy operátornak, vagy közvetlenül a számítógépbe).
Két feladatot kellett megoldaniuk, az első az algebrai egyenletek értelmezése volt egyetlen függő változóval. A megoldás megvalósításához Samelson és Bauer dolgozatát kapták segítségül. Egy kép a dolgozatból az alábbiakban látható:
A második feladat egy 20×20-as labirintus megoldása volt, amelynek pontosan egy útvonala van. Az útvesztőt egy 400 elemű keresőtáblával írták le, ahol minden egyes bejegyzés tartalmazta az egyes cellák kijáratainak információit. Ehhez a feladathoz nem állt rendelkezésre segédanyag. A labirintus megoldása lenyűgöző problématér, és azt hiszem, hogy azok, akik nemrégiben elvégeztek egy gráfelmélet kurzust, nagy előnyben voltak!!!
Az ilyen feladatok ismeretében nem vagyok meglepve, hogy nagy egyéni különbségek vannak. A szoftverfejlesztés 1968-ban még csak most született meg mint tudományág. A feladatok matematikai jellegűek, és nem világos, hogy a résztvevők milyen háttérrel rendelkeztek. Minden bizonnyal azoknak kedvezne, akik magasabb szintű matematika kurzusokat végeztek.
Azt hiszem, hogy a 10x olyan személyt találna ebből, aki tehetséges ezeknek a feladatoknak a megoldásában. El tudom hinni, hogy a “labirintus + lineáris egyenletek megoldása” problématérben lehet egy 10x fejlesztő, de nehéz elhinni, hogy ez bármely más területre átvihető lenne.
Kellene 10x fejlesztőnek lenni?
Valószínűleg. De valószínűleg 10x jobb kódot írni.
Ez a kiváló könyv sokkal jobban tárgyalja a 10x fejlesztő mítosz mögött álló kutatási módszertant. Még ha létezik is 10x-es fejlesztő, valószínűleg nem kellene arra törekedned, hogy az legyél; még ha elsőre tökéletesen tudsz is kódot implementálni, valószínűleg rájössz, hogy eleve rossz problémát oldottál meg.
Még ha igazak is lennének ezek a tanulmányok, a szoftverfejlesztés továbblépett (legalábbis az én területemen, a termékfejlesztésben).
A régi időkben talán évente egyetlen nagy kiadást csináltunk, volt néhány követelmény, és az egész évet a megvalósításukkal töltöttük. Ez mára egy agilis megközelítésre változott, ahol folyamatos ciklusban történik a kiváltás, az elképzelés, a megvalósítás és az ellenőrzés. Ebben a modellben a megvalósítás (általában) nem a szűk keresztmetszet
A nem szűk keresztmetszetnél megtakarított egy óra csak káprázat. (Eliyahu Goldratt)
Mit kellene tehát tennie helyette? Nos, összpontosítson arra, hogy értékesebbé váljon a vállalkozása számára. Tudsz:
- Identifikálni a vállalkozásod számára értékes problémákat?
- Tervezz olyan megoldást, amelyet az emberek használni tudnak?
- Gyűjts visszajelzést, hogy felmérd, értékes-e?
- Írj olyan szoftvert, amely valódi különbséget jelent valódi emberek számára?
- Fókuszálj a valódi problémákra az érdekesek helyett?
- Növeld a csapat tagjait, hogy fantasztikusak legyenek?
És még millió és egy dolog, ami értékesebb, mint tökéletes kódot írni rekordidő alatt (lásd t-alakú!).
Ez nem azt jelenti, hogy a kódolás nem fontos. A kódolás fontos! A kódot 4x annyiszor olvassák, mint ahányszor megírják, tehát ha könnyen érthető kódot írsz, akkor az drámaian megtérül a jövőben (talán van valahol egy 10x-es történet is, de ezt egy másik napra hagyom). A szakmádba (legyen az kódolás, tervezés vagy projektmenedzsment) időt kell fektetned, de ne feledd, hogy a szakmád nem elszigetelten létezik, hanem azért, hogy egy magasabb célt szolgáljon.
Ne csak arra koncentrálj, hogy a világ legjobb fejlesztője legyél, koncentrálj a nagyobb képre (ne feledd: Product over Project!). Tanuld meg a készségek széles skáláját (különösen az emberekkel kapcsolatosakat), és sokkal értékesebb leszel, és sokkal közelebb kerülsz egy igazi 10x “fejlesztőhöz”.