Desde que estoy en el mundo del software, se habla del desarrollador 10x. Son las personas que quieres que resuelvan tus problemas; lo harán en una décima parte del tiempo, con una décima parte del número de líneas de código. Suenan increíbles.
¿Pero de dónde viene el término? ¿Existen? E incluso si existen, ¿querrías ser uno de ellos?
Tom DeMarco y Tim Lister han llevado a cabo, desde 1977, los «Coding War Games». Se trata de una encuesta pública de productividad en la que equipos de implementadores de software de diferentes organizaciones compiten para completar una serie de puntos de referencia en un tiempo mínimo y con un mínimo de defectos. Participaron más de 600 desarrolladores.
¿Qué aprendieron?
- La elección del lenguaje de programación tuvo poco impacto – ya sea COBOL/Fortran o un lenguaje de alto nivel como Pascal la dispersión de los resultados es casi la misma. La única excepción fue el lenguaje ensamblador.
- No hubo correlación entre la experiencia y el rendimiento, salvo que aquellos con menos de seis meses de experiencia con un lenguaje no lo hicieron tan bien como los demás.
- Los desarrolladores de soluciones con cero defectos no pagaron ninguna penalización de rendimiento por hacer un trabajo más preciso (de hecho, ¡tomaron un poco menos de tiempo!).
Sí encontraron que había enormes diferencias entre las organizaciones. La mejor organización trabajó 11,1 veces más rápido que la peor. Además, las que trabajaron más rápido desarrollaron un código que pasó la prueba de aceptación. ¿Caso cerrado?
Bueno, no del todo. El estudio pasa a correlacionar el entorno de trabajo (que es diferente en cada organización) con el rendimiento. Resulta que el grupo con un espacio de trabajo tranquilo, privado y dedicado tuvo un rendimiento significativamente mejor.
Lección aprendida: ¡consigue primero un entorno de trabajo adecuado antes de empezar a preocuparte por si puedes encontrar 10x desarrolladores o no!
El programador de producción neta negativa
Schulmeyer observa que algunos desarrolladores son «programadores de producción neta negativa» (NNPP), es decir, que producen tantos defectos que eliminarlos del equipo aumenta la productividad. Esto es casi lo contrario del desarrollador 10x – es posible tener a alguien en el equipo que lo empeore.
Si existen productores negativos (¿desarrolladores Nx?) entonces es claramente posible tener un desarrollador 10x (matemáticas aparte).
Sin embargo, no es el mejor argumento para el programador 10x, ¿verdad? Si le pidiera a un niño de la escuela que se uniera a un equipo, ¿sería un productor neto negativo? Probablemente, si les dejara sentarse en un rincón y machacar algo de código (¡y si de alguna manera pueden pasar a producción!). ¡Si eres el tipo de empresa que deja que la gente se siente en un rincón, no da feedback y les deja empujar a la producción, entonces creo que probablemente mereces tener NNPPs en tu equipo!
Más realista, espero que en cualquier empresa normal, si se contrata a alguien, se le dará todo el apoyo que necesita para ser impresionante en su papel (revisión de código por pares, retroalimentación, un mentor, análisis de código automatizado para la retroalimentación, materiales de aprendizaje, etc.)
Supongo que todavía es posible que usted podría terminar con un NNPP, pero sospecho que es muy poco probable. Desde luego no parece la mejor historia para la existencia de desarrolladores 10x.
Estudios experimentales exploratorios que comparan el rendimiento de la programación online y offline
Sackman, Erikson, Grant publicaron un artículo en 1968 llamado «Exploratory experimental studies comparing online and offline programming performance». Una de las citas al final es sobre las diferencias individuales y los estudios «revelaron grandes diferencias individuales entre el alto y el bajo rendimiento, a menudo por un orden de magnitud». ¿Podría ser este el documento mágico que describe esa diferencia de 10x?
Vale la pena leer el estudio completo y poner un poco de contexto alrededor de esto. En primer lugar, estas pruebas comparaban tanto el rendimiento en papel y lápiz como en línea utilizando un IBM AN/FSQ-32. Los programadores escribieron su código (bien en lápiz/papel para dárselo a un operador, bien directamente en el ordenador) utilizando un lenguaje llamado JTS (un derivado de ALGOL).
Tenían que resolver dos tareas, la primera era interpretar ecuaciones algebraicas con una única variable dependiente. Se les dio el documento de Samelson y Bauer para ayudar a implementar la solución. Una imagen del documento se muestra a continuación:
La segunda tarea era resolver un laberinto de 20×20 que tiene exactamente un camino. El laberinto estaba descrito por una tabla de búsqueda de 400 elementos donde cada entrada contenía información de las salidas de cada celda. No se proporcionó ningún material de apoyo para este reto. La resolución de laberintos es un espacio de problemas fascinante y supongo que aquellos que habían realizado un curso de teoría de grafos recientemente tenían una gran ventaja.
Conociendo estas tareas, no me sorprende que haya grandes diferencias individuales. En 1968, la ingeniería del software acababa de nacer como disciplina. Las tareas son de naturaleza matemática y no está claro cuál era la formación de los participantes. Sin duda, favorecería a los que tomaron cursos de matemáticas de nivel superior.
Creo que la persona 10x que encontrarías de esto es dotada para resolver estos problemas. Puedo creer que en el espacio de problemas de «resolver un laberinto + ecuaciones lineales» puede haber un desarrollador 10x, pero es difícil que esto se traslade a cualquier otro dominio.
¿Debería ser un desarrollador 10x?
Probablemente. Pero probablemente 10 veces mejor escribiendo código.
Hay una discusión mucho mejor de las metodologías de investigación detrás del mito del desarrollador 10x en este excelente libro. Incluso si un desarrollador 10x existe, probablemente no deberías aspirar a ser uno; incluso si puedes implementar el código perfectamente a la primera, probablemente descubrirás que estabas resolviendo el problema equivocado en primer lugar.
Incluso si esos estudios fueran ciertos, la ingeniería de software ha avanzado (al menos en mi dominio de desarrollo de productos).
En los viejos tiempos, podríamos hacer una sola gran versión al año, tener algunos requisitos y pasar el año implementándolos. Esto ha cambiado a un enfoque ágil en el que hay un ciclo continuo de elicitar, imaginar, implementar y verificar. En este modelo, la implementación no es (normalmente) el cuello de botella
Una hora ahorrada en el cuello de botella no es un espejismo. (Eliyahu Goldratt)
Entonces, ¿qué deberías hacer en su lugar? Pues centrarse en ser más valioso para su negocio. ¿Puedes:
- Identificar problemas valiosos para tu negocio?
- Diseñar una solución que la gente pueda utilizar?
- Recoger opiniones para evaluar si es valiosa?
- Escribir un software que suponga una diferencia real para personas reales?
- ¿Centrarse en los problemas reales en lugar de en lo interesante?
- ¿Crecer a los miembros del equipo para que sean increíbles?
Y un millón y una de cosas que son más valiosas que escribir un código perfecto en un tiempo récord (¡ver forma de t!).
Esto no quiere decir que la codificación no sea importante. ¡La codificación es importante! El código se lee 4 veces más de lo que se escribe, así que si escribes código fácil de razonar, entonces se paga dramáticamente en el futuro (tal vez hay una historia de 10x en alguna parte, pero lo dejaré para otro día). Invertir tiempo en tu arte (ya sea codificación o diseño o gestión de proyectos) es una necesidad, pero recuerda que tu arte no existe de forma aislada y existe para servir a un objetivo superior.
No te centres sólo en ser el mejor desarrollador del mundo, céntrate en el panorama general (¡recuerda Producto sobre Proyecto!). Aprende un amplio conjunto de habilidades (especialmente las relacionadas con las personas) y serás mucho más valioso y mucho más cerca de un verdadero «desarrollador» 10x.