Gran productividad del programador: ¿representa 10.000 veces la diferencia? [cerrado]

Un gran operador de torno gana varias veces el salario de un operador de torno promedio, pero un gran escritor de código de software vale 10.000 veces el precio de un escritor de software promedio. - Bill Gates

Digamos que hay un "gran" ingeniero de software y un ingeniero de software "promedio" en el mismo equipo. ¿Cómo puede explicar que un ingeniero sea 10,000 veces más productivo? No puedo entender esto, dado que ambos están asumiendo su parte de características, errores e investigaciones, y entregan constantemente con calidad. ¿Posiblemente mi descripción justifique que estén por encima del "promedio"? "genial"?

El punto de la cita no es que uno sea 10K veces más productivo, es que uno es 10K veces más valioso que el otro. El software tiene la condición única de que un diseño o implementación defectuosos pueden permanecer inactivos durante años (una parte que está mal mecanizada generalmente simplemente "no funcionará" y no entrará en el campo), bien dentro del ciclo de vida del producto hasta que uno día levanta la cabeza en una situación intratable.

Todos deberían estar familiarizados con el costo exponencial de la reparación de un defecto a medida que pasa del diseño, a la implementación, a las pruebas, a la producción y al mantenimiento.

Cuando se tiene en cuenta la posible responsabilidad, así como la reputación corporativa, es fácil concluir que el desarrollador que sabía lo suficiente para evitar el problema vale 10.000 veces más que el que implementó una solución pobre o ignorante o ingenuamente.

Editar (Primavera 2014): "Heartbleed"

El nadador olímpico promedio puede nadar alrededor de 2.5 millas por hora a una distancia.

La persona promedio (que puede nadar) puede nadar aproximadamente 1.5 millas por hora a una distancia.

Esto significa que el nadador olímpico promedio puede nadar en el Canal de la Mancha en aproximadamente 8 horas.

Sería lógico entonces que el nadador olímpico sea un 60% más rápido que el promedio y que el nadador promedio tomaría alrededor de 13 horas para completar la carrera ...

Excepto que si yo, un nadador promedio, intentara nadar en el Canal de la Mancha, la única forma en que voy a cruzar es arrastrarme a la orilla una semana después.

Muchos aspectos de la programación son como nadar en el Canal de la Mancha. Es hundirse o nadar. Ni siquiera sé si 10,000 veces mejor es realmente una forma precisa de describir la distinción entre el software completo que funciona y el software incompleto que no funciona.

Digamos que hay un "gran" ingeniero de software y un ingeniero de software "promedio" en el mismo equipo. ¿Cómo puede explicar que un ingeniero sea 10,000 veces más productivo? No puedo entender esto, dado que ambos están asumiendo su parte de características, errores e investigaciones, y entregan constantemente con calidad. ¿Posiblemente mi descripción justifique que estén por encima del "promedio"? "genial"?

Eso es un montón de "obsequios" para un ingeniero de software "promedio". En realidad, el gran ingeniero de software resuelve problemas en horas que el ingeniero promedio nunca resolverá correctamente. El gran ingeniero de software resuelve problemas comunes en un tercio del tiempo con un quinto de código y un décimo de errores. El código del gran ingeniero de software se ejecuta en O (n) mientras que el código promedio del ingeniero de software se ejecuta en tiempo O (n ^ 3). El gran ingeniero de software puede adaptar su solución mientras espera, mientras que el ingeniero de software promedio se queja de los cambios tardíos en las especificaciones y dice que ahora llevará semanas cumplir con los nuevos requisitos. Estas son todas las diferencias reales que he visto cuando un gran ingeniero rehace el trabajo del ingeniero promedio.

Trataré de abordar esto en términos de las diferencias:

Un gran ingeniero hará lo siguiente mejor que un promedio:

• Diseño: produzca diseños que necesitarán menos modificaciones y serán más flexibles. Esto se traduce en ahorros a lo largo de la vida útil del software.
• Características: se implementarán en ayunas y serán implementaciones más limpias.
• Errores: se encontrarán más rápido, se solucionarán bien y no introducirán menos errores futuros.
• Investigaciones: se concluirán más rápido con mejores resoluciones y resultados.

Tomados en conjunto, estos serían salvar a los lotes de la compañía de dinero en tiempo de desarrollo y hacer que los lotes de la compañía de dinero en oportunidades adicionales.

Un gran programador muy a menudo no solo "toma su parte de características, errores e investigaciones" para ganar un salario. A veces abandonan y comienzan su propia empresa, o se unen a una startup, o inician un nuevo proyecto de skunkworks, o, en los viejos tiempos, tal vez, se unieron a un laboratorio de I + D de cielo azul de renombre nacional e innovan algún producto que nadie cree que necesitan. , o el pensamiento era posible hacer con el software, antes de la gran visión, habilidad y sudor de ese gran programador.

Gran parte del "valor" de este programador se trata de una recompensa proporcional por el riesgo. El programador podría incluso haber sido despedido por pensar en productos de software tan locos, en lugar de recibir el pago 2X o más.

Lo que sucede con un inicio de software ocasional: salir a bolsa por millones / miles de millones, o ser adquirido por Google o Facebook, et.al. por cantidades similares, rara vez le sucede a los operadores de torno (aunque al menos un exitoso fundador de la compañía de tecnología de Silicon Valley tenía un torno en su taller).

Hay algunas soluciones que solo los mejores programadores podrán resolver. Lanzar miles de mediocres no funcionará. También es más difícil coordinar sus esfuerzos, incluso si pudieran combinar colectivamente las piezas de su conocimiento.

Responder preguntas sobre SO no es diferente. Hay muchos problemas en los que, de un grupo de desarrolladores promedio, uno puede llegar a la respuesta. Es probable que estos sitios web coordinen los esfuerzos mucho mejor que la mayoría de los equipos de desarrollo, lo cual es triste.

Creo que hay alguna evidencia empírica que respalda la cita de Gates. Recuerdo haber leído (aunque no recuerdo la fuente) que en los grupos de mecanografía la diferencia en la producción (fácilmente medible para un grupo de mecanografía) entre los del quinto percentil y los del 95% era algo así como 3 a 1. Pero Después de que el software de procesamiento de texto estuvo disponible, la proporción aumentó a algo así como 10 o 20 a 1, porque aquellos que podían usar las funciones avanzadas del software obtuvieron aún más ventajas relativas.

Presumiblemente para el desarrollo de software, la relación sería aún mayor, ya que hay aún más libertad para aprovechar todo tipo de herramientas, técnicas, etc. Es más difícil medir las diferencias, pero la mayoría de los intentos salen con al menos 10 a 1, y eso presumiblemente está subestimando la diferencia porque solo mide lo que es fácil de medir.

En algo como escribir u operar un torno, las personas en el 1% superior probablemente estén muy cerca de alcanzar los límites fisiológicos de lo que es posible. En el caso de la programación, claramente no lo son (la proporción de cuánto tiempo lleva escribir código versus cuánto tiempo lleva escribir código es enorme), por lo que debería haber espacio para mucha más variación.