Ingeniería de Software de Culto de Carga
En los Mares del Sur hay un culto de carga de personas. Durante la guerra vieron aviones con muchos materiales buenos, y quieren que pase lo mismo ahora. Así que se han arreglado para hacer cosas como pistas de aterrizaje, para poner fuegos a los lados de las pistas, para hacer una cabaña de madera para que un hombre se siente, con dos piezas de madera en la cabeza para auriculares y barras de bambú sobresaliendo como antenas—él es el controlador—y esperan a que aterricen los aviones. Están haciendo todo bien. La forma es perfecta. Se ve exactamente como se veía antes. Pero no funciona. No aterrizan aviones. Así que a estas cosas las llamo ciencia de culto de carga, porque siguen todos los aparentes preceptos y formas de investigación científica, pero les falta algo esencial, porque los aviones no aterrizan.
– Richard Feynman
Encuentro útil establecer un contraste entre dos estilos de desarrollo organizacional diferentes: el desarrollo “orientado a procesos” y el “orientado al compromiso”. El desarrollo orientado a procesos logra su efectividad a través de una planificación hábil, el uso de procesos cuidadosamente definidos, el uso eficiente del tiempo disponible y la aplicación hábil de las mejores prácticas de ingeniería de software. Este estilo de desarrollo tiene éxito porque la organización que lo utiliza está mejorando constantemente. Incluso si sus primeros intentos son ineficaces, la atención constante al proceso significa que cada intento sucesivo funcionará mejor que el intento anterior.
El desarrollo orientado al compromiso recibe varios nombres, incluidos “desarrollo orientado al héroe” y “empoderamiento individual”.”Las organizaciones orientadas al compromiso se caracterizan por contratar a las mejores personas posibles, pedirles un compromiso total con sus proyectos, empoderarlas con una autonomía casi completa, motivarlas en un grado extremo y luego ver que trabajan 60, 80 o 100 horas a la semana hasta que el proyecto está terminado. El desarrollo orientado al compromiso deriva su potencia de su tremenda capacidad de motivación-estudio tras estudio ha encontrado que la motivación individual es, con mucho, el mayor contribuyente individual a la productividad. Los desarrolladores hacen compromisos voluntarios y personales con los proyectos en los que trabajan, y a menudo hacen todo lo posible para que sus proyectos tengan éxito.
Impostores organizacionales
Cuando se usan con conocimiento, cualquiera de los estilos de desarrollo puede producir software de alta calidad de manera económica y rápida. Pero ambos estilos de desarrollo tienen aspectos patológicos que no funcionan tan bien, y que pueden ser difíciles de distinguir de los artículos genuinos.
La organización impostora de procesos basa sus prácticas en una devoción servil al proceso por el proceso. Estas organizaciones miran a organizaciones orientadas a procesos como el Laboratorio de Ingeniería de Software de la NASA y la antigua División Federal de Sistemas de IBM. Observan que esas organizaciones generan muchos documentos y celebran reuniones frecuentes. Llegan a la conclusión de que, si generan un número equivalente de documentos y celebran un número comparable de reuniones, tendrán un éxito similar. Si generan más documentación y celebran más reuniones, ¡tendrán aún más éxito! Pero no entienden que la documentación y las reuniones no son responsables del éxito; son los efectos secundarios de unos pocos procesos efectivos específicos. Llamamos a estas organizaciones burocráticas porque ponen la forma de los procesos de software por encima de la sustancia. Su mal uso del proceso es desmotivador, lo que perjudica la productividad. Y no es muy agradable trabajar para ellos.
La organización de impostores de compromiso se centra principalmente en motivar a las personas a trabajar largas horas. Estas organizaciones miran a compañías exitosas como Microsoft; observan que generan muy poca documentación; ofrecen opciones de acciones a sus empleados; y luego exigirles que trabajen montañas de horas extras. Concluyen que si también minimizan la documentación, ofrecen opciones de compra de acciones y requieren largas horas extras, tendrán éxito. Cuanto menos documentación y más horas extras, mejor! Pero estas organizaciones pierden de vista el hecho de que Microsoft y otras empresas exitosas orientadas al compromiso no requieren horas extras. Contratan a gente que ama crear software. Combinan a estas personas con otras personas a las que les encanta crear software tanto como a ellos. Proporcionan un generoso apoyo organizacional y recompensas por crear software. Y luego los sueltan. El resultado natural es que los desarrolladores y gerentes de software eligen trabajar largas horas voluntariamente. Las organizaciones impostoras confunden el efecto (largas horas) con la causa (alta motivación). Llamamos maquiladoras a las organizaciones impostoras porque enfatizan el trabajo duro en lugar de trabajar de manera inteligente, y tienden a ser caóticas e ineficaces. Tampoco es muy agradable trabajar para ellos.
Ingeniería de Software de culto de carga
A primera vista, estos dos tipos de organizaciones impostoras parecen ser exactamente opuestos. Uno es increíblemente burocrático, y el otro es increíblemente caótico. Pero una similitud clave es en realidad más importante que sus diferencias superficiales. Ninguno de los dos es muy efectivo, y la razón es que ninguno entiende lo que realmente hace que sus proyectos tengan éxito o fracasen. Pasan por los movimientos de verse como organizaciones efectivas que son estilísticamente similares. Pero sin una comprensión real de por qué funcionan las prácticas, esencialmente solo se pegan trozos de bambú en las orejas y esperan que sus proyectos aterricen de manera segura. Muchos de sus proyectos terminan fallando porque son solo dos variedades diferentes de ingeniería de software de culto de carga, similares en su falta de comprensión de lo que hace que los proyectos de software funcionen.
La ingeniería de software de culto de carga es fácil de identificar. Los ingenieros de software de Cargo cult justifican sus prácticas diciendo: “Siempre lo hemos hecho de esta manera en el pasado” o “los estándares de nuestra empresa nos exigen que lo hagamos de esta manera”, incluso cuando esas formas no tienen sentido. Se niegan a reconocer las compensaciones que entraña un desarrollo orientado a los procesos o a los compromisos. Ambos tienen fortalezas y debilidades. Cuando se les presentan prácticas nuevas y más efectivas, los ingenieros de software de cargo cult prefieren permanecer en sus cabañas de madera con hábitos de trabajo familiares, cómodos y no necesariamente efectivos. “Hacer lo mismo una y otra vez y esperar resultados diferentes es un signo de locura”, dice el viejo refrán. También es un signo de ingeniería de software de culto a la carga.
El verdadero Debate
En esta revista y en muchas otras publicaciones, pasamos nuestro tiempo debatiendo si el proceso es bueno o si el empoderamiento individual (en otras palabras, el desarrollo orientado al compromiso) podría ser mejor. Esta es una falsa dicotomía. El proceso es bueno, y también lo es el empoderamiento individual. Los dos pueden existir uno al lado del otro. Las organizaciones orientadas a los procesos pueden pedir un compromiso extremo en proyectos específicos. Las organizaciones orientadas al compromiso pueden utilizar las prácticas de ingeniería de software con habilidad.
La diferencia entre estos dos enfoques realmente se reduce a diferencias de estilo y personalidad. He trabajado en varios proyectos de cada estilo, y me han gustado diferentes cosas de cada estilo. Algunos desarrolladores disfrutan trabajando metódicamente en un horario de 8 a 5, que es más común en empresas orientadas a procesos. Otros desarrolladores disfrutan del enfoque y la emoción que conlleva hacer un compromiso 24×7 con un proyecto. Los proyectos orientados al compromiso son más emocionantes en promedio, pero un proyecto orientado al proceso puede ser igual de emocionante cuando tiene una misión bien definida e inspiradora. Las organizaciones orientadas al proceso parecen degenerar en sus parecidos patológicos con menos frecuencia que las organizaciones orientadas al compromiso, pero cualquiera de los estilos puede funcionar bien si se planifica y ejecuta hábilmente.
El hecho de que tanto los proyectos orientados al proceso como los orientados al compromiso tengan aspectos patológicos ha enturbiado el debate. Algunos proyectos realizados en cada estilo tienen éxito, y otros fracasan. Eso permite que un defensor del proceso señale el éxito del proceso y los fracasos del compromiso y afirme que el proceso es la clave del éxito. Permite que el defensor del compromiso haga lo mismo.
El tema que se ha quedado en el camino mientras hemos estado debatiendo el proceso vs. el compromiso es tan evidente que, al igual que la carta robada de Edgar Allen Poe, puede haber sido simplemente tan obvio que lo hemos pasado por alto. No deberíamos debatir el proceso frente al compromiso; deberíamos debatir la competencia frente a la incompetencia. La verdadera diferencia no es qué estilo se elige, sino qué educación, capacitación y comprensión se aplican al proyecto. En lugar de debatir el proceso frente al compromiso, deberíamos buscar formas de aumentar el nivel promedio de competencia de desarrolladores y gerentes. Eso mejorará nuestras posibilidades de éxito, independientemente del estilo de desarrollo que elijamos.
