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

19

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"?

productivity El impacto
fuente
2
No estoy seguro de si esta pregunta es adecuada para stackoverflow, pero también estoy interesado en las respuestas.
Austin Henley
18
La cita dice que una excelente vale 10k veces el precio de una media, nada sobre "productividad" allí.
Finalizado el
44
De hecho, un gran programador puede ser mucho menos productivo que uno promedio. En lugar de hacer su "trabajo", hizo algo mejor que estaba fuera del radar, y tal vez incluso creó una línea de productos completamente nueva que dejó obsoleto el trabajo del programador productivo.
hotpaw2
2
De lo único que estoy seguro es de que necesitas ambas cosas si quieres innovar Y hacer! @ # $ Done.
Erik Reppen
66
Abe Lincoln dijo una vez: "Si tuviera ocho horas para cortar un árbol, pasaría seis horas afilando mi hacha", esto nunca es más cierto en la programación, donde hacer un "buen" trabajo supera con creces un trabajo rápido. El buen programador puede parecer menos productivo, pero se está preparando para todos los problemas que se avecinan.
BeardedO

Respuestas:

57

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"

Dave Nay
fuente
1
Sutil que sería la falta de responsabilidad lo que hace que un programador valga 10.000 veces más que otro. No pensé en eso originalmente, gracias. Sin embargo, parece una cosa increíblemente difícil de medir.
TheImpact
2
@TheImpact: Es difícil "medir" ya que generalmente solo se hace evidente mucho después de que se realiza la codificación y el proyecto está fuera del mundo. Rendimiento y confiabilidad y generalmente después de pensar en un programador "promedio"; mientras que están integrados en la estructura misma del diseño que proviene de un gran programador.
NotMe
10
+1. Si el valor de un buen desarrollador de software es 100, ¿cuántas veces más es eso que -10?
Nicole
3
También está el tema de la oferta y la demanda. Raymond Chen: "Confío en que solo unas cinco personas en el mundo escriban código tan avanzado, y no soy uno de ellos". Blogs.msdn.com/b/oldnewthing/archive/2011/04/15/10154245 .aspx ". Esto es particularmente cierto para la codificación relacionada con la seguridad, ya que los problemas pueden pasar desapercibidos (o al menos, pasar inadvertidos por los sombreros blancos) durante años. Schneier comenta que la mayoría de los programadores pueden escribir un algoritmo de cifrado que el programador mismo no puede romper. Observo que esto no implica que alguien mejor no pueda hacerlo ... a menos que el escritor sea el mejor.
Brian
1
Considere el primer lanzamiento del cohete Ariane V. Hubo una división no descubierta por cero que causó la destrucción del cohete. No solo eso, sino que el código en cuestión había dejado de tener valor en el instante en que se encendió el cohete. Piense en los millones que habrían ahorrado con un mejor programador.
Loren Pechtel
44

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.

Morgan Herlocker
fuente
31

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.

Kevin Cline
fuente
66
+1: desafortunadamente es bastante común que los problemas no obtengan soluciones correctas. Es una locura la frecuencia con la que hay soluciones y embragues que solo "solucionan" el problema inmediato, pero es casi seguro que producirán aún más problemas en unas pocas semanas. "Pero eso es en unas pocas semanas, ¡dejemos que nuestro futuro se ocupe de esos problemas!"
Joachim Sauer
La diferencia entre una solución que funciona y otra que no funciona para un problema casi imposible se aproxima a infinito, por ejemplo, la organización sobrevive, se quiebra, o algo explota en el laboratorio y mata a todos los ingenieros (historia clásica del drama de TV ...), etc. .
hotpaw2
@ hotpaw2: Cierto, no estaba pensando en nada tan dramático. Estaba pensando en problemas con un poco de complejidad matemática, por ejemplo, cálculos de gráficos como el tipo topológico. Un ingeniero promedio puede pasar semanas escribiendo una solución lenta y con errores. Un gran ingeniero asignará los requisitos del negocio a un problema bien conocido, luego buscará una biblioteca o algoritmo publicado.
Kevin Cline
9

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.

Oded
fuente
4

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).

hotpaw2
fuente
44
"... salir a bolsa por millones / miles de millones, ....." A pesar de la retórica de los medios, esto rara vez sucede también para los ingenieros de software. Por cada uno que "lo logra", miles caen en la oscuridad y / o pasan por muchas rondas de VC y vuelven a un trabajo de 9-5 días con nada más que sabor amargo en la boca ...
mattnz
1
@mattnz: con probabilidades probablemente un poco mejores que las 10,000 a 1 que van con el supuesto valor de 10,000X de ese programador.
hotpaw2
3

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.

JeffO
fuente
3

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.

psr
fuente
1
Guau. Hable acerca de perder el punto. Cualquier medida de productividad del programador que comience con la "velocidad de tipeo" como punto de anclaje seguramente obtendrá una respuesta tonta.
Riwalk