Con alarmante frecuencia en las últimas dos semanas me he encontrado a mí mismo repitiéndole lo mismo a gente que debería saberlo ya. Hablo específicamente de una ley aplicada al desarrollo de programas informáticos conocida como la «Ley de Brooks» y, aunque es realmente simple de entender, por algún motivo no parece ni obvia ni natural si no te la muestran y demuestran usando tus propios errores como ejemplo.

Hay muchas metodologías, en estos días de tanto «emprendedor» y «gente altamente eficaz», que se enseñan para manejar equipos de trabajo y proyectos de todo tipo. La «Ley de Brooks» se centra sobre la incorrecta aplicación de uno de los estilos más comunes de llevar proyectos y, específicamente, a la espiral de desastre que suele desencadenar. Al final del artículo pongo más información sobre el libro de Brooks en cuestión y sus otros postulados sobre manejo de proyectos.

En México se dice «Échale más cemento» cuando algún proyecto está atrasándose y no va como debería. La frase viene de la construcción, donde lo que no puedas arreglar con buena ingeniería y arquitectura siempre lo puedes arreglar poniéndole mas hormigón y hierro. Esta analogía se extiende a muchas cosas en las que podemos vernos envueltos:

-¿No puedes transportar todo lo que debes? Échale más camiones
-¿No estás logrando apagar un fuego? Échale más agua
-¿Tienes más información de la que puedes capturar? Échale más gente capturista
-¿No puedes detener a Godzilla? Échale más tanques ((Ésta última es más común de lo que parece.))

El problema es que la solución de «Echarle más cemento» sólo sirve en los proyectos en los que el problema son los recursos y la solución obvia es buscar más recursos.

El otro tipo de proyecto, que es el que nos concierne, es el ‘Serializado’. Proyectos donde una tarea no puede ir antes de otra y cada tarea tiene que hacerse por la misma persona/grupo. Los desarrollos de software son de este tipo porque, con frecuencia (y especialmente en la segunda mitad), las partes que lo componen son interdependientes y dependen unas de otras. No puedes desarrollar pantallas de usuario si no tienes datos que presentar, no puedes hacer rutinas de importación si no tienes tablas definidas.

Esto obviamente no suele ser un problema en desarrollos hechos por grupos pequeños de manera informal pero cada vez más se ve el uso, por parte de compañías y corporaciones, de equipos de desarrollo de terceros, el famoso «outsourcing» o «subcontratación». El outsourcing significa, simple y llanamente, que alguien más hace el trabajo a partir de una serie de condiciones de resultados, por una cuota. ¿Cual es la pega? Que cuando se hace outsourcing de desarrollo tiene que haber un estimado previo estipulando cuánto se va a pagar por ese desarrollo y la forma más fácil de comprender lo que se está pagando es cotizar los proyectos en «horas-hombre»:

Estas horas-hombre pueden luego, fácilmente, multiplicarse por el coste por hora y se sabe de antemano el costo de desarrollo del proyecto (o sea, 1500 euros en el caso de un desarrollador freelance y 150,000 euros en el caso de un desarrollador certificado de consultoría de Oracle).

Las horas-hombre (o su múltiplo, meses-hombre, equivalente a 160 horas) conducen a la deducción equivocada que si una parte requiere 10 horas-hombre entonces diez personas lo completarían en 1 hora. Es dolorosamente indiscutible que TODO líder de proyecto de desarrollo caerá en esta falacia, usualmente en su primer proyecto y, hasta que alguien no se lo señale, fallará en ver que es lo que está pasando mal.

La Ley de Brooks lo dice que «Añadir mas personal a un proyecto tardío sólo logrará retrasarlo más«. Esto significa que cuando un proyecto va retrasado y se intentan añadir desarrolladores nuevos no se toma en cuenta el tiempo el tiempo añadido que le lleva a los nuevos elementos el familiarizarse con el mismo, y que el tiempo adicional perdido en comunicaciones entre ellos puede aumentar tanto que puede llegar a rebasar el tiempo disponible (hay una fórmula al respecto, donde se muestra que a medida que se añaden elementos a comunicar el tiempo dedicado crece de tal manera que al final el 100% del tiempo se dedica a comunicación y el desarrollo se detiene).

¿Qué se puede hacer cuando un desarrollo está retrasado?
Las opiniones aquí son varias y variadas, y no hay ninguna que sea 100% adecuada, ya que depende mucho de la situación específica del proyecto y el cliente, pero el resultado final suele ser que la fecha de entrega del proyecto se retrasa (con o sin cargo adicional al cliente, usualmente el segundo) y en casos extremos el proyecto se cancela totalmente.

La única forma de evitar este problema es a través de delineación adecuada de etapas, metas y módulos en el proyecto y de una distribución adecuada de los recursos asegurándonos de tener localizados a aquellos programadores «estrella» que son capaces de moverse de uno a otro trayendo resultados inmediatos con el mínimo de preparación.

The Mythical Man-Month (El mítico mes-hombre), de Fred Brooks.
El libro ‘El mítico mes-hombre’ de Fred Brooks surge de sus experiencias en IBM y su error de intentar acelerar el desarrollo añadiendo mas desarrolladores al mismo, que es el tema central del libro. En el libro se manejan varios conceptos, de los cuales destacan:
El mítico mes-hombre
Arriba ya he comentado algo de este concepto, conocido como la «Ley de Brooks» pero cabe aclarar que la Ley se suele interpretar de forma incorrecta. Dependiendo de como se entienda puede pensarse que lo que sugiere es que un proyecto debe ser desarrollado por grupos pequeños de programadores altamente capaces, pero la realidad es que el concepto lo que cubre es la adecuada planeación del proyecto y la capacidad de dividir el mismo en módulos separados y que se puedan desarrollar de forma independiente. Específicamente la Ley de Brooks no dice que quitando personal de un proyecto se pueda acelerar su terminación (que podría ser una consecuencia lógica de invertir el postulado).

El efecto del ‘Segundo Proyecto‘
De este problema también son víctima casi todos los líderes de proyectos cuando, después de haber completado el primero deciden aplicar al segundo todo lo que han aprendido. El segundo sistema que haga un jefe de proyecto siempre estará horriblemente sobre-diseñado. En un intento de evitar los problemas encontrados en el primer proyecto el jefe de proyecto sobre compensará cayendo en el extremo opuesto.

El ‘equipo quirúrgico’
Todo jefe de desarrollo debe ser capaz de tener en su equipo al menos una persona e idealmente un conjunto de ellas capaz de atacar cualquier problema que surja. La idea es tener a estos grupos dedicandose a varios proyectos en áreas especialmente problemáticas o con labores asignadas pero capaces de entrar de emergencia en alguna etapa problemática. El concepto es bastante similar al concepto de «Electrón Libre» de Rands

Seguimiento del Proyecto
Metas y etapas (milestones) deben ser definidas de antemano para el proyecto, con fechas límite y conjuntos de funcionalidad mínima requerida. La única forma de evitar el acecho de nuevas funcionalidades es mantener el objetivo inicial hasta su conclusión y sólo entonces introducir mejoras al diseño original (la única excepción a esto siendo los «electrones libres», gracias a su capacidad especial de genios y aún en estos casos debe controlarse de cerca. Esto está atado directamente a…

Congelación de código y versionamiento
No existe ningun sistema perfecto y si no se decide un momento en que el código, esté como esté, se detiene y se declara la versión como terminada, jamás se producirían resultados. Escoger las funcionalidades que deben incluirse en cada versión y el momento en que el desarrollo se detiene hasta la próxima versión es vital para poder dar resultados. Obviamente el «síndrome de la versión 1.0» surge de aquí, pero la alternativa sería lo que se conoce como «vaporware». Proyectos que cada vez parecen tener más y mejor funcionalidad y capacidades, pero que nunca ven la luz del día.

Normalmente no suelo hablar de mí por aquí. En parte porque no me es fácil y en parte porque no me gusta editorializar (contra lo que pueda parecer). Sin embargo han habido algunas conversaciones en estos últimos días que me han hecho pensar ciertas cosas y creo que puede haber otras personas que opinen de forma similar a mí.

Yo me encuentro en una situación poco usual. Nací en España y a todos fines soy español pero desde muy pequeño me fui a vivir a Venezuela primero y a México después. Hoy en día, a tres años de haber vuelto a la península me sigue costando convencer a la gente que conozco que si, que realmente nací en España (aunque haya sido en un sitio tan inesperado como Benidorm) y que sí, que ya se que tengo acento «sudaca», como tan sutilmente me lo han definido.

Y aquí, en lo que no debería ser más que una anécdota simple y sin mayor mérito, es donde se complican las cosas.

En estos tres años me he encontrado conque el hecho de que tenga acento hispano-americano (porque la mayoría no pueden ubicarlo como mexicano) me ha significado perder entrevistas de trabajo, un trato inferior en tiendas, bancos y servicios por teléfono y, en una ocasión memorable, perder el alquiler de un piso aunado a una clara implicación de que mi documentación era falsa porque estaba claro que yo no era español.

¿Porqué es especialmente triste esto? Porque en el momento que la gente se convence (y esta es la palabra exacta) de que SÍ soy español entonces la actitud gira 180º y empiezan a compartir conmigo, supongo que asumiendo que comparto su opinión, sus opiniones con respecto a hispano-américa y a los inmigrantes que vienen de allí.

Ahora bien, no soy yo alguien que diga que el mundo es perfecto en ningún país y mucho menos en los que yo he vivido pero, tal vez por haber vivido en varios, mi perspectiva es diferente. Nunca me dejará de asombrar la facilidad con la que estas inmensas generalizaciones se me mencionan como si por el hecho de no ser de allí signifique que deba compartirlas automáticamente. La gente se molesta cuando puntualizo que no, que no toda latino-américa puede pasarse por el mismo tamiz y que no, tampoco a toda la gente de un mismo país puede hacérsele eso.

Una de las consecuencias de haber vuelto a España (soy re-patriado, por lo visto) es que puedo ver mi propio país con ojos diferentes y que me es más fácil ser crítico en cosas que para los demás, por fuerza de la costumbre, es invisible ya. Esto deberia significar que podría caer en la categoría de «extranjero en la propia tierra» pero en realidad es algo que me suele gustar. Me ha gustado siempre ver todos los lados de lo que tengo enfrente mío y esto no es diferente pero también me ha acarreado problemas en un país en el que el deporte nacional es tomar bandos en una discusión y hacer todo posible esfuerzo por hundir al lado contrario (la técnica más común es ver quien puede discutir más alto, preferentemente descartando todo lo que diga el contrario sin intentar siquiera rebatir sus argumentos y, de ser posible, menospreciándolo por tener su opinión). Con frecuencia me he retirado de conversaciones simplemente porque, visto desde afuera, es totalmente fútil y una pérdida de tiempo el constantemente sostener discusiones en las que ninguno de los interlocutores contempla la posibilidad de ver las cosas de forma diferente.

A lo mejor te preguntas porque suelto todo esto, a las 2 en punto del lado oscuro del desayuno, y no tengo realmente una razón. Desde hace un tiempo lo había estado pensando y algunas situaciones de la última semana me han hecho escribir la parrafada que (probablemente no) acabas de leer.

No lo sé, a lo mejor algún día seré más específico. A lo mejor algún día comentaré las cosas que me chocan de mi país y las que pienso que otros hacen mejor. A lo mejor algún día hablaré sobre la ridícula animadversión hacia el idioma inglés (donde se intenta usar por todos lados pero es literalmente un orgullo hacerlo mal y cualquier crítica provoca una discusión estúpida que nada tiene que ver con el tema) y el doble-estándar al que se somete a este idioma (corregir el inglés de alguien está mal visto, pero no corregirle el francés, portugués o catalán). O sobre como puede acabarse la conversación de forma incómoda si no conoces ni te interesa el nombre del delantero izquierdo del Real Madrid o qué tiempo ha hecho Fernando Alonso en las pruebas de Monza.

En fin, buenas noches.

EDIT: Un año y medio después me encuentro con esta entrada de nuevo por casualidad buscando otra cosa y veo que, entre palizas, vídeos y manifestaciones en los medios, las cosas no han cambiado. Que no han mejorado. Que si encuentras a alguien que sepa ver mas allá del patrioterismo (recordemos: No es Xenofobia, es Racismo. Si fuera xenofobia se trataría mal también a alemanes, ingleses y suecos) tienes que cuidarlo porque NO es la norma.

Adiós a CIAT, a toda su gente tan valiosa, mis amigos, mis compañeros.

El día de hoy dejo CIAT y emprendo una nueva aventura. Me emociona y a la vez me invade un sentimiento de tristeza y nostalgia. Vienen a mi memoria muchas cosas que viví junto a ustedes durante estos seis años y medio que han transcurrido desde el inicio de CIAT.

Recuerdos como todo el trabajo que requirió poner a punto las instalaciones antes de septiembre de 1999 para que pudiéramos iniciar las operaciones de CIAT; El cambio de alfombra del Tec 100 y su «corral» sauna; El infame papel de baño de 600 mil dólares; La velada del 31 de diciembre de 1999 en espera del bug Y2K para salir y darnos cuenta que lo que no funcionaba era el carro en (sic) víspera del siglo XXI ; El primer día de campo en Polotitlán; El cambio de edificio el 21 de marzo del 2000; La configuración de los correos; Los cambios internos de lugar; ese triste día del Camelinas; los cambios de servidores; las tormentas de virus de «desconecten sus computadoras de la red».

Me dio gran satisfacción ser parte de la familia de CIAT, los extrañaré y les deseo lo mejor.

Su amigo Neto.