¿Es el desarrollo de software de estilo estrella de rock sostenible o incluso saludable para la empresa y la industria?

Fred Brooks abordó esta pregunta en su importante libro The Mythical Man-Month , que es un relato de su experiencia en el desarrollo de IBM System / 360. Todos los involucrados en la gestión de proyectos de software deberían leerlo; está disponible gratuitamente en línea, por ejemplo aquí:
El mes del hombre mítico: Frederick Brooks: descarga y transmisión gratuitas: archivo de Internet

La posición de Brooks, que he comprobado que es cierta a través de la experiencia personal, es que el número mínimo de meses-hombre para un proyecto se logra con un equipo de desarrollo de ONE. Sin embargo, esto no produce resultados en el número mínimo de meses calendario . Reconoce que algunos programadores son mejores que otros …

En uno de sus estudios, Sackman, Erikson y Grant midieron el desempeño de un grupo de programadores experimentados. ¡Solo dentro de este grupo, las relaciones entre el mejor y el peor desempeño promediaron alrededor de 10: 1 en mediciones de productividad y un sorprendente 5: 1 en velocidad de programa y mediciones de espacio! ….. Los datos no mostraron correlación alguna entre la experiencia y el rendimiento.

La mayor parte del libro está relacionada con cómo obtener lo mejor de un equipo mixto, dado que las mejores personas son difíciles de encontrar y más difíciles de mantener, y la solución, respaldada por un razonamiento impecable, es que un equipo exitoso tiene una piedra estrella responsable de casi todas las especificaciones, programación y documentación, respaldada por un adjunto que también es muy bueno y un equipo de soporte de varios especialistas. El principal programador, arquitecto, o como se llame, es el responsable y todos los demás lo siguen.

La mayoría de las empresas para las que he trabajado no implementan ese tipo de estructura porque la administración administrativa no puede ceder el control ni aceptar un personal técnico que gane más dinero que ellos. Pero un hombre que realmente conoce sus cosas simplemente no tolerará tener que seguir órdenes que él sabe que están equivocadas. Luego se corre la voz de que las estrellas de rock son imbéciles egoístas que no pueden ser manejados, cuando en realidad son los gerentes quienes son los imbéciles, cargados de inseguridad crónica y el temor de que alguien sepa mejor que ellos y les haga quedar mal. a sus propios superiores. Este es un peligro particular cuando el gerente ha sido promovido fuera de la ingeniería; Los ingenieros solo son promovidos a la gerencia porque se pueden salvar.

Hay estrella de rock, y hay estrella de rock.

• He trabajado en un entorno donde algunos de los propietarios-desarrolladores fueron “estrellas de rock” hasta el punto de tener equipos de filmación, periodistas impresos o visitantes famosos en la oficina al menos una vez al mes.
• También trabajé en un entorno donde la “estrella del rock” era una prima donna que solo hacía ciertos tipos de trabajo, no documentaba nada, se deleitaba en hacer que otras personas se sintieran estúpidas y representaba un solo punto de falla en la organización – Sin embargo, fue percibido por la gerencia como “demasiado grande para fallar”.
• Y he trabajado en un entorno en el que había uno o más programadores de “estrellas de rock” muy, muy efectivos que superaron a todos los demás en ciertas tareas, pero también mejoraron a todos los demás; sin embargo, se aburrieron, y cuando se dieron cuenta de que no había nadie mejor que ellos en la organización para aprender, se fueron.

No creo que términos como “estrella de rock” o “ninja” o “programador 10x” sean sostenibles o saludables para una empresa o para la industria. Hay un equipo Tiene que funcionar como un equipo. Que el equipo funcione bien es más importante para mí que la productividad individual de un experto.

Tomaré el punto de vista contrario. Claro, las estrellas de rock son difíciles de encontrar y relativamente difíciles de manejar; También cuestan más. Pero una estrella real es mucho más productiva, a veces hasta en dos órdenes de magnitud, que vale la pena. En cuanto a integrarlo en un equipo de personas menos capaces, mi experiencia personal ha sido que la estrella a menudo es mucho más productiva que otras que no necesita el resto del equipo de desarrollo, excepto quizás una segunda estrella para evitar problemas de sensibilidad de un solo punto. (Por cierto, he descubierto que dos estrellas reales funcionan bien juntas debido a su respeto mutuo).

La razón por la que existen programadores de estrellas de rock se debe a la gran brecha entre los programadores talentosos con claridad real y la mayoría que son programadores de bajo grado. Solo necesita una experiencia mínima para entrevistar a los desarrolladores y trabajar en equipos medianos y grandes para ver esto.

La gente se queja de las cualidades tipo “diva” de estas “estrellas” de alta gama y dice que crea cuellos de botella, pero para resolver el problema, creo que la capacidad promedio en TI debe aumentar significativamente, de lo contrario, ¡las estrellas de rock continuarán controlando!

El problema que veo con las estrellas de rock es, como las estrellas de rock “reales”, se consideran artistas y están motivados por el ego.

Entonces, si les das un proyecto que les gusta, les irá bien o incluso se esforzarán demasiado, pero si les das un proyecto poco interesante o algo de lo que no aprenderán, no lo harán y encontrarán alguna excusa.

Justo lo contrario de:
¿Qué es la profesionalidad para los programadores?

El problema con el desarrollo al estilo de las estrellas de rock es que no hay tantas “estrellas de rock” … y la mayoría de ellas no van a funcionar para usted, y el resto podría hacerlo, pero van a comandar un fuerte prima.

En lugar de hacer todo lo posible para atraer a una “estrella de rock”, lo mejor sería atraer a varias personas que sean desarrolladores experimentados y competentes, pero no necesariamente “estrellas de rock”. Luego, a medida que crecen las necesidades del equipo, traiga a los menos experimentados que puedan ser instruidos en su cultura de desarrollo general por el “cuadro” que ya tiene. Ellos, a su vez, se convertirán en desarrolladores experimentados que instruirán a la próxima “clase” entrante, y así sucesivamente.

Más honestamente que el simple talento de “estrella de rock”, honestamente, es la flexibilidad y una base sólida en los fundamentos del arte y la ciencia del desarrollo de software. Un desarrollador que tenga esas cualidades no necesita ser un “especialista” en cualquier idioma o kit de herramientas que esté utilizando; podrán aprenderlo fácilmente. Un desarrollador que no tiene esas cualidades puede ser muy bueno en el lenguaje y el entorno específicos que ha aprendido, pero trate de moverlos más allá de eso y se agitarán como un rango n00b. Y probablemente se perderán algunos trucos incluso en el idioma y el entorno que conocen. (Es por eso que Google pone tanto énfasis en cosas como algoritmos básicos y análisis Big-O de ellos durante su proceso de entrevista, por ejemplo).

Sin embargo, es una buena idea hacer que su entorno de trabajo sea el tipo de entorno en el que las estrellas de rock querrán trabajar. Esto no solo lo ayudará a atraer una estrella de rock si decide buscar una de todos modos, sino que también lo ayudará. atraer desarrolladores competentes de todas las franjas. (Puede atraer a más desarrolladores en general de esta manera … solo asegúrese de tener los medios a mano para separar a los competentes y eliminar a los incompetentes durante el proceso de entrevista).

Punta de sombrero: Aryeh Friedman para la A2A.

La limitación clave es el número y la calidad de groupies que puede suministrar.

No, a menos que sus inversores / clientes insistan en la última moda tecnológica en lugar de soluciones sólidas bien implementadas.

No sostenible Las organizaciones de software deben hacer un esfuerzo para difundir dicho trabajo y conocimiento, en lugar de crear cuellos de botella. Si la gerencia es consciente de la situación, deberían estar haciendo exactamente eso.

Peor aún, si pierdes a la estrella de rock, pasas de un cuello de botella a un equipo roto. Después de eso, todo el conocimiento necesita ser reconstruido sin la ayuda del desarrollador original del cuello de botella, que puede ser difícil y costoso.

Creo que Jeff Nelson hace un muy buen punto, está muy bien tener un desarrollador de ‘estrella de rock’, pero ¿sucede si esa persona decide irse?

Creo que para mucho desarrollo de software, las estrellas de rock no solo son deseables, son esenciales . Google tiene decenas de miles de desarrolladores, pueden permitirse que el estándar general no sea especialmente alto. No digo que el estándar no sea alto, digo que es menos importante que sea alto.

No todas las empresas pueden pagar decenas de miles de desarrolladores, muchos no pueden pagar 10. Muchos pueden pagar menos que eso. Si solo puede pagar un desarrollador, será mejor que sea uno bueno, o si está gastando dinero que no puede pagar en alguien que no está resolviendo sus problemas.

A veces, la única forma de hacer algo es un montón de habilidades envueltas en una persona, pero es un peligro a largo plazo si esa persona decide irse.

No. Por ejemplo, esto existe en la industria del juego que no es muy estable. Asumir que un único desarrollador o conjunto de desarrolladores es muy superior a otros desarrolladores es defectuoso y una posición peligrosa. Lo vi personalmente en la industria de los videojuegos a principios de los 80. Choque y quema para los inversores.