Per tutto il tempo che sono stato nel software, si è parlato dello sviluppatore 10x. Queste sono le persone che volete per risolvere i vostri problemi; lo faranno in 1/10 del tempo, con 1/10 del numero di linee di codice. Sembrano fantastici.
Ma da dove viene il termine? Esistono? E anche se esistessero, vorresti essere uno di loro?
Tom DeMarco e Tim Lister hanno condotto, dal 1977, i “Coding War Games”. Si tratta di un’indagine pubblica sulla produttività in cui squadre di implementatori di software di diverse organizzazioni competono per completare una serie di benchmark in un tempo minimo con difetti minimi. Hanno fatto partecipare più di 600 sviluppatori.
Cosa hanno imparato?
- La scelta del linguaggio di programmazione ha avuto poco impatto – che fosse COBOL/Fortran o un linguaggio di alto livello come Pascal la diffusione dei risultati è circa la stessa. L’unica eccezione era il linguaggio assembly.
- Non c’era alcuna correlazione tra esperienza e performance, tranne che quelli con meno di sei mesi di esperienza con un linguaggio non hanno fatto bene come gli altri.
- Gli sviluppatori di soluzioni a zero difetti non hanno pagato alcuna penalità di performance per fare un lavoro più preciso (in effetti, hanno impiegato un po’ meno tempo!).
Hanno trovato che c’erano enormi differenze tra le organizzazioni. La migliore organizzazione ha lavorato 11,1 volte più velocemente della peggiore. Inoltre, quelli che lavoravano più velocemente sviluppavano codice che passava il test di accettazione. Caso chiuso?
Beh, non proprio. Lo studio continua poi a correlare l’ambiente di lavoro (che è diverso in ogni organizzazione) alle prestazioni. Si scopre che il gruppo con uno spazio di lavoro tranquillo, privato e dedicato ha ottenuto risultati significativamente migliori.
La lezione è stata imparata: ottieni il giusto ambiente di lavoro prima di iniziare a preoccuparti se puoi trovare sviluppatori 10x o meno!
Il programmatore produttore netto negativo
Schulmeyer osserva che alcuni sviluppatori sono “programmatori produttori netti negativi” (NNPP), cioè producono così tanti difetti che rimuoverli dal team aumenta la produttività. Questo è quasi l’opposto dello sviluppatore 10x – è possibile avere qualcuno nel team che lo peggiora.
Se esistono produttori negativi (- Nx sviluppatori?) allora è chiaramente possibile avere uno sviluppatore 10x (matematica a parte).
Non è il miglior argomento per il programmatore 10x però, vero? Se chiedessi a un bambino della scuola di unirsi a un team, sarebbe un produttore netto negativo? Probabilmente sì, se li lascio seduti in un angolo a scrivere del codice (e se in qualche modo riescono a spingere alla produzione!). Se siete il tipo di azienda che lascia le persone sedute in un angolo, non dà feedback e le lascia spingere alla produzione, allora penso che probabilmente meritate di avere dei NNPP nel vostro team!
Più realisticamente, spero che in qualsiasi azienda normale, se assumi qualcuno, gli darai tutto il supporto di cui ha bisogno per essere fantastico nel suo ruolo (revisione del codice tra pari, feedback, un mentore, analisi automatica del codice per il feedback, materiali di apprendimento ecc. Questa certamente non sembra essere la storia migliore per l’esistenza di sviluppatori 10x.
Studi sperimentali esplorativi che confrontano le prestazioni di programmazione online e offline
Sackman, Erikson, Grant hanno pubblicato un documento nel 1968 chiamato “Studi sperimentali esplorativi che confrontano le prestazioni di programmazione online e offline”. Una delle citazioni alla fine riguarda le differenze individuali e gli studi “hanno rivelato grandi differenze individuali tra alte e basse prestazioni, spesso di un ordine di grandezza”. Potrebbe essere questo il magico documento che descrive quella differenza di 10 volte?
È utile leggere l’intero studio e mettere un po’ di contesto intorno a questo. In primo luogo, questi test confrontavano sia le prestazioni su carta e penna che quelle online usando un IBM AN/FSQ-32. I programmatori scrivevano il loro codice (sia su carta/penna per darlo a un operatore, o direttamente nel computer) usando un linguaggio chiamato JTS (un derivato di ALGOL).
Hanno avuto due compiti da risolvere, il primo era interpretare equazioni algebriche con una singola variabile dipendente. Fu dato loro il documento di Samelson e Bauer per aiutarli a implementare la soluzione. Un’immagine del documento è mostrata qui sotto:
Il secondo compito era di risolvere un labirinto 20×20 che ha esattamente un percorso. Il labirinto era descritto da una tabella di ricerca di 400 elementi dove ogni voce conteneva informazioni sulle uscite di ogni cella. Nessun materiale di supporto è stato fornito per questa sfida. La soluzione del labirinto è un problema affascinante e immagino che coloro che hanno completato un corso di teoria dei grafi di recente hanno avuto un grande vantaggio!
Conoscendo questi compiti, non sono sorpreso che ci siano grandi differenze individuali. Nel 1968, l’ingegneria del software era appena nata come disciplina. I compiti sono di natura matematica e non è chiaro quale fosse il background dei partecipanti. Sicuramente favorirebbe coloro che hanno seguito corsi di matematica di livello superiore.
Penso che la persona 10x che trovereste da questo sia dotata per risolvere questi problemi. Posso credere che nello spazio problematico di “risolvere un labirinto + equazioni lineari” ci possa essere uno sviluppatore 10x, ma è difficile che questo si trasferisca a qualsiasi altro dominio.
Dovrei essere uno sviluppatore 10x?
Probabilmente. Ma probabilmente 10 volte meglio a scrivere codice.
C’è una discussione molto migliore delle metodologie di ricerca dietro il mito dello sviluppatore 10x in questo eccellente libro. Anche se esiste uno sviluppatore 10x, probabilmente non dovreste aspirare ad esserlo; anche se riuscite ad implementare perfettamente il codice la prima volta, probabilmente scoprirete che stavate risolvendo il problema sbagliato in primo luogo.
Anche se questi studi fossero veri, l’ingegneria del software è andata avanti (almeno nel mio campo dello sviluppo dei prodotti).
In passato, potremmo fare una sola grande release all’anno, avere dei requisiti e passare l’anno ad implementarli. Questo è cambiato in un approccio agile dove c’è un ciclo continuo di elicitazione, immaginazione, implementazione e verifica. In questo modello, l’implementazione non è (di solito) il collo di bottiglia
Un’ora risparmiata al non collo di bottiglia è un miraggio. (Eliyahu Goldratt)
Quindi cosa dovresti fare invece? Beh, concentrati sull’essere più prezioso per il tuo business. Puoi:
- Identificare i problemi di valore per il tuo business?
- Progettare una soluzione che le persone possano usare?
- Raccogliere feedback per valutare se è di valore?
- Scrivere un software che faccia davvero la differenza per persone reali?
- Focalizzarsi sui problemi reali piuttosto che su quelli interessanti?
- Crescere i membri del team per essere fantastici?
E un milione e uno di cose che sono più importanti che scrivere codice perfetto in tempo record (vedi t-shaped!).
Questo non vuol dire che codificare non sia importante. La codifica è importante! Il codice viene letto 4 volte di più di quanto sia scritto, quindi se scrivete codice facile da ragionare, questo vi ripaga drammaticamente in futuro (forse c’è una storia del 10x da qualche parte, ma la lascio per un altro giorno). Investire tempo nel tuo mestiere (che sia la codifica o il design o la gestione del progetto) è un dovere, ma ricorda che il tuo mestiere non esiste in modo isolato ed esiste per servire un obiettivo più alto.
Non concentrarti solo sull’essere il miglior sviluppatore del mondo, concentrati sul quadro generale (ricorda il Prodotto sul Progetto!). Imparate un ampio insieme di competenze (specialmente quelle relative alle persone) e sarete molto più preziosi e molto più vicini a un vero “sviluppatore” 10x.
.