#macrotweet: el imperativo de intentar

It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something.

Frederick P. Brooks Jr.

'The mythical man-month'

Tres motivos para documentar un proyecto software... y cualquier otro proyecto...

Es una buena práctica, sin discusión, documentar el software. Una buena práctica que, por desgracia, tiende a no ejercerse y que no es fácil ni de promover ni de auditar...aunque si sufrir su ausencia.

Hay razones evidentes de legibilidad, de mantenibilidad, de facilitar la transferencia y colaboración entre diferentes programadores, de legado a quien venga detrás...

Pero más allá de esas evidencias, me parecen relevantes las tres razones que aporta Frederick P. Brooks en su libro 'The mythical man-month', tres motivos más orientados, si se quiere, a la gestión del proyecto que a la calidad del software propiamente dicho.

El primero es como mecanismo de descubrimiento de gaps e inconsistencias. Así, nos dice:

writing decisions down is essential. Only when one writes do the gaps appear and the inconsistencies protrude. The act of writing turns out to require hundreds of mini-decisions, and it is the existence of these that distinguishes clear, exact policies from fuzzy ones.

Es quizá éste un motivo poco reconocido pero el que personalmente más aprecio y al que más valor otorgo: la escritura, la documentación, como vehículo de pensamiento y de estructuración. Estoy seguro de haber escrito en este u otro de mis blogs al respecto porque lo considero esencial,

El segundo es casi evidente y autoexplicativo y tiene que ver, simplemente, con la comunicación:

Documents will communicate the decisions to others

El tercer motivo es como herramienta de gestión, como un lugar de consulta y guión, casi un plan que consultar para monitorizar el proyecto y gestionarlo.

a manager's documents give him a data base and checklist.

Se observa que estos motivos van más allá de la evidencia de comentar el código o utilizar una herramienta CASE que de alguna forma documenta un diseño. Se trata de la documentación como herramienta de gestión del proyecto e incluye, adicionalmente y más allá de la documentación estrictamente técnica, la expresión escrita de los planes y decisiones arquitecturales y de gestión, y llegaría a algo así como el Project Management Plan que preconiza el PMI (Project Management Institute).

#macrotweet: una triste realidad sobre la documentación en proyectos de software

In most computer projects there comes a day when it is discovered that the machine and the manual don't agree.

Frederick P. Brooks Jr.

'The mythical man-month'

1000 transistores: un auto-homenaje

Si el chip, el chip azul en concreto, es la metáfora que guía este blog, el transistor podría ser la metáfora que representase cada post, cada artículo aquí publicado.

Y si tomamos por válida esa metáfora, el lector podrá sospechar el sentido del título de este artículo.

Si, este post que el lector está recorriendo, hace el número 1000 publicado en este blog Blue Chip.

Un ya largo, y desde luego esforzado, camino que inicié el 22 de Enero de 2009 con un primer post casi preventivo 'Estoy fabricando el chip...' con una advertencia por si algún navegante de forma inexplicable llegaba hasta mi blog antes de que lo hubiese realmente inaugurado y anunciado.

Los primeros artículos 'reales', los publiqué el 31 de Enero de ese año, nueve días después, con una explicación acerca de las intenciones del blog ('A modo de presentación ¿qué es un 'blue chip'?') y una arriesgada, y el tiempo ha demostrado que bastante desacertada, apuesta acerca del futuro de Twitter y el microblogging.

Desde entonces hasta hoy, 1000 artículos, nada más y nada menos, lo cual supone una media de más de trece posts por mes y del orden de tres artículos por semana.

Espero que los contenidos que publico sean interesantes para mis visitantes pero, caso que no fuese así, espero al menos que se reconozca el esfuerzo y dedicación que suponen estos 1000 artículos.

Cuando escribo esto, ya está preparado el 1001, así que creo que tengo cuerda para rato.

Pero, mientras voy fabricando nuevos transistores, ruego me permita el lector unos segundos de espero que merecido auto-homenaje.

La organización jerárquica como gestión de la comunicación

Muchas son las ideas que se nos pueden ocurrir para explicar el por qué las organizaciones tradicionales presentan una estructura jerárquica, una especie de árbol de poder.

Pero en el libro 'The mythical man-month' su autor, Frederick P. Brooks, Jr. nos ofrece una en que a lo mejor no habíamos pensado: la gestión de la comunicación.

La explicación es la siguiente: a medida que el número de integrantes de un proyecto u organización se multiplica, los canales de comunicación, las posibles interacciones, crecen exponencialmente. Esto hace que las organizaciones no puedan escalar porque los costes de comunicación y coordinación en seguida se convierten en inasumibles.

¿La solución?

La organización y, en concreto, la organización jerárquica.

En una organización jerárquica establecida por motivos funcionales, con criterios de división de trabajo, los trabajadores se comunican fundamentalmente con los de su misma unidad y reportan a sus responsables directos, éstos a los suyos y así sucesivamanente.

El resultado es una espectacular reducción de interacciones y, por tanto de los costes de coordinación.

Así nos lo explica el propio Brooks:

If there are n workers on a project, there are (n² - n )/2 interfaces across which there may be communication, and there are potentially 2n teams within which organization must occur. The purpose of organization is to reduce the amount of communication and coordination neccessary; hence organization is a radical attack on the communications problem.

y sobre la organización jerárquica:

The means by which communication is obviated are division of labor and specialization of function. Tree-like structure organizations reflects the diminishing need for detailed communication when division and specialization are applied.

Simple, ingenioso y casi inapelable.

Eso sí, me pregunto cómo enfocar entonces los nuevos modelos de organización, las de naturaleza matricial, y no digamos nada las organizaciones en red....

Sobre integridad conceptual, arquitectura empresarial y grandes proyectos de software

El software, a pesar del impacto absolutamente tangible que tiene en las personas, en las empresas, y en la economía es sin embargo en sí mismo algo bastante intangible y maleable, algo que se mueve mucho en el terreno de las ideas y los conceptos, cuya concepción y construcción, a pesar de los esfuerzos en la creación de metodologías y herramientas, depende todavía de la inspiración, la opinión y el diseño de arquitectos y desarrolladores.

Esto convierte el diseño de software en una actividad apasionante...pero también algo artesanal e incierta.

Cuando, además, hablamos de grandes proyectos de software, que involucran a decenas e incluso centenas de personas, la libertad de pensamiento y diseño, que en otros ámbitos consideraríamos fuertemente beneficiosa, se puede convertir en peligrosa.

¿Por qué?

Pues porque si las distintas partes de un sistema complejo se piensan de forma separada tienden a no encajar bien, tienden a producir fallos, tienden a complicar el conjunto, tienden a hacerlo difícilmente asimilable tanto para el equipo técnico que lo debe evolucionar y mantener, como a los usuarios que lo deben emplear y para los cuales fue construido.

Y esto que ya es grave durante la construcción inicial del sistema, se convierte en casi mortal para su evolución y mantenimiento.

Un conjunto no coherente de soluciones que por separado pueden ser brillantes, se convierte en una especie de Frankestein poco gestionable. Paradojicamente, el todo puede ser menos, bastante menos, que la suma de las partes.

En ese sentido nos advierte Frederick P. Brooks Jr. en su libro 'The mythical man-month' a propósito del concepto que él denomina integridad conceptual.

Nos dice así:

conceptual integrity is the most important consideration in systems design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.

Como se puede ver, valora tanto la integridad conceptual que está dispuesto a sacrificar funcionalidades y soluciones si éstas no encajan bien en el todo. 

Toda una demostración de sabiduría y experiencia.

En este caso hablamos de un gran proyecto de software pero de una forma creo que muy parecida, aunque a otra escala, a una escala en que hablamos ya de mapas de sistemas, mapas de información y/o mapas de procesos, el concepto de arquitectura empresarial puede servir de planteamiento director para conseguir esa integridad conceptual a nivel empresarial, cuando se trata de que los sistemas y procesos se integren y colaboren de forma natural, sin solapes, sin gaps, sin excentricidades y sin planteamientos divergentes.

Sin restar ni un ápice de su importancia al talento, la creatividad y la innovación, todo lo contrario, cuando hablamos de ecosistemas complejos como los grandes sistemas software, el mapa de sistemas de una gran compañía o el mapa de procesos de una gran organización, el orden se hace necesario, se hace necesaria esa integridad conceptual de nos habla Brooks.

Lenguaje natural versus lenguajes formales

Cuando se intenta describir, analizar y modelar algo abstracto, y pienso, por lo cerca que se encuentra de mi actividad profesional, en procesos de negocio, software, etc se suele recurrir a metodologías y lenguajes formales.

Así, por ejemplo, en el mundo del software nos encontramos con los conocidos diagramas entidad relación, los ya vetustos DFD (Diagramas de Flujo de Datos) o la riqueza de diagramas de lenguajes de modelado como el UML.

En el mundo de los procesos de negocio, podemos pensar, por ejemplo, en BPMN.

Pero ¿qué nos añaden este tipo de lenguajes respecto a una descripción en lenguaje natural?

Varias cosas se me podrían ocurrir:

• Exactitud, sin posibilidades de interpretaciones arbitrarias
• Capacidad para ser automatizados (no siempre, pero sí en ocasiones)
• Capacidad para el intercambio (entre distintas personas y organizaciones, incluso en diferentes países y con diferentes idiomas)

A cambio, también presentan algunos inconvenientes:

• Necesidad de aprendizaje previo
• Necesidad de un cierto esfuerzo para interpretarlos
• Falta de amigabilidad
• Son poco pedagógicos y no aptos para lo divulgativo

Pero veamos qué nos dice Frederick P. Brooks en su libro 'The mythical man-month'. 

En un pasaje del mismo afirma:

Let us examine the merits and weaknesses of formal definitions. As noted, formal definitios are precise. They tend to be complete; gaps show more conspicuously, so they are filled sooner. What they lack is comprehensibility. With English prose one can show struuctural principles, delineate structure in stages or levels, and give examples. One can readily mark exceptions and emphasize contrasts. Most important, one can explain why.

Quizá, precisión frente a comprensibilidad es lo que resume las ventajas y desventajas.

En mi experiencia, y esto no es ser especialmente original ni brillante, los mejores resultados se obtienen combinando ambas técnicas. Unos diagramas en lenguaje formal, explicados y puestos en contexto en lenguaje natural, nos ofrecen lo mejor de ambos mundos y permiten unos modelados a un tiempo precisos y automatizables unido a una fácil comprensión y comunicación.

#macrotweet: la experiencia de un fracaso caro

It is a very humbling experience to make a multimillion-dollar mistake, but it is also very memorable.

Frederick P. Brooks Jr.

'The mythical man-month'

El optimismo como defecto... en la planificación de proyectos de software

Parafraseando el famoso dicho, podríamos afirmar que

Planificar siempre es difícil... especialmente si es a futuro.

En la sentencia original el verbo es predecir, y no planificar...pero en cierto modo la planificación es una predicción, bien que basada en la experiencia y, en ocasiones, en técnicas más o menos reconocidas.

Si bien la planificación es siempre compleja, parece como si los proyectos de software fuesen especialmente sensibles a un error de planificación que nace de un excesivo optimismo.

Por eso, en su famoso libro 'The mythical man-month', Frederick P. Brooks afirma:

All programmers are optimists

Y la experiencia indica que algo hay de cierto en esto. En efecto, los proyectos de software tienden con enorme frecuencia a retrasarse, probablemente mucho más que cualquier otro tipo de proyecto.

So the first false assumption that underlies the scheduling of systems programming is that all will go well.

Pero, ¿de dónde sale ese optimismo crónico?  

Dos son los argumentos que recoge el autor. 

Por una parte, el medio con el que trabaja el desarrollo software es un medio lógico, no físico y, por tanto, extremadamente maleable. Esto es diferente, por ejemplo, de la construcción de una vivienda donde los medios son materiales y mucho menos maleables. El software es casi pensamiento puro... y eso nos crea esa sensación de maleabilidad y de poder sobre ello. y de que no surgirán dificultades...cosa que es extremadamente falsa.

De hecho, y este es el segundo argumento, el software es extremadamente complejo y formado por muchísimos elementos. La probabilidad de que los avances de todos o la mayor parte de los componentes sean tal y como estaba planificado, es decir, que no surjan dificultades en ninguno de ellos, es extremadamente baja..,con lo que, aunque sólo sea por estadística, el optimismo en el mundo del software está absolutamente injustificado.

Y esa es la paradoja: al contrario de lo que sucede en la mayoría de los campos, en el caso de los proyectos de software, el optimismo lejos de ser una virtud es un defecto, un defecto frecuente, un defecto crónico...

Ingeniería de software: ¿por qué es tan difícil pasar del garaje a la factoría?

Los fenómenos que se observan en el mundo del software, y en concreto, en lo relativo a la productividad, son a veces sorprendentes.

Tengo una experiencia que me demuestra claramente que la productividad entre persona y persona puede variar en órdenes de magnitud dependiendo sobre todo, creo, del conocimiento y el talento. A diferencia de muchos otros campos, conocimiento y talento (sobre todo este último) son mucho más relevantes incluso, que la motivación. Sea como fuere, las diferencias de productividad son enormes.

En otra escala, sorprende no solo la capacidad de innovación sino también la rapidez y productividad con que pequeñas empresas, a veces núcleos reducidísimos de programadores, son capaces de producir software de extraordinaria calidad, complejidad y funcionalidad y cómo, sin embargo, con frecuencia, las grandes compañías de consultoría, desarrollo o integración son lentas y producen resultados inferiores.

¿Por qué se produce esto? ¿No es contradictorio?

En su libro 'The mythical man-month', Frederick P. Brooks, Jr. analiza este fenómeno y llega a interesantes y clarificadoras conclusiones.

Primero parte del producto típico de 'garaje' y es lo que denomina un programa. Dicho programa es autocontenido y se ejecuta en la máquina de su autor y el sistema en que fue desarrollado. En este ámbito es donde suele producirse ese fenómeno de garaje, esa innovación y esa aparente productividad superior.

A partir de aquí, el autor distingue dos ejes en que ese software puede evolucionar

La primera forma de evolución es hacia un producto. Un producto es un un programa que puede ser ejecutado, probado, reparado y extendido por cualquiera. Puede usarse en muchos entornos y con diferentes juegos de datos. Para pasar del programa al producto, se debe producir una generalización, tiene que ser extensivamente probado  y debe ser documentado. Esto hace que, en estimación del autor (muy versado en el mundo del software), el producto sea tres veces más costoso que el programa.

La segunda forma de evolución es hacia lo que denomina un sistema. En un sistema los programas interaccionan de una forma coordinada y según una disciplina. Para que el programa pase a ser un componente de un sistema, debe ser escrito de forma que cada entrada y cada salida respete una sintaxis y una semántica precisas. Además, debe hacer un uso limitado de recursos, puesto que éstos son compartidos. Finalmente, debe ser probado en conjunto con el resto de componentes, lo que lleva a la aparición de errores debidos a interacciones insospechadas. De nuevo, el autor estima que un componente de un sistema es, como mínimo, tres veces más costoso que el programa aislado.

Finalmente, podemos mezclar ambas evoluciones para obtener un sistema producto que añade las complejidades de las dos evoluciones anteriores y que proporciona un resultado realmente útil... pero cuesta nueve veces más.

Es cierto que nos estamos fiando de las estimaciones del autor...pero también es cierto que sus argumentos son sólidos y las problemáticas que expresa reconocibles.

Ciertamente, pueden existir otros motivos para la menor productividad en las grandes empresas (burocracia, actividades colaterales no directamente productivas o menor motivación) pero aún así, los argumentos de Brooks parecen dar una buena explicación a por qué es tan costoso pasar de la programación más amateur o tipo startup, a una producción realmente industrial, por qué es tan difícil, en definitiva, pasar del garaje a la factoría. 

#macrotweet: innovación, obsolescencia... y un puntito de realismo

The obsolescence of an implementation must be measured against other existing implementations, not against unrealized concepts.

Frederick P. Brooks Jr.

'The mythical man-month'

¿Por qué nueve mujeres no pueden tener un niño en un mes?

Por supuesto, se trata de una explicación no literal sino a lo que la metáfora significa.

Cuando un proyecto, un trabajo, va retrasado, el plan de acción que primero se nos ocurre para recuperar el tiempo perdido es incrementar el número de recursos, de personas asignadas a ese proyecto.

Sin embargo la experiencia enseña que frecuentemente esta medida no sólo no mejora la situación  sino que incluso puede llegar a empeorarla.

La sabiduría popular lo explica diciendo que aunque una mujer tiene a un niño en nueve meses, nueve mujeres no pueden tener un niño en un mes.

Pero ¿podemos encontrar una explicación algo más rigurosa? ¿Hay alguna regla que nos enseñe cuándo añadir recursos puede ser útil para mejorar tiempos y cuándo no?

En su famosa obra 'The mithycal man-month', Frederick P. Brooks analiza desde varios puntos de vista, aunque siempre circunscrito al desarrollo del software, esta problemática. En ese análisis ofrece ideas y razonamientos muy interesantes, pero hay una directriz muy sencilla que nos ayuda a discriminar. Nos dice:

Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them. 

De lo que de alguna manera Brooks nos está hablando es de los costes de comunicación y coordinación, costes que crecen a medida que aumenta el número de recursos. Por ello, añadir más recursos ('men') no siempre ayuda a disminuir de forma equivalente el tiempo ('months').

¿Y qué pasa con las mujeres y el niño?

Es evidente que la metáfora es sólo válida hasta un cierto punto. Es evidente que un niño no es software y que existen otros condicionantes de tipo biológico muchísimo más relevantes pero todavía parcialmente podemos aplicar la teoría de Brooks. Así, ya que para hacer un niño entre varias mujeres se necesitaría una cierta colaboración y coordinación, nueve mujeres nunca conseguirían disminuir  un mes el tiempo para tener un niño. 

Tengámoslo en cuenta la próxima vez que por retraso en un proyecto, o por ansia de satisfacer a un cliente o mejorar un caso de negocio tengamos la tentación de añadir recursos indiscriminadamente con el ilusorio propósito de mejorar los tiempos de disponibilidad.