El desarrollador "estrella del rock" 10X NO es un mito
Menú de navegaciónMenú
Categorías

La mejor forma de Aprender Programación online y en español www.campusmvp.es

El desarrollador "estrella del rock" 10X NO es un mito

Estrella del rock - Imagen Ornamental

Este artículo es una traducción del original de Yevgeniy Brikman, realizada con su permiso. El énfasis es nuestro. La imagen de portada es CC0, obtenida aquí.

Ayer por la noche publiqué este tweet:

Recibí muchísimas respuestas y preguntas, pero Twitter es un medio horrible para el debate, así que retomo el tema por medio de esta entrada en el blog.

Se han escrito un montón de artículos que sostienen que el desarrollador "10x" o "estrella del rock" no existe. Los argumentos en contra normalmente se pueden clasificar en tres grupos:

  • El número x10 original vino de un único estudio (Sackman, Erikson, and Grant (1968)) que está errado.
  • La productividad es un concepto difuso que es muy difícil de medir, así que mejor no hacer teorías como la de x10.
  • El talento está distribuido de forma desigual, pero de ninguna manera puede un solo ingeniero hacer el trabajo de 10.

Yo estoy en desacuerdo con todas estas. Repasemos estos argumentos uno a uno.

No hay solo un estudio

Aunque a muchos científicos de sofá en Twitter y Hacker News les encanta desmontar los estudios con revisión por pares (peer-reviewed), en este caso las pruebas son bastante convincentes y no se basan en un único estudio. Voy a citar la respuesta más valorada en StackOverflow en relación con este debate:

...El estudio original que halló enormes variaciones en la productividad de programación entre individuos fue llevado a cabo a finales de los años 60 por Sackman, Erikson, y Grant (1968). Tomaron como muestra a programadores profesionales con una media de 7 años de experiencia y vieron que el ratio en tiempos de programación entre los mejores y los peores programadores era de 20 to 1; el ratio en tiempo de corrección de errores era de 25 to 1; el del tamaño del programa de 5 a 1; y el de velocidad de ejecución de programa era de 10 a 1. No hallaron ninguna relación entre la cantidad de experiencia del programador con la calidad del código o la productividad.

Un análisis pormenorizado de los hallazgos de Sackman, Erickson, y Grant muestran algunos defectos en su metodología... Sin embargo, incluso tras tener en cuenta dichos defectos, el estudio muestra que hay una diferencia de x10 entre los mejores y los peores programadores.

Años después del estudio original, la conclusión general de que hay "diferencias de orden de magnitud entre programadores" ha sido ratificada por muchos otros estudios sobre programadores profesionales (Curtis 1981, Mills 1983, DeMarco y Lister 1985, Curtis et al. 1986, Card 1987, Boehm y Papaccio 1988, Valett y McGarry 1989, Boehm et al 2000)...

Puedes leer más aquí y aquí.

Cuando no lo puedes medir, al menos puedes argumentar razonadamente

Incluso si ignoras los estudios mencionados arriba y sostienes que la productividad en programación es difícil de medir -que lo es- podemos aún así debatir sobre los programadores x10. Porque algo sea difícil de medir no significa que no podamos razonarlo.

Por ejemplo, ¿cómo elegiste el lenguaje de programación para tu proyecto más reciente? ¿Buscaste un estudio que "demuestra" que el lenguaje es más efectivo que otras alternativas? Personalmente, no necesito un experimento para concluir que Ruby será una elección un orden de magnitud más productivo para crear una página web que, digamos, C. Podrías juntar grosso modo cuatro métricas (disponibilidad de bibliotecas, el peso de la comunidad, documentación, etc...), pero la realidad es que la mayoría de las personas toman estas decisiones basándose en un razonamiento intuitivo y no en un estudio exhaustivo. A pesar de que no hay datos concluyentes, apostaría que elegir Ruby sobre C para el desarrollo de páginas web resulta ser la mejor decisión en la mayoría de los casos.

Por supuesto, esto no solo se puede aplicar a la programación: ¿qué "métrica" te puede indicar que un escritor, artista, profesor o filósofo es mejor que otro? Simplemente observándolos, no puedo dar una "métrica de productividad" que sugiera que Shakespeare, Nabokov, o Orwell fueron un orden de magnitud mejor que el escritor medio, pero una amplia mayoría de personas estarían de acuerdo en que lo son.

La programación no es un trabajo manual

El mayor problema de los argumentos que niegan la existencia de programadores x10 es que algunas personas se creen que la programación es un trabajo manual y que los programadores son trabajadores en una cadena de montaje. Algunos programadores son un poco mejores que otros, pero, por supuesto, ¡un solo programador no puede de manera regular cerrar 10 veces más incidencias que otro! y ¡un equipo de diez programadores siempre rendirá más que un único programador! Nueve mujeres no pueden dar a luz a un bebé en 1 mes...

La lógica mencionada arriba hace parecer que la productividad en programación versa sobre la velocidad con las teclas; como si el programador x10 es simplemente el que produce diez veces más código que el programador medio. Esta línea de razonamiento ignora que la programación es un trabajo creativo y no manual: hay muchísimas formas de solucionar un mismo problema. En vez de la analogía del bebé, piensa más en una analogía de la resolución de un crimen: diez investigadores medios contra un Sherlock Holmes. ¿Quién resolverá el crimen antes?

Un desarrollador x10 tiene ideas y encuentra soluciones que nunca se le ocurrirían a un programador medio; evitarán toda una serie de problemas que le comen el tiempo al programador medio. Diez ingenieros picando el código equivocado pueden ser claramente superados por uno solo que escribe el código apropiado.

En programación hay que saber elegir bien

Piensa en todas las decisiones que hay que tomar a la hora de crear un producto de software, como por ejemplo una página web: ¿qué lenguaje de programación usas? ¿qué frameworks web usas? ¿cómo almacenas los datos? ¿dónde la alojas? ¿cómo la monitorizas? ¿cómo introduces mejoras? ¿cómo guardas código nuevo? ¿qué tipo de testeo automatizado configuras?

Diez programadores medios tomarán decisiones de calidad media en cada paso del proceso y los costes o los beneficios de estas decisiones se multiplicarán. Imagina que el tráfico aumenta de forma exponencial, y este equipo medio monta una web media, con un motor de almacenamiento de datos que es difícil de fragmentar, un alojamiento que no tiene suficiente redundancia, control de versiones sin copias de seguridad bien implementadas, sin entorno CI, y sin monitorización. ¿Cuán productivos serán esos diez programadores si se pasan el día apagando fuegos?

Un solo programador puede rendir más que este equipo de 10 si es capaz de modelar el problema y la solución de forma que hay menos trabajo que hacer en un orden de magnitud. Tras años de experiencia, un gran programador sabrá que los errores son una lacra de muy difícil solución a posteriori. Tomando buenas decisiones al principio, un programador x10 puede evitar meses de trabajo a la larga.

No se trata de escribir más código: se trata de escribir el código apropiado. No te conviertes en programador x10 haciendo más trabajo en un orden de magnitud, sino tomando mejores decisiones y más a menudo en un orden de magnitud.

Esto no quiere decir que los programadores x10 no cometan errores nunca; pero los programadores toman un gran número de decisiones al día y los grandes programadores toman mejores decisiones con mucha más frecuencia que los programadores medios.

Esto no solo es aplicable a la programación. ¿Preferirías tener diez científicos medios o un Isaac Newton? Diez científicos medios no idearon las leyes del movimiento, la teoría de la gravedad, las series binomiales, cálculo, etc... Fue un único Isaac Newton. ¿Prefieres tener a un Michael Jordan en tu equipo o diez jugadores medios? (nota: Jordan cobraba ~x10 el salario medio de la NBA). ¿Preferías que Steve Jobs o Elon Musk dirigieran una empresa o dejarla en manos de diez emprendedores medios?

Los programadores x10 son una especie poco común

Superman - OrnamentalImagen por Kooroshication CC-BY

Es importante poner las cosas en perspectiva. Los programadores estrella, al igual que los atletas, escritores o científicos estrella, son extremadamente poco comunes. No aconsejaría montar una política de contratación solo de estrellas del rock; te acabarías encontrando solo y sintiendo tonto. No dejes que lo perfecto sea enemigo de lo bueno: contrata a los mejores programadores que puedas y dales abundantes oportunidades para desarrollarse y mejorar.

No obstante, no caigas en la farsa de que todos los programadores son iguales. Hay un gran espectro de destrezas en cualquier profesión creativa. Por un lado están los tipos de contrataciones que pueden hundir cualquier empresa, activamente incrementando la deuda tecnológica con cada línea que pican. Y por el otro están las personas que pueden escribir código que cambia lo que antes era imposible y que tiene un impacto que es un orden de magnitud mayor que la media.

campusMVP campusMVP es la mejor forma de aprender a programar online y en español. En nuestros cursos solamente encontrarás contenidos propios de alta calidad (teoría+vídeos+prácticas) creados y tutelados por los principales expertos del sector. Nosotros vamos mucho más allá de una simple colección de vídeos colgados en Internet porque nuestro principal objetivo es que tú aprendas. Ver todos los posts de campusMVP

No te pierdas ningún post

Únete gratis a nuestro canal en Telegram y te avisaremos en el momento en el que publiquemos uno nuevo.

Archivado en: DevFacts

Agregar comentario