"Un buon programmatore può essere 10 volte più produttivo di uno mediocre" [chiuso]

Avevo letto un'intervista con un grande programmatore (non è in inglese) e in esso mi ha detto che "un grande programmatore può essere 10 volte più buono di uno mediocre", spiegando perché i bravi programmatori sono ben pagati e perché le società di programmazione offrono molti servizi ai propri dipendenti. L'idea era che c'è una grande richiesta di buoni programmatori, a causa della ragione sopra menzionata ed è per questo che le aziende pagano molto per portarli.

Sei d'accordo con questa affermazione? Conosci fatti oggettivi che potrebbero supportarlo?

Modifica: la domanda non ha nulla a che fare con l'esperienza; se parli di un grande programmatore con 1 anno di esperienza, allora dovrebbe essere 10 volte più produttivo di un programmatore mediocre con 1 anno di esperienza. Concordo sul fatto che da alcuni anni in poi, le cose iniziano a dissiparsi, ma non è questo lo scopo della domanda.

Una panoramica e un'analisi piuttosto approfondite della ricerca sulle differenze di produttività è fornita in due articoli scritti da Steve McConnell :

• Variazioni di produttività tra sviluppatori e team di software: l'origine di "10x"

• Origini di 10X: quanto è valida la ricerca sottostante?

Il primo articolo ( Variazioni di produttività ... ) afferma:

... Lo studio originale che ha riscontrato enormi variazioni nella produttività della programmazione individuale è stato condotto alla fine degli anni '60 da Sackman, Erikson e Grant (1968). Hanno studiato programmatori professionisti con una media di 7 anni di esperienza e hanno scoperto che il rapporto tra il tempo di codifica iniziale tra i programmatori migliori e peggiori era di circa 20 a 1; il rapporto tra i tempi di debug oltre 25 a 1; di dimensioni del programma da 5 a 1; e della velocità di esecuzione del programma da 10 a 1. Non hanno trovato alcuna relazione tra la quantità di esperienza di un programmatore e la qualità o la produttività del codice.

L'esame dettagliato delle scoperte di Sackman, Erickson e Grant mostra alcuni difetti nella loro metodologia ... Tuttavia, anche dopo aver tenuto conto dei difetti, i loro dati mostrano ancora una differenza di oltre 10 volte tra i migliori programmatori e il peggio.

Negli anni successivi allo studio originale, la constatazione generale che "ci sono differenze nell'ordine di grandezza tra i programmatori" è stata confermata da molti altri studi di programmatori professionisti (Curtis 1981, Mills 1983, DeMarco e Lister 1985, Curtis et al. 1986 , Card 1987, Boehm e Papaccio 1988, Valett e McGarry 1989, Boehm et al 2000) ...

^{Questo articolo ha anche una nota a margine interessante:}

^{Questo grado di variazione non è unico per il software. Uno studio di Norm Augustine ha scoperto che in una varietà di professioni - scrittura, calcio, invenzione, lavoro di polizia e altre occupazioni - il 20% superiore delle persone ha prodotto circa il 50% della produzione, indipendentemente dal fatto che si tratti di touchdown, brevetti , casi risolti o software (Augustine 1979).}

Il secondo articolo ( ... How Valid is the Underlying Research? ) È stato scritto principalmente per affrontare la revisione critica del primo di Laurent Bossavit :

• critica originale in francese: Folklore ou fait scientifique, comment les différencier
• Traduzione inglese: fatti e folklore nell'ingegneria del software .

Nel secondo articolo, nella sezione A Deeper Dive Into the Research Supporting "10x" McConnell ricontrolla più in dettaglio i riferimenti utilizzati nel primo articolo e conclude:

... Mentre ho rivisto queste citazioni ancora una volta scrivendo questo articolo, ho concluso di nuovo che supportano la conclusione generale che ci sono 10 differenze di produttività tra i programmatori. Gli studi hanno coinvolto collettivamente centinaia di programmatori professionisti in una gamma di attività di programmazione.

... il corpo di ricerca che supporta l'affermazione 10x è solido come qualsiasi ricerca che è stata fatta in ingegneria del software. Gli studi che supportano l'affermazione 10x non sono singolarmente soggetti alla limitazione metodologica descritta nella Figura 1, poiché stanno studiando la variabilità individuale stessa (cioè solo il lato sinistro della figura). Bossavit non cita nemmeno uno studio - imperfetto o meno - che contrapponga l'affermazione 10x, e nemmeno io ho visto nessuno di questi studi. Il fatto che nessuno studio abbia prodotto risultati che contraddicono l'affermazione 10x fornisce ancora più fiducia nell'affermazione 10x. Quando considero il numero di studi che sono stati condotti, in generale trovo la ricerca non solo suggestiva, ma conclusiva, il che è raro nella ricerca di ingegneria del software.

Per completezza, l'elenco dei riferimenti utilizzati nelle variazioni di produttività ... è anche riportato di seguito:

Riferimenti

Augustine, NR 1979. "Le leggi di Augustine e i principali programmi di sviluppo del sistema". Revisione della gestione dei sistemi di difesa: 50-76.

Boehm, Barry W. e Philip N. Papaccio. 1988. "Comprensione e controllo dei costi del software". Transazioni IEEE sull'ingegneria del software SE-14, n. 10 (ottobre): 1462-77.

Boehm, Barry, et al, 2000. Stima dei costi del software con Cocomo II, Boston, Mass .: Addison Wesley, 2000.

Boehm, Barry W., TE Grey e T. Seewaldt. 1984. "Prototipazione contro specifica: un esperimento multiprogetto". Transazioni IEEE sull'ingegneria del software SE-10, n. 3 (maggio): 290-303. Anche in Jones 1986b.

Card, David N. 1987. "Un programma di valutazione della tecnologia software". Tecnologia informatica e software 29, n. 6 (luglio / agosto): 291-300.

Curtis, Bill. 1981. "Variabilità sostanziale del programmatore". Atti dell'IEEE 69, n. 7: 846.

Curtis, Bill, et al. 1986. "Psicologia del software: la necessità di un programma interdisciplinare". Atti dell'IEEE 74, n. 8: 1092-1106.

DeMarco, Tom e Timothy Lister. 1985. "Performance del programmatore ed effetti sul posto di lavoro". Atti dell'ottava conferenza internazionale sull'ingegneria del software. Washington, DC: IEEE Computer Society Press, 268-72.

DeMarco, Tom e Timothy Lister, 1999. Peopleware: progetti produttivi e squadre, 2d Ed. New York: Dorset House, 1999.

Mills, Harlan D. 1983. Produttività del software. Boston, Mass .: Piccolo, marrone.

Sackman, H., WJ Erikson e EE Grant. 1968. "Studi sperimentali esplorativi che mettono a confronto le prestazioni di programmazione online e offline". Comunicazioni dell'ACM 11, n. 1 (gennaio): 3-11.

Valett, J. e FE McGarry. 1989. "Un riassunto delle esperienze di misurazione del software nel laboratorio di ingegneria del software." Journal of Systems and Software 9, n. 2 (febbraio): 137-48.

Weinberg, Gerald M. ed Edward L. Schulman. 1974. "Obiettivi e prestazioni nella programmazione per computer". Fattori umani 16, n. 1 (febbraio): 70-77.

Un programmatore veramente terribile può avere una produttività inferiore allo zero (i bug che introducono richiedono più tempo per essere risolti di quanto non ci vorrebbe solo per fare tutto il loro lavoro per loro).

E un programmatore veramente bravo può fare cose che i programmatori mediocri e mediocri non riuscirebbero mai a realizzare, indipendentemente da quanto tempo hai dedicato loro.

Quindi, per questi motivi, è difficile parlare di "10 volte più produttivo" o "100 volte più produttivo".

La cosa da ricordare, tuttavia, è che la maggior parte dei datori di lavoro dei programmatori non ha alcuna necessità di svolgere i compiti difficili che i programmatori medi non sono in grado di gestire. La maggior parte del codice in fase di scrittura è costituita da siti Web, app line of business, app intranet, ecc., In gran parte non è poi così difficile. Il programmatore produttivo in quell'ambiente è colui che è il migliore per comprendere e attuare le esigenze degli utenti, non colui che può scrivere il codice più intelligente.

In effetti, la maggior parte dei datori di lavoro dei programmatori starebbe meglio con un buon programmatore piuttosto che con un grande programmatore, perché il grande si annoierà e se ne andrà. Devo trovare una buona corrispondenza tra programmatori e lavori.

Fatti e errori degli stati di ingegneria del software (Fatto 2, disponibile nell'anteprima di Amazon):

I migliori programmatori sono fino a 28 volte meglio dei peggiori programmatori, secondo una ricerca sulle "differenze individuali". Dato che la loro retribuzione non è mai commisurata, sono i maggiori affari nel campo del software.

(guarda l'elenco delle fonti lì per la ricerca)

Naturalmente, se si confronta la produttività di un non programmatore (o di un programmatore molto cattivo) con quella buona (in termini di esperienza e conoscenza), la differenza può essere infinitamente grande ( n/0 == infinityper qualsiasi positivo n), ma non è né equa né confronto ragionevole.

Il tuo stipendio può dipendere da più fattori (in ordine casuale):

• Tecnologie utilizzate
• Paese / stato in cui lavori
• Ricchezza dell'azienda
• Tipo di attività dell'azienda
• Numero di sviluppatori in azienda
• Da quanto tempo lavori in azienda
• Politiche d'ufficio

insieme al tuo personale ...

• produttività
• conoscenza ed esperienza
• coinvolgimento negli affari dell'azienda (per startup)
• capacità di negoziazione
• attrattiva e abilità sessuali, lol (beh, l'intelligenza è sexy)

La mia risposta è "sì, ma fai attenzione a come usi questa metrica".

Un programmatore che, per così dire, funziona in modo ottimale, è uno che crea funzionalità e causa meno errori che devono essere riparati rispetto ai suoi fratelli con prestazioni inferiori. Non troverei difficile credere che queste persone possano esibire a 10 volte la produttività degli altri, in particolare se si considera che una singola scelta buona o cattiva fatta in un'ora può avere immediatamente 10 ore di impatto e i programmatori fanno molte di queste scelte la maggior parte dei giorni.

Ma...

Stai attento a misurare questo. Non mi fido davvero della maggior parte delle misurazioni sulla produttività poiché ho visto infiniti casi in cui quasi tutte le metriche conosciute non riescono a considerare qualcosa che considero vitale per la produttività del team. Quindi generalmente odio numeri così duri per "produttività". Ecco alcuni esempi:

• Lines of code (LOC) - una metrica generalmente odiata, dal momento che un programmatore sconsiderato può generare molte righe di codice orribili, verbose, inefficienti, difficili da eseguire il debug mentre un buon programmatore crea alcune righe di codice, eleganti, facili da riparare, raramente interrotte in più tempo, ma che nel complesso sono una scelta migliore.
• Bug generati e / o tempo per risolvere: tutti genereranno alcuni bug e spesso i bug più costosi sono generati da una serie di decisioni sbagliate per le quali il generatore del problema è solo l'ultimo dell'effetto domino. Inoltre, i tuoi grandi debugger non sono sempre i tuoi grandi designer - hai bisogno di entrambi.
• Secondo quasi tutte le metriche, ci sono grandi sviluppatori che fanno così male avere in una squadra, che 1 sviluppatore "super produttivo" porterà via 10 sviluppatori sostanzialmente buoni e raramente vedo qualcuno che può fare tutto bene, quindi avremo bisogno più di 1 persona nel progetto.
• Non c'è modo di spiegare facilmente quelle persone meravigliose che vedono i problemi prima che si presentino seri e li risolvono, in particolare quando il problema è un gap in un processo - CM difettoso, build inefficiente, un gap nei test, un difetto di sicurezza - questi spesso sembrano una grande perdita di tempo finché non ti rendi conto che ti salvano dal disastro - non c'è modo di misurarlo.
• Inoltre, ci sono persone che ritengo necessarie in una squadra di una certa dimensione che definirei "costruttori di coesione" - raramente il massimo della produttività, di solito sono ancora nel 20% superiore e fanno il prezioso lavoro di aiutare a crescere nuove persone, collegando i punti e assicurandosi che vengano poste le domande giuste e che le persone giuste vengano mantenute in loop, scrivono (senza domande!) la documentazione chiave a cui tutti fanno riferimento perché non è solo il documento giusto, ma è messo insieme nel modo giusto. Se vuoi che 10 persone lavorino al massimo dell'efficienza, hai assolutamente bisogno di una di queste persone e non lo otterrai se metti 10 super sviluppatori in una stanza.

Molti sistemi di misurazione hanno cercato di tenere conto di questi fattori, ma devo ancora vedere che ce n'è uno che tiene conto di tutti questi problemi, quindi non sono mai stato troppo colpito da fattori come "un buon sviluppatore è 10 volte più produttivo di un mediocre "perché devo chiedermi se la metrica rappresenti davvero tutto il lavoro che deve andare in un prodotto in corso di successo o in una squadra di successo e fiorente.

Quindi il mio grande avvertimento è: che cosa hai intenzione di fare con questa metrica? Userò qualcosa del genere per essere consapevole del fatto che gli strumenti e il talento giusti possono causare una grande differenza nel modo in cui il lavoro viene svolto, ma se si tenta di ottimizzare in un team in cui ogni individuo produce 10 volte l'output "tipico", si è destinati a un caso di frustrazione. Meglio è trovare un modo per convincere il tuo team a fare 2-3 volte quello che stavano facendo prima lavorando insieme meglio.

Nel suo libro The Leprechauns of Software Engineering , Laurent Bossavit descrive la ricerca della dichiarazione di produttività 10x. Ha scoperto che non ci sono numeri di suono dietro di esso - l'affermazione è passata dalla speculazione al "fatto accertato" da un gioco telefonico di affermazioni successivamente più concrete nella citazione. Il post sul blog che comprende il capitolo sull'affermazione 10x e include le citazioni e le citazioni errate pertinenti, è fatto e folklore nell'ingegneria del software .

Ciò che ha scoperto è qualcosa del genere: qualcuno nel 1968 ha fatto uno studio comparando le persone che risolvono un particolare problema di debug e ha scoperto che alcuni di loro lo hanno fatto 10 volte più velocemente di altri. Da ciò potremmo concludere che alcune persone sono 10 volte più brave a risolvere quel problema , oppure possiamo concludere che alcune persone sono state fortunate , o una grande varietà di cose diverse. Alcune persone hanno scelto di citare questo come (sono tutte parafrasi) "uno studio (Sackman et al, 1968) ha scoperto che alcuni programmatori lavorano 10 volte più velocemente di altri". Poi è diventato "gli studi hanno dimostrato che i buoni programmatori sono 10 volte migliori della media", infine "è risaputo che la produttività dei programmatori varia di 10 volte tra gli individui". Quindi qualcuno raccoglie tutte queste citazioni, citando erroneamente una fonte originale per dire "molti ricercatori credono ...".

Certo, non sarebbe un gioco per telefono se cambiasse solo la veridicità dell'asserzione: il moltiplicatore va anche a 11 e oltre .

" Il programmatore produttivo in quell'ambiente è colui che è il migliore nel comprendere e attuare le esigenze degli utenti, non quello che può scrivere il codice più intelligente. " (Dalla risposta di Carson63000 )

Quel punto chiave accoppiato con bethlakshmiI punti fanno un punto enorme. Un grande sviluppatore può essere eccezionale nella sua unica fetta di realtà ma spezzarsi non appena il mondo cambia. Essere in grado di tenere il passo con le esigenze del business è molto più importante di ogni altra cosa. Alla fine della giornata, a meno che la tua attività non sia tecnologia, l'azienda non si preoccupa della tecnologia; hanno bisogno di soluzioni. Quindi, essere bravi con i modelli di progettazione non significa occuparsi in modo accorto degli utenti finali che hanno solo bisogno di un dump dei dati da mostrare su una pagina web. Ho visto sviluppatori mediocri assicurarsi un lavoro soddisfacendo l'azienda che li supporta, mentre i grandi sviluppatori si annoiano e se ne vanno alla ricerca di una sfida infinita. A seconda dell'organizzazione e dei progetti, è possibile alimentare questi sviluppatori affamati di sfide, ma probabilmente ci sarà un momento in cui non Ho bisogno di quella quantità di potenza di elaborazione. A questi sviluppatori non piace semplicemente restare inattivi come un processore. Si spegneranno e si riavvieranno altrove.

Infine, dirò che va bene sapere chi sono i tuoi "principali" interpreti, ma un "team" di sviluppo è ancora un team. Per ribadire bethlakshmi, " che cosa hai intenzione di fare con questa metrica?"Se hai bisogno di una squadra che si comporti come una squadra, non mi concentrerei su queste metriche. Mi accorgerei che anche il giocatore più piccolo è ancora una parte importante della squadra. Anche con il 60% in meno della produttività della tua chiave giocatore, quel giocatore potrebbe dare alla tua squadra qualcosa di cui ha bisogno. Scopri di cosa si tratta e prova a moltiplicarlo. Non bruciare il tuo giocatore chiave supponendo che debba guidare la squadra, trovare modi per moltiplicare anche la sua produzione, contaminando gli altri giocatori con quella grandezza. Ciò richiede un po 'di creatività, non solo numeri. Alla fine, potresti imparare che ciò che rende un buon programmatore non è nemmeno quel programmatore, potrebbero essere i suoi pari, le sue opportunità sul posto di lavoro o potresti anche essere tu.