Grande produttività del programmatore: contabilità per 10.000 volte di differenza? [chiuso]

Un grande operatore di tornio controlla più volte il salario di un operatore di tornio medio, ma un grande scrittore di codice software vale 10.000 volte il prezzo di un normale scrittore di software. - Bill Gates

Supponiamo che ci sia un "grande" ingegnere informatico e un "medio" ingegnere informatico nella stessa squadra. Come si può rendere conto che un ingegnere è 10.000 volte più produttivo? Non riesco proprio a capirlo, dato che entrambi stanno assumendo la loro parte di funzionalità, bug e indagini, e offrono costantemente qualità. La mia descrizione potrebbe giustificare che siano superiori alla "media"? "grande"?

Il punto della citazione non è che uno è 10K volte più produttivo, è che uno è 10K volte il valore dell'altro. Il software ha la condizione unica in cui un design o un'implementazione difettosi possono rimanere inattivi per anni (una parte che è stata fabbricata in modo errato di solito semplicemente "non funziona" e non lo fa sul campo), fino al ciclo di vita del prodotto fino a quando giorno che alza la testa in una situazione intrattabile.

Tutti dovrebbero avere familiarità con il costo esponenziale della correzione di un difetto nel passaggio dalla progettazione, all'implementazione, al collaudo, alla produzione, alla manutenzione.

Quando si tiene conto della possibile responsabilità e della reputazione aziendale, è facile concludere che lo sviluppatore che sapeva abbastanza per evitare il problema vale 10.000 volte quello che ha implementato in modo ignorante o ingenuo una soluzione scadente.

Modifica (primavera 2014): "Heartbleed"

Il nuotatore olimpico medio può nuotare a circa 2,5 miglia all'ora a distanza.

La persona media (che sa nuotare) può nuotare a circa 1,5 miglia all'ora a distanza.

Ciò significa che il nuotatore olimpico medio può nuotare nel Canale della Manica in circa 8 ore.

Sarebbe quindi ragionevole pensare che il nuotatore olimpico sia il 60% più veloce della media e che il nuotatore medio impiegherebbe circa 13 ore per completare la gara ...

Solo che se io, un nuotatore medio, tentassi di nuotare nel Canale della Manica, l'unico modo per attraversare è lavato sulla riva una settimana dopo.

Molti aspetti della programmazione sono come nuotare nel Canale della Manica. È affondare o nuotare. Non so nemmeno se 10.000 volte meglio sia davvero un modo accurato per descrivere la distinzione tra software completo che funziona e software incompleto che non funziona.

Supponiamo che ci sia un "grande" ingegnere informatico e un "medio" ingegnere informatico nella stessa squadra. Come si può rendere conto che un ingegnere è 10.000 volte più produttivo? Non riesco proprio a capirlo, dato che entrambi stanno assumendo la loro parte di funzionalità, bug e indagini, e offrono costantemente qualità. La mia descrizione potrebbe giustificare che siano superiori alla "media"? "grande"?

Questo è un sacco di "dati" per un ingegnere del software "medio". In realtà, il grande ingegnere del software risolve in poche ore problemi che l'ingegnere medio non risolverà mai correttamente. Il grande ingegnere del software risolve i problemi ordinari in un terzo del tempo con un quinto del codice e un decimo del numero di bug. Il codice dell'ingegnere del software eccellente viene eseguito in O (n) mentre il codice dell'ingegnere del software medio viene eseguito in O (n ^ 3) tempo. Il grande ingegnere del software può adattare la sua soluzione mentre aspetti, mentre il tecnico del software medio si lamenta delle modifiche tardive alle specifiche e afferma che ci vorranno settimane per soddisfare i nuovi requisiti ora. Queste sono tutte vere differenze che ho visto quando un grande ingegnere rifa il lavoro dell'ingegnere medio.

Proverò ad affrontarlo in termini di differenze:

Un grande ingegnere farà quanto segue meglio di un normale:

• Design: produce progetti che richiederanno meno modifiche ed essere più flessibili. Ciò si traduce in risparmi per tutta la durata del software.
• Caratteristiche: verranno implementate a digiuno e saranno implementazioni più pulite.
• Bug: verranno trovati più velocemente, risolti bene e non verranno introdotti meno bug futuri.
• Indagini: si concluderanno più rapidamente con migliori risoluzioni e risultati.

Nel loro insieme, questi risparmierebbero all'azienda un sacco di soldi nei tempi di sviluppo e renderebbero molti soldi all'azienda in ulteriori opportunità.

Un grande programmatore molto spesso non si limita a "assumere la propria parte di funzionalità, bug e indagini" per guadagnare uno stipendio. A volte lasciano e avviano la propria azienda, si uniscono a una startup o avviano un nuovo progetto skunkworks o, in passato forse, si sono uniti a un laboratorio di ricerca e sviluppo di fama internazionale a cielo blu e innovano alcuni prodotti che nessuno pensa di aver nemmeno bisogno , o si pensava fosse possibile fare con il software, prima dell'intuizione, dell'abilità e del sudore di quel grande programmatore.

Gran parte di questo "valore" del programmatore riguarda una ricompensa proporzionata per il rischio. Il programmatore potrebbe anche essere stato licenziato per aver pensato a prodotti software così folli, piuttosto che essere pagato 2X o più.

Cosa succede con un'avvio occasionale del software: diventare pubblico per milioni / miliardi o essere acquisito da Google o Facebook, ecc. per importi simili, accade raramente agli operatori del tornio (anche se almeno un fondatore della società tecnologica di successo della Silicon Valley aveva un tornio nel suo laboratorio).

Ci sono alcune soluzioni che solo i migliori programmatori saranno in grado di risolvere. Lanciare migliaia di mediocri non funzionerà. È anche più difficile coordinare i loro sforzi anche se potrebbero unire collettivamente i pezzi delle loro conoscenze.

Rispondere alle domande su SO non è diverso. Ci sono molti problemi in cui da un gruppo di sviluppatori medi, uno è in grado di trovare la risposta. Questi siti web probabilmente svolgono un lavoro molto migliore nel coordinare gli sforzi rispetto alla maggior parte dei team di sviluppo, il che è triste.

Penso che ci siano alcune prove empiriche a supporto della citazione di Gates. Ricordo di aver letto (anche se non ricordo la fonte) che nei pool di battitura la differenza nell'output (facilmente misurabile per un pool di battitura) tra quelli nel 5o percentile e quelli nel 95% era qualcosa come 3 a 1. Ma dopo che il software di elaborazione testi divenne disponibile, il rapporto salì a qualcosa come 10 o 20 a 1, perché coloro che potevano usare le funzionalità avanzate del software ottennero un vantaggio ancora maggiore.

Presumibilmente per lo sviluppo del software il rapporto sarebbe ancora più elevato, dal momento che c'è ancora più libertà di trarre vantaggio da tutti i tipi di strumenti, tecniche, ecc. È più difficile misurare le differenze, ma la maggior parte dei tentativi esce con almeno 10 a 1, e questo presumibilmente sottovaluta la differenza perché misura solo ciò che è facile da misurare.

In qualcosa come scrivere o utilizzare un tornio, le persone in cima all'1% sono probabilmente abbastanza vicine a colpire i limiti fisiologici di ciò che è possibile. Nel caso della programmazione chiaramente non lo sono (il rapporto tra il tempo impiegato per scrivere il codice e il tempo impiegato per scrivere il codice è enorme), quindi dovrebbe esserci spazio per molte più variazioni.