Un programador errante en busca de la sabiduría...

El mítico hombre-mes

A los hombres de negocios les encantaría poder ahorrar tiempo metiendo mas hombres al trabajo, de ahí viene la ficticia correlación de hombre-mes; Si un trabajo requiere de dos meses de desarrollo entonces dos hombres pueden hacerlo en un mes. Tal vez por que los hombres de negocios piensan que esto es como pintar una pared o algo así. Pero no, esto es un trabajo de ingeniería bastante complejo. De esto trata el mítico hombre mes

¿Vale la pena un libro de 1975 sobre sistemas?

Siendo honestos, no vale tanto la pena, Sus primeros capítulos siguen muy vigentes y solo por eso vale la pena la recomendación. Para ser escritos con mas de 40 años de antigüedad es increíble como la industria del software sigue cometiendo los mismos errores. Ademas este libro tiene una re-edición lanzada en 1995 con un epilogo sublime titulado "Sin balas de plata".

Frederick P. Brooks nos plantea una serie de pensamientos del por que el IBM system/360 fallo, este sistema fue un intento de IBM por ofrecer un sistema operativo único para una serie de mainframes, las super computadoras de los 60, El desarrollo de este sistema operativo fue desastroso y nuestro querido Brooks se encargo de plasmar los errores cometidos en este libro, para que las generaciones venideras no sufrieran tanto.

La correlación del hombre-mes y como mandar un sistema a la mierda

Como ya mencionamos antes, entre los hombres de negocios existe la creencia popular de que mas trabajadores pueden hacer el trabajo mas rápido. Pero esto no es as y brooks plantea un par de motivos. El primero es que la comunicación entre mas personas escala de forma exponencial.

  • Si dos personas necesitan coordinarse para hacer algo, solo hay un canal de comunicación
  • Si tres personas necesitan coordinarse tenemos 3 canales de comunicación
  • Para cuatro tendremos 6 canales
  • Con 5 personas se requerirán 10 canales de comunicación.

... entre mas personas trabajen en un proyecto como colegas, la coordinación entre ellos crece de forma exponencial. Reduciendo así las horas efectivas de programación y aumentando el tiempo necesario de planificación.

Nuestro segundo problema es la cantidad de "features" que pueden trabajarse en paralelo. Si bien teóricamente es posible planear todo y dividir el trabajo, en la practica no es tan fácil. Algunas tareas requieren hacerse de forma encadenada por que dependen entre si en su funcionamiento. Y por que hay un cierto grado de incertidumbre en alguna de las tareas.Por ejemplo; No podemos hacer un sistema de recomendación de productos personalizado por cliente, si primero no tenemos un historial de productos vendidos por cliente. Teóricamente es posible programarlo a la par. En la practica descubriremos que las partes del sistema no encajan y que hay que hacer modificaciones o desarrollar conectores.

De aquí viene la famosa ley de brooks: 9 mujeres embarazadas no pueden dar a luz un niño en 1 mes.

El equipo de cirujanos, una oda a los equipos de desarrollo.

Brooks hace una curiosa analogía en este libro entre el desarrollo de software y un equipo que va a realizar un cirugía. Y es increíble como 40 años después seguimos cometiendo los mismos errores que los famosos full-stacks. Desde siempre los hombres de negocios han creído que pueden solo contratar programadores y ponerlos a hacer de todo y hacerlos correr en círculos si algo no funciona como se espera.

Es aquí donde Brooks de una forma precaria (recordemos que escribió esto en los 70s) recomienda tener un equipo con distintas habilidades. Como en un quirofano, hay enfermeras, médicos especialistas, anestesistas, camilleros, etc. Cada uno de los miembros del equipo cumple un rol especial. Como en un equipo de software lo cubrirían los backends, frontends, devops, administrativos, etc.

De alguna forma la ley de brooks también ha hecho daño. Los empresarios al ver que 9 mujeres no pueden tener a un niño en un mes, intentan que una mujer tenga al niño en 7 meses. No entienden que hay un proceso y que el proceso tiene un numero relativo de gente adecuada para hacer el trabajo en el tiempo optimo.

Quieren que un fullstacks desarrolle un sistema en la mitad de tiempo en la que lo haría un backend y un frontend por que... "ley de brooks". La industria simplemente no aprende.

Sin balas de plata

Por ultimo tenemos este epilogo escrito años después, que simplemente no puedo resumir, ya es bastante pequeño así que les comparto mejor un fragmento.

De todos los monstruos que pueblan nuestras pesadillas, ninguno es tan terrorífico como el hombre lobo, porque pasa repentinamente de lo familiar al horror. Por eso, todos buscamos balas de plata que puedan acabar con ellos magicamente.

El familiar proyecto de software, al menos tal como lo ve un gestor no técnico, tiene algo de ese carácter: suele ser inocente y sencillo, pero es capaz de convertirse en un monstruo de plazos incumplidos, objetivos fallados y productos defectuosos. Por eso escuchamos lamentos clamando por una bala de plata -- algo que haga que los costes del software caigan tan rápidamente como lo han hecho los del hardware.

Pero no se ve en ningún lugar una bala de plata. No hay ningún desarrollo, ni en tecnología ni en técnicas de gestión, que por si sólo prometa ni siquiera una mejora en un orden de magnitud en productividad, en fiabilidad, en simplicidad. En este artículo, intentaré mostrar el porque, examinando la naturaleza del problema del software y las propiedades de las balas propuestas.

Pero ser excéptico no es lo mismo que ser pesimista. Aunque no se vea la luz al final del túnel -- y, de hecho, creo que es inconsistente con la naturaleza del software-- se están realizando muchas innovaciones. Un esfuerzo consistente y disciplinado para desarrollar, difundir y explotar estas innovaciones debería conducir a una mejora de un orden de magnitud. No hay un camino dorado, pero hay un camino.

El primer paso hacia la cura de las enfermedades fue reemplazar las teorías sobre demonios y las teorías sobre humores por la teoría de los germenes. Ese primer paso, el principio de la esperanza, destruyó toda las esperanzas de una solución mágica. Se le dijo a los trabajadores que el progreso se haría paso a paso, con gran esfuerzo, y que una vida saludable sería el pago por una disciplina de limpieza. Eso también es lo que ocurre con la ingeniería del software hoy

Entonces... ¿debo leer Mytical man-month?

Umm... tal vez comprarlo sea tirar el dinero a la basura, mas de la mitad del libro no aplica hoy en día y la otra mitad parece que nunca dejara de aplicar. Brooks de alguna forma fue un genio incomprendido de la gestión de software. así que... Si, vale la pena leer los primeros capítulos, definitivamente.


Ultima revisión:



Usamos cookies. Leer más