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