De când lucrez în domeniul software, s-a vorbit despre dezvoltatorul 10x. Aceștia sunt oamenii pe care îi doriți să vă rezolve problemele; ei o vor face în 1/10 din timp, cu 1/10 din numărul de linii de cod. Sună grozav.
Dar de unde a apărut acest termen? Există ele? Și chiar dacă există, ați vrea totuși să fiți unul?
Tom DeMarco și Tim Lister au condus, încă din 1977, „Coding War Games”. Acesta este un studiu public de productivitate în care echipe de implementatori de software din diferite organizații concurează pentru a finaliza o serie de repere într-un timp minim și cu defecte minime. Au participat peste 600 de programatori.
Ce au învățat?
- alegerea limbajului de programare a avut un impact redus – fie că a fost vorba de COBOL/Fortran sau de un limbaj de nivel înalt precum Pascal, răspândirea rezultatelor este aproximativ aceeași. Singura excepție a fost limbajul de asamblare.
- Nu a existat nicio corelație între experiență și performanță, cu excepția faptului că cei cu mai puțin de șase luni de experiență cu un limbaj nu s-au descurcat la fel de bine ca ceilalți.
- Dezvoltatorii soluțiilor cu zero defecte nu au plătit nicio penalizare de performanță pentru că au făcut o muncă mai precisă (de fapt, au avut nevoie de ceva mai puțin timp!).
Au constatat că existau diferențe uriașe între organizații. Cea mai bună organizație a lucrat de 11,1 ori mai repede decât cea mai slabă. În plus, cei care au lucrat cel mai repede au dezvoltat cod care a trecut testul de acceptare. Caz închis?
Bine, nu chiar. Studiul continuă apoi să coreleze mediul de lucru (care este diferit de la o organizație la alta) cu performanța. Se pare că acel grup liniștit, privat, cu spațiu de lucru dedicat a avut performanțe semnificativ mai bune.
Lecția învățată – obțineți-vă mai întâi mediul de lucru corect înainte de a începe să vă faceți griji dacă puteți găsi sau nu dezvoltatori 10x!
Programatorul cu productivitate netă negativă
Schulmeyer observă că unii programatori sunt „programatori cu productivitate netă negativă” (NNPP), adică produc atât de multe defecte încât eliminarea lor din echipă crește productivitatea. Acest lucru este aproape opusul dezvoltatorului 10x – este posibil să ai pe cineva în echipă care o înrăutățește.
Dacă există producători negativi (- Nx programatori?) atunci este clar că este posibil să existe un programator 10x (lăsând matematica la o parte).
Nu este totuși cel mai bun argument pentru programatorul 10x, nu-i așa? Dacă i-aș cere unui copil de școală să se alăture unei echipe, ar fi el un producător net-negativ? Probabil, dacă îi las să stea într-un colț și să bată niște cod (și dacă cumva reușesc să împingă la producție!). Dacă sunteți genul de companie care îi lasă pe oameni să stea într-un colț, nu le oferă feedback și îi lasă să treacă la producție, atunci cred că, probabil, meritați să aveți PNNPP în echipă!
Mai realist, sper că în orice companie normală, dacă angajezi pe cineva, îi vei oferi tot sprijinul de care are nevoie pentru a fi grozav în rolul său (peer code-review, feedback, un mentor, analiză automată a codului pentru feedback, materiale de învățare etc.)
Cred că este încă posibil să ajungi să ai un NNPP, dar bănuiesc că este foarte puțin probabil. Aceasta cu siguranță nu pare a fi cea mai bună poveste pentru existența dezvoltatorilor 10x.
Studii experimentale exploratorii care compară performanțele de programare online și offline
Sackman, Erikson, Grant au publicat o lucrare în 1968 intitulată „Exploratory experimental studies comparing online and offline programming performance”. Unul dintre citatele de la sfârșitul lucrării se referă la diferențele individuale, iar studiile „au evidențiat diferențe individuale mari între performanțele ridicate și cele scăzute, adesea cu un ordin de mărime”. Ar putea fi aceasta lucrarea magică care descrie acea diferență de 10x?
Merită să citiți întregul studiu și să puneți în context acest lucru. În primul rând, aceste teste au comparat atât performanța cu pixul și hârtia, cât și cea online, folosind un IBM AN/FSQ-32. Programatorii și-au scris codul (fie pe creion/hârtie pentru a-l da unui operator, fie direct în calculator) folosind un limbaj numit JTS (un derivat ALGOL).
Au avut de rezolvat două sarcini, prima a fost să interpreteze ecuații algebrice cu o singură variabilă dependentă. Li s-a dat lucrarea lui Samelson și Bauer pentru a-i ajuta să implementeze soluția. O imagine din lucrare este prezentată mai jos:
Cea de-a doua sarcină a fost să rezolve un labirint de 20×20 care are exact o singură cale. Labirintul a fost descris de un tabel de căutare cu 400 de elemente în care fiecare intrare conținea informații despre ieșirile din fiecare celulă. Pentru această probă nu a fost furnizat niciun material justificativ. Rezolvarea labirintului este un spațiu problematic fascinant și bănuiesc că cei care au absolvit recent un curs de teoria grafurilor au avut un mare avantaj!
Cunoscând aceste sarcini, nu sunt surprins că există diferențe individuale mari. În 1968, ingineria software abia se născuse ca disciplină. Sarcinile sunt de natură matematică și nu este clar care a fost pregătirea participanților. Cu siguranță i-ar favoriza pe cei care au urmat cursuri de matematică de nivel superior.
Cred că persoana de 10x pe care o veți găsi de aici este înzestrată să rezolve aceste probleme. Pot să cred că în spațiul de probleme „rezolvarea unui labirint + ecuații liniare” poate exista un dezvoltator de 10x, dar este dificil ca acest lucru să se transfere în orice alt domeniu.
Ar trebui să fiu un dezvoltator de 10x?
Probabil. Dar probabil de 10 ori mai bun la scrierea de cod.
Există o discuție mult mai bună despre metodologiile de cercetare din spatele mitului dezvoltatorului 10x în această carte excelentă. Chiar dacă există un dezvoltator 10x, probabil că nu ar trebui să aspirați să fiți unul; chiar dacă puteți implementa codul perfect de prima dată, probabil că veți descoperi că ați rezolvat problema greșită de la bun început.
Chiar dacă aceste studii ar fi adevărate, ingineria software a evoluat (cel puțin în domeniul meu de dezvoltare a produselor).
În vremurile vechi, puteam face o singură versiune mare pe an, aveam niște cerințe și ne petreceam anul implementându-le. Acest lucru s-a schimbat în favoarea unei abordări agile, în care există un ciclu continuu de elicitare, imaginare, implementare și verificare. În acest model, implementarea nu este (de obicei) gâtul de îmbulzeală
O oră economisită la cel care nu este gâtul de îmbulzeală este un miraj. (Eliyahu Goldratt)
Atunci ce ar trebui să faceți în schimb? Ei bine, concentrați-vă pe a fi mai valoroși pentru afacerea dumneavoastră. Puteți:
- Identifica probleme valoroase pentru afacerea dumneavoastră?
- Proiecta o soluție pe care oamenii o pot folosi?
- Colecta feedback pentru a evalua dacă este valoroasă?
- Scrieți un software care face o diferență reală pentru oameni reali?
- Concentrați-vă pe problemele reale mai degrabă decât pe cele interesante?
- Creșteți membrii echipei pentru a fi grozavi?
Și un milion și unu de lucruri care sunt mai valoroase decât scrierea unui cod perfect în timp record (vezi forma de T!).
Aceasta nu înseamnă că programarea nu este importantă. Codificarea este importantă! Codul este citit de 4 ori mai mult decât este scris, așa că dacă scrii cod ușor de raționalizat, atunci se amortizează dramatic în viitor (poate că există o poveste de 10x pe undeva pe acolo, dar o voi lăsa pentru o altă zi). Să investești timp în meseria ta (fie că este vorba de codare, design sau management de proiect) este o necesitate, dar amintește-ți că meseria ta nu există în mod izolat și că există pentru a servi un scop mai înalt.
Nu te concentra doar pe a fi cel mai bun dezvoltator din lume, ci concentrează-te pe imaginea de ansamblu (amintește-ți Product over Project!). Învățați un set larg de abilități (în special cele legate de oameni) și veți fi mult mai valoros și mult mai aproape de un adevărat „dezvoltator” de 10x.
.