"Un buen programador puede ser 10 veces más productivo que uno mediocre" [cerrado]

Había leído una entrevista con un gran programador (no está en inglés) y en él dijo que "un gran programador puede ser 10 veces más bueno que uno mediocre", explicando por qué los buenos programadores están muy bien pagados y por qué Las compañías de programación ofrecen muchas facilidades para sus empleados. La idea era que existe una gran demanda de buenos programadores, debido a la razón anterior y es por eso que las compañías pagan mucho para traerlos.

¿Estás de acuerdo con esta afirmación? ¿Conoces algún hecho objetivo que pueda respaldarlo?

Editar: la pregunta no tiene nada que ver con la experiencia; Si habla de un gran programador con 1 año de experiencia, entonces debe ser 10 veces más productivo que un programador mediocre con 1 año de experiencia. Estoy de acuerdo en que desde cierta experiencia años en adelante, las cosas comienzan a disiparse, pero ese no es el propósito de la pregunta.

En dos artículos escritos por Steve McConnell se proporciona una descripción general y un análisis bastante exhaustivos de la investigación sobre las diferencias de productividad :

• Variaciones de productividad entre desarrolladores de software y equipos: el origen de "10x"

• Orígenes de 10X: ¿cuán válida es la investigación subyacente?

El primer artículo ( Variaciones de productividad ... ) establece:

... El estudio original que encontró grandes variaciones en la productividad de la programación individual fue realizado a fines de la década de 1960 por Sackman, Erikson y Grant (1968). Estudiaron programadores profesionales con un promedio de 7 años de experiencia y encontraron que la proporción del tiempo de codificación inicial entre los mejores y peores programadores era de aproximadamente 20 a 1; la relación de tiempos de depuración de más de 25 a 1; del tamaño del programa 5 a 1; y de la velocidad de ejecución del programa de aproximadamente 10 a 1. No encontraron relación entre la cantidad de experiencia de un programador y la calidad o productividad del código.

El examen detallado de los hallazgos de Sackman, Erickson y Grant muestra algunos defectos en su metodología ... Sin embargo, incluso después de tener en cuenta los defectos, sus datos aún muestran una diferencia de más de 10 veces entre los mejores programadores y los peores.

En años posteriores al estudio original, muchos otros estudios de programadores profesionales han confirmado el hallazgo general de que "Hay diferencias de orden de magnitud entre los programadores" (Curtis 1981, Mills 1983, DeMarco y Lister 1985, Curtis et al. 1986 , Card 1987, Boehm and Papaccio 1988, Valett and McGarry 1989, Boehm et al 2000) ...

^{Este artículo también tiene una nota al margen interesante:}

^{Este grado de variación no es exclusivo del software. Un estudio realizado por Norm Augustine descubrió que en una variedad de profesiones (escritura, fútbol, ​​invención, trabajo policial y otras ocupaciones), el 20 por ciento de las personas más importantes producían alrededor del 50 por ciento de la producción, ya sea la toma de contacto, patentes , casos resueltos o software (Augustine 1979).}

El segundo artículo ( ... ¿Qué tan válida es la investigación subyacente? ) Se ha escrito principalmente para abordar la revisión crítica del primero por Laurent Bossavit :

• Crítica original en francés: Folklore ou fait scientifique, comentario les différencier
• Traducción Inglés: Realidad y el folclore en la ingeniería de software .

En el segundo artículo, en la sección Una inmersión más profunda en la investigación que respalda "10x" McConnell vuelve a verificar con más detalles las referencias utilizadas en el primer artículo y concluye:

... Al revisar estas citas una vez más al escribir este artículo, concluí nuevamente que respaldan el hallazgo general de que hay 10 veces más diferencias de productividad entre los programadores. Los estudios han involucrado colectivamente a cientos de programadores profesionales en un espectro de actividades de programación.

... el cuerpo de investigación que respalda la afirmación 10x es tan sólido como cualquier investigación que se haya realizado en ingeniería de software. Los estudios que respaldan la afirmación 10x no están sujetos a la limitación metodológica descrita en la Figura 1, porque están estudiando la variabilidad individual en sí misma (es decir, solo el lado izquierdo de la figura). Bossavit no cita ni siquiera un estudio, defectuoso o de otro tipo, que contrarreste la afirmación 10x, y tampoco he visto ninguno de estos estudios. El hecho de que ningún estudio haya producido resultados que contradigan el reclamo 10x proporciona aún más confianza en el reclamo 10x. Cuando considero la cantidad de estudios que se han realizado, en conjunto encuentro que la investigación no solo es sugerente, sino concluyente, lo cual es raro en la investigación de ingeniería de software.

En aras de la exhaustividad, la lista de referencias utilizadas en las variaciones de productividad ... también se cita a continuación:

Referencias

Agustín, NR 1979. "Las leyes de Agustín y los principales programas de desarrollo del sistema". Revisión de la gestión de sistemas de defensa: 50-76.

Boehm, Barry W. y Philip N. Papaccio. 1988. "Comprensión y control de costos de software". Transacciones IEEE sobre Ingeniería de Software SE-14, no. 10 (octubre): 1462-77.

Boehm, Barry, et al, 2000. Estimación de costos de software con Cocomo II, Boston, Massachusetts: Addison Wesley, 2000.

Boehm, Barry W., TE Gray y T. Seewaldt. 1984. "Creación de prototipos versus especificación: un experimento multiproyecto". Transacciones IEEE sobre Ingeniería de Software SE-10, no. 3 (mayo): 290-303. También en Jones 1986b.

Card, David N. 1987. "Un programa de evaluación de tecnología de software". Tecnología de la información y el software 29, no. 6 (julio / agosto): 291-300.

Curtis, Bill. 1981. "Variabilidad sustancial del programador". Actas del IEEE 69, no. 7: 846.

Curtis, Bill y col. 1986. "Psicología del software: la necesidad de un programa interdisciplinario". Actas del IEEE 74, no. 8: 1092-1106.

DeMarco, Tom y Timothy Lister. 1985. "Rendimiento del programador y los efectos del lugar de trabajo". Actas de la 8ª Conferencia Internacional sobre Ingeniería de Software. Washington, DC: IEEE Computer Society Press, 268-72.

DeMarco, Tom y Timothy Lister, 1999. Peopleware: Proyectos y equipos productivos, 2ª ed. Nueva York: Dorset House, 1999.

Mills, Harlan D. 1983. Productividad del software. Boston, Massachusetts: Little Brown.

Sackman, H., WJ Erikson y EE Grant. 1968. "Estudios experimentales exploratorios que comparan el rendimiento de programación en línea y sin conexión" Comunicaciones de la ACM 11, no. 1 (enero): 3-11.

Valett, J. y FE McGarry. 1989. "Un resumen de las experiencias de medición de software en el laboratorio de ingeniería de software". Revista de Sistemas y Software 9, no. 2 (febrero): 137-48.

Weinberg, Gerald M. y Edward L. Schulman. 1974. "Objetivos y rendimiento en la programación de computadoras". Factores humanos 16, no. 1 (febrero): 70-77.

Un programador realmente terrible puede tener una productividad bajo cero (los errores que introducen tardan más en solucionarse de lo que se necesitaría para hacer todo su trabajo por ellos).

Y un programador genuinamente excelente puede hacer cosas que los programadores pobres y promedio simplemente nunca lograrían, sin importar cuánto tiempo les dedique.

Por estas razones, es difícil hablar de "10 veces más productivo" o "100 veces más productivo".

Sin embargo, lo que hay que recordar es que la mayoría de los empleadores de programadores no tienen ninguna necesidad de que realicen las tareas difíciles que los programadores promedio no podían manejar. La mayoría del código que se está escribiendo son sitios web, aplicaciones de línea de negocios, aplicaciones de intranet, etc., gran parte de lo cual no es tan difícil. El programador productivo en ese entorno es el que mejor comprende e implementa las necesidades de los usuarios, no el que puede escribir el código más inteligente.

De hecho, la mayoría de los empleadores de programadores estarían mejor con un buen programador que con uno excelente, porque el excelente simplemente se aburrirá y se irá. Tengo que encontrar una buena combinación entre programadores y trabajos.

Hechos y Falacias de los estados de Ingeniería de Software (Hecho 2, disponible en la vista previa de Amazon):

Los mejores programadores son hasta 28 veces mejores que los peores programadores, según la investigación de "diferencias individuales". Dado que su paga nunca es proporcional, son las mayores gangas en el campo del software.

(mira la lista de fuentes allí para la investigación)

Por supuesto, si compara la productividad de un no programador (o un programador muy malo) con el bueno (en términos de experiencia y conocimiento), la diferencia puede ser infinitamente grande ( n/0 == infinitypara cualquier positivo n), pero tampoco es justo ni una comparación sensata.

Su salario puede depender de múltiples factores (en orden aleatorio):

• Tecnologías utilizadas
• País / estado en el que trabaja
• Riqueza de la empresa
• Tipo de negocio de la empresa
• Número de desarrolladores en la empresa.
• ¿Cuánto tiempo trabajas en la empresa?
• Politicas de oficina

junto con tu personal ...

• productividad
• conocimientos y experiencia
• participación en el negocio de la empresa (para startups)
• habilidades de negociación
• atractivo sexual y habilidades, lol (bueno, la inteligencia es sexy)

Mi respuesta es "sí, pero tenga cuidado de cómo usa esa métrica".

Un programador que, digamos, funciona de manera óptima, es aquel que crea para la funcionalidad y causa menos errores que necesitan reparación que sus hermanos de bajo rendimiento. No me resultaría difícil creer que estas personas puedan rendir a 10 veces la productividad de los demás, particularmente cuando consideras que una sola elección buena o mala hecha en una hora puede tener fácilmente 10 horas de impacto, y los programadores hacen muchas de esas elecciones la mayoría de los días.

Pero...

Debes tener cuidado al medir esto. Realmente no confío en la mayoría de las mediciones de productividad, ya que he visto un sinfín de casos en los que casi todas las métricas conocidas no consideran algo que considero vital para la productividad del equipo. Por lo tanto, generalmente odio los números tan difíciles de "productividad". Aquí hay algunos ejemplos:

• Líneas de código (LOC): una métrica generalmente odiada, ya que un programador irreflexivo puede generar muchas líneas de código horribles, verbosas, ineficientes y difíciles de depurar, mientras que un buen programador crea unas pocas líneas de código elegantes, fáciles de corregir y raramente rotas. en más tiempo, pero que en general son una mejor opción.
• Errores generados y / o tiempo para corregir: todos generarán algunos errores, y a menudo los errores más caros se generan por una serie de malas decisiones para las cuales el generador del problema es simplemente el último en el efecto dominó. Además, sus grandes depuradores no siempre son sus grandes diseñadores: necesita ambos.
• Según casi cualquier métrica, hay grandes desarrolladores que son tan difíciles de tener en un equipo, que 1 desarrollador "superproductivo" alejará a 10 desarrolladores básicamente buenos y rara vez veo a alguien que pueda hacer todo bien, por lo que necesitaremos Más de 1 persona en el proyecto.
• No hay forma de dar cuenta fácilmente de esas personas maravillosas que ven los problemas antes de que se conviertan en serios y evitarlos, particularmente cuando el problema es una brecha en un proceso: CM defectuoso, construcción ineficiente, una brecha en las pruebas, una falla de seguridad. a menudo parece una gran pérdida de tiempo hasta que te das cuenta de que te salvan del desastre; no hay forma de medir eso.
• Además, hay personas que considero necesarias en un equipo de cierto tamaño que yo llamaría "constructores de cohesión": rara vez son la cima absoluta de la productividad, generalmente todavía están en el 20% superior y hacen el trabajo invaluable de ayudar a aumentar gente nueva, conectando los puntos y asegurándose de que se hagan las preguntas correctas y se mantenga informada a las personas correctas, escriben (¡sin preguntar!) la pieza clave de documentación a la que todos se refieren porque no es solo el documento correcto, sino se arma de la manera correcta. Si desea que 10 personas trabajen con la máxima eficiencia, absolutamente necesita una de estas personas y no la obtendrá si coloca a 10 súper desarrolladores en una habitación.

Muchos sistemas de medición han tratado de tener en cuenta estos factores, pero aún no he visto que haya uno que tenga en cuenta todos estos problemas, por lo que nunca estoy demasiado impresionado con factores como "un buen desarrollador es 10 veces más productivo que un mediocre "porque tengo que preguntarme si la métrica realmente representa todo el trabajo que se necesita para un producto continuo exitoso o un equipo exitoso y próspero.

Entonces mi gran advertencia es: ¿qué vas a hacer con esta métrica? Usaré algo como esto para tener en cuenta que las herramientas y el talento correctos pueden causar una gran diferencia en la forma en que se realiza el trabajo, pero si intenta optimizar a un equipo donde cada individuo produce 10 veces la producción "típica", está obligado a Un caso de frustración. Lo mejor es encontrar una manera de hacer que su equipo haga 2-3 veces lo que estaban haciendo antes trabajando juntos mejor.

En su libro The Leprechauns of Software Engineering , Laurent Bossavit describe la investigación del reclamo de productividad 10x. Descubrió que no hay números sólidos detrás de esto: la afirmación ha pasado de la especulación al "hecho establecido" por un juego telefónico de afirmaciones sucesivamente más concretas en citas. La publicación de blog que comprende el capítulo sobre el reclamo 10x, e incluye las citas y citas erróneas relevantes, es un hecho y un folklore en la ingeniería de software .

Lo que encontró es algo como esto: alguien en 1968 hizo un estudio comparando a las personas que resolvieron un problema de depuración en particular, y descubrió que algunos de ellos lo hicieron 10 veces más rápido que otros. De esto podríamos concluir que algunas personas son 10 veces mejores para resolver ese problema , o podríamos concluir que algunas personas tuvieron suerte o una gran variedad de cosas diferentes. Algunas personas optaron por citar esto como (todas estas son paráfrasis) "un estudio (Sackman et al, 1968) encontró que algunos programadores trabajan 10 veces más rápido que otros". Luego se convirtió en "los estudios han demostrado que los buenos programadores son 10 veces mejores que el promedio" y finalmente "es de conocimiento común que la productividad del programador varía en 10 veces entre los individuos". Luego, alguien recopila todas estas citas, citando erróneamente una fuente original decir "muchos investigadores creen ...".

Por supuesto, no sería un juego telefónico si solo cambiara la veracidad de la afirmación: el multiplicador también va a 11 y más .

" El programador productivo en ese entorno es el que mejor comprende e implementa las necesidades de los usuarios, no el que puede escribir el código más inteligente " . ( Respuesta de Carson63000 )

Ese punto clave junto con bethlakshmiLos puntos hacen un gran punto. Un gran desarrollador puede ser excelente en su única parte de la realidad, pero se separará pronto a medida que el mundo cambie. Ser capaz de mantenerse al día con las necesidades del negocio es mucho más importante que cualquier otra cosa. Al final del día, a menos que su negocio sea tecnología, al negocio no le importa la tecnología; Necesitan soluciones. Por lo tanto, ser excelente con los patrones de diseño no significa ponerse en cuclillas para los usuarios finales que solo necesitan un volcado de datos para mostrar en una página web. He visto a desarrolladores mediocres asegurarse un trabajo atendiendo a la empresa que los apoya, mientras que los grandes desarrolladores se aburren y se van en busca de un desafío interminable. Dependiendo de su organización y proyecto (s), es posible alimentar a estos desarrolladores hambrientos de desafíos, pero es probable que haya un momento en el que simplemente no ' No necesita esa cantidad de potencia de procesamiento. A estos desarrolladores no les gusta quedarse inactivos como un procesador. Se apagarán y se reiniciarán en otro lugar.

Por último, diré que está bien saber quiénes son sus artistas "clave", pero un "equipo" de desarrollo sigue siendo un equipo. Para reiterar bethlakshmi, " ¿qué vas a hacer con esta métrica?"Si necesita un equipo que se comporte como un equipo, no me enfocaría en las métricas como estas. Me daría cuenta de que incluso el jugador más pequeño sigue siendo una parte importante del equipo. Incluso con un 60% menos de la productividad de su clave jugador, ese jugador puede estar dando a su equipo algo que necesita. Descubra qué es e intente multiplicarlo. No queme a su jugador clave asumiendo que debe liderar el equipo, encuentre formas de multiplicar su producción también, contaminando a los otros jugadores con esa grandeza. Esto requiere un poco de creatividad, no solo números. Al final, puedes aprender que lo que hace que un buen programador no sea ese programador, podrían ser sus compañeros, sus oportunidades en el lugar de trabajo o incluso podrías ser tú.