El gráfico de Minard: una infografía de casi siglo y medio

Charles_Joseph_Minard

Una imagen vale más que mil palabras y de ahí el valor de las infografías. Puestos frente a una imagen y un texto explicativo la mayoría miramos la imagen y sin embargo tenemos que hacer un esfuerzo consciente para leer el texto. Por eso es tan interesante el concepto de infografía: la imagen y el texto son un todo y no se entiende el uno sin la otra.

El gráfico de Charles Joseph Minard, que fue inspector general de Puentes y Carreteras, refleja sobre un mapa el trayecto del ejército napoleónico en su campaña de Rusia y está considerado la primera infografía moderna. El tramo de color rojo muestra sobre el mapa el camino de ida hacia Moscú desde la frontera con Polonia y el tramo negro el de vuelta. Cada milímetro de ancho representa 10.000 hombres. Además, un gráfico paralelo muestra las condiciones meteorológicas extremas que tuvieron que soportar los soldados derrotados en su camino de vuelta, combinándolo con las fechas más relevantes.

“El gráfico de Minard es el mejor gráfico estadístico que se haya dibujado nunca” (Edward Tufte)

Lo que el gráfico muestra de una forma brutal es que la campaña la empezaron 442.000 hombres, de los que sólo llegaron a Moscú 100.000 y, tras abandonar Moscú, sólo consiguieron regresar al punto de partida 10.000, que tuvieron que soportar unas temperaturas terribles en su viaje de vuelta, hasta de -30ºC el 6 de Diciembre de 1813.

Minard publicó este gráfico a los 88 años de edad y falleció un año después, el 24 de Octubre de 1870. Esta semana se cumplen 145 años de su fallecimiento. Sirva este post como homenaje a un hombre que se adelantó a su tiempo.

*Edward Tufte, experto en diseño de la información, autor también de la frase “Power corrupts, PowerPoint corrupts absolutely”.

Mi ábaco en la web de UCMAS

Screen Shot 2015-10-14 at 20.21.00

Los amigos de UCMAS España han publicado en su web una versión adaptada de mi ábaco. Si no conocéis el método UCMAS echadle un vistazo, yo empecé con esto del ábaco porque mis críos estaban apuntados y me enganché.

Esta versión incluye, además del modo “FlashCards”, en que hay que identificar el número que aparece en pantalla, un modo “Demo” que reproduce en el ábaco las operaciones (sumas y restas) que vamos introduciendo en el teclado.

 

 

 

 

 

Las metáforas, imprescindibles, pero qué peligro.

 

The_Wasa_from_the_Bow

By Nick Lott – Own work. Licensed under CC BY 2.0 via Wikimedia Commons

Una de las características más llamativas del desarrollo de software para las personas legas en la materia es que es un trabajo invisible. Cuando uno entra en una fábrica de piezas de motor, por ejemplo, puede ver tornos de control numérico, personas limando las rebabas y piezas en distintos niveles de acabado. En una fábrica de muebles veremos tableros, patas torneadas, mucho serrín, mesas a medio montar y percibiremos olor a barniz. Durante la construcción de una vivienda se ven perfectamente los cimientos, forjados, canalizaciones y tabiquería pero en una fábrica de software no hay más que personas delante de un monitor y es imposible tener una idea clara del progreso del trabajo simplemente observando a la gente trabajar.

Para muchos de los perfiles implicados en el desarrollo de una solución software el proceso es un poco más visible, pero no visible del todo. En un proyecto complejo con varias tecnologías implicadas no es raro que pocas personas entiendan cómo encaja cada pieza del puzzle. Surge, por tanto, la necesidad de utilizar metáforas para intentar simplificar la complejidad de lo que se está desarrollando y poder tomar decisiones.

El poder de las metáforas es asombroso. Se dice que el químico alemán August Kekulé estaba obsesionado con intentar entender la estructura del benceno pero por más vueltas que le daba le faltaban dos átomos de hidrógeno, hasta que un día se quedó dormido junto a la chimenea de su casa y soñó con una serpiente que se mordía la cola… acababa de descubrir las cadenas circulares de hidrocarburos.

Benzene Ouroboros

 By DMGualtieri (Own work) [CC BY-SA 3.0], via Wikimedia Commons

Hay metáforas tremendamente llamativas que se han utilizado con frecuencia en la literatura de Ingeniería de Software. El buque Vasa, por ejemplo, construido por Suecia para la guerra que libraba con Polonia y Lituania en el siglo XVII, tenía los requisitos de ser el buque más rápido, más grande y mejor armado. Se construyó con una tremenda presión en fechas (al fin y al cabo había una guerra de por medio y era un proyecto personal del Rey Gustavo Adolfo, que había supervisado personalmente las especificaciones)… y se hundió en el viaje inaugural al primer soplo de viento fuerte, tras quince minutos de singladura. Su estructura, con un centro de gravedad muy alto, fue incapaz de soportar el peso de dos puentes de cañones, el navío se escoró a babor debido al fuerte viento y, al llevar la fila inferior de cañones abierta, entró agua, terminando de desequilibrarlo y hundiéndolo finalmente. Se habían planificado pruebas de estabilidad para el buque pero se cancelaron nada más empezarlas debido a la presión del plazo de entrega, aunque las pocas que se hicieron ya fueron preocupantes. El Vasa es un claro ejemplo de proyecto con requisitos imposibles y de cómo suelen acabar estos proyectos. En la construcción del Vasa se dieron también algunos de los problemas que podemos encontrar hoy en el desarrollo global de software: parece que la masa se distribuyó de forma irregular porque en diferentes fases de su construcción se utilizó el pie sueco y el pie holandés como unidad de medida.

 

El problema es que este poder innegable de las metáforas se puede volver contra nosotros cuando las elegimos incorrectamente o intentamos llevarlas más allá de donde llegan. Por ejemplo, es habitual comparar el desarrollo de software con una cadena de montaje de vehículos y tratar de extraer conclusiones sobre estimaciones y planificaciones de acuerdo con esta metáfora, como si las ventanas de una aplicación se fabricasen en serie como las de un vehículo y los interfaces fueran latiguillos. El problema radica en que la metáfora es incorrecta de raíz: desarrollar software es un proceso complejo y altamente cualificado que no tiene nada que ver con trabajos mecánicos y repetitivos como una cadena de montaje. Si buscamos una metáfora automovilística para la construcción de una solución software es mucho más aproximado el desarrollo de un nuevo modelo de vehículo desde la etapa de concepción hasta que está listo para la cadena de montaje. En este símil la cadena de montaje en realidad sería el equivalente de copiar CD’s (y en eso somos rapidísimos…)

640px-Renault_clay_model_-_front

By DineshAdvOwn work. Licensed under CC BY-SA 3.0 via Commons

Si observamos en detalle cómo es el proceso de diseño de un nuevo vehículo encontraremos numerosas analogías con el desarrollo de software, muchas más que en la cadena de montaje. El proceso automovilístico está resumido aquí: Cuánto se tarda en desarrollar un nuevo modelo de automóvil.

 

Automóvil
Software 
Las condiciones del proyecto Los requisitos
El diseño UML
Las primeras maquetas Mocks
Los prototipos Desarrollo versiones Alfa, Beta, Release Candidate
Pruebas de los prototipos FAT, UAT, …
La fabricación Copia de CD’s, publicación de descargable, etc.

Continue reading