Fred Brooks murió el mes pasado a la edad de 91 años. A través de su libro de gestión de desarrollo de software más vendido, The Mythical Man-Month Essays on Software Engineering, se convirtió en una leyenda de la programación y la gestión.

A lo largo de las décadas, he conocido a muchos líderes tecnológicos, pero pocos fueron tan impresionantes como Brooks. Si bien lo he visto muchas veces en eventos, solo hablé con él una vez cuando era presidente del departamento de informática de la Universidad de Carolina del Norte.

Algunos líderes tecnológicos, como Steve Jobs, muestran su genio como una nova. Otros, como Brooks, son tranquilos, ingeniosos e igual de brillantes a su manera.

Incluso sin el libro, Brooks sería famoso en la historia de la informática por ser uno de los líderes en desarrollar un sistema operativo que podría usarse en más de una arquitectura de computadora: OS/360.IBM.

Assembler 360 resultó ser mi primer lenguaje de programación. Advertencia justa: el lenguaje en primera persona no debe ser IBM 360 Assembler.

En cuanto al lenguaje de control de trabajos 360 (JCL), supe al mismo tiempo que el propio Brooks lo llamó «el peor lenguaje de programación informático jamás ideado por nadie, en cualquier lugar». Solo diré que hubo «razones» por las que cambié de mainframes a mini computadoras Unix.

Personalmente, sin embargo, Brooks señaló: «La decisión más importante que tomé fue cambiar la serie IBM 360 de un byte de 6 bits a un byte de 8 bits, lo que permitió el uso de letras minúsculas. Este cambio se ha extendido por todas partes».

Si, es verdad. Las arquitecturas informáticas de 8 bits, 16 bits, 32 bits y 64 bits con las que todos crecimos comenzaron con Brooks.

Diablos, la misma palabra «arquitectura» para chips y diseños de computadora proviene de él.

Pero lo que la mayoría de nosotros recordamos es su libro, con sus concisas declaraciones de gestión. Ahora, ¡si los usáramos más en nuestras oficinas!

Comencemos con el más conocido de estos: Ley de Brooks: «Agregar mano de obra a un proyecto de software atrasado lo hace atrasado».

Una y otra vez veo empresas que arruinan este.

La mayoría de las veces en estos días, este error se manifiesta al insistir en que, oh, digamos, todos los desarrolladores se presenten en la oficina el viernes por la tarde para justificar su trabajo y trabajar en un sprint. Sí, de hecho, estoy pensando en Elon Musk y Twitter.

Pero no es solo Musk. Si en tu negocio siempre terminas dedicando un montón de horas extras al final de cualquier proyecto para sacarlos adelante, estás equivocado. Por supuesto, a veces es necesario; pero si se ha convertido en un hábito, tienes un problema de gestión.

Un Brooksismo relacionado es que «nueve mujeres no pueden tener un bebé en un mes». O, al hacerse cargo de Musk, tampoco puede traer nueve programadores de sistemas de vehículos Tesla y crear una nueva función de redes sociales en un mes. O tres meses, o nueve meses, para el caso.

Otra pregunta relacionada es: «¿Cómo puede un gran proyecto de software tener un año de retraso? Respuesta: ¡un día a la vez!» La solución es garantizar que se cumplan los hitos individuales en cada nivel de gestión.

Brooks también apoyó la idea de equipos de software pequeños y estrictamente administrados que puedan evitar la sobrecarga de funciones y tomarse su tiempo.

Después de todo, también dijo Brooks, «un buen software, como una buena comida, toma tiempo para producir».

Ahora, algunas personas dirían que el código abierto ha refutado eso. En el manifiesto de código abierto The Cathedral and the Bazaar, Brooks abogó por un estilo «catedral». Por el contrario, los desarrolladores de Linux y de código abierto poco organizados lanzaron actualizaciones de software temprano y con frecuencia.

¿Pero es éste realmente el caso?

Si observa más de cerca cómo se desarrolla Linux, verá muchos desarrolladores. Pero están dirigidos por un grupo mucho más pequeño de funcionarios encabezados por Linus Torvalds. Las adiciones de código en sí consisten en muchos pequeños cambios.

Los cambios significativos, como agregar Rust a Linux o WireGuard VPN, tardan años en ocurrir.

Creo que debe tenerse en cuenta que en la época medieval a menudo se celebraban bazares en los terrenos de la catedral.

Brooks también nos advirtió que debemos tener cuidado con las balas de plata.

«No hay un solo desarrollo, ya sea en tecnología o técnica de gestión, que por sí solo prometa una mejora de orden de magnitud en una década en términos de productividad, confiabilidad, simplicidad». En resumen, si alguien de su equipo le promete que su última idea, descubrimiento o invento «cambiará el mundo». no les creas

Por supuesto, hay desarrollos que cambian el mundo.

Más recientemente, me vienen a la mente la computación en la nube, Docker/containers y la computación perimetral. Pero nada de eso sucedió tan rápido como podrías pensar.

Todos tardaron años en madurar y volverse importantes. Quiero decir, si bien el éxito aparentemente repentino de Docker puede haberlo sorprendido, su tecnología de contenedores se remonta a 2000 y las cárceles de FreeBSD.

Finalmente, DevOps, la principal tendencia de desarrollo actual, también le debe mucho al trabajo de Brooks.

Creía firmemente que todos se comunicaban en un proyecto. (Es la necesidad de una comunicación eficaz lo que hace que sea imposible solucionar los problemas de software invirtiendo más horas de trabajo en ellos).

Por supuesto, a menudo hacemos esto ahora en Git y con herramientas CI/CD, pero las comunicaciones ahora, como lo eran a principios de los años 60, siguen siendo vitales para el éxito de los proyectos comerciales y de programación.

Y tener éxito es lo que quería Brooks.

Copyright © 2022 IDG Communications, Inc.

Teilen Sie es