_
_
_
_
Retos de la gestión
Tribuna
Artículos estrictamente de opinión que responden al estilo propio del autor. Estos textos de opinión han de basarse en datos verificados y ser respetuosos con las personas aunque se critiquen sus actos. Todas las tribunas de opinión de personas ajenas a la Redacción de EL PAÍS llevarán, tras la última línea, un pie de autor —por conocido que éste sea— donde se indique el cargo, título, militancia política (en su caso) u ocupación principal, o la que esté o estuvo relacionada con el tema abordado

La poesía del software

El 4 de junio de 1996, a las 9.33, despegaba el Ariane 5, orgullo de la Agencia Espacial Europea. Era su primer vuelo. A los 40 segundos, cuando estaba a casi cuatro kilómetros de altura, el cohete giró bruscamente y explotó en miles de pedazos. Junto con la aeronave se desintegraron en el aire los 500 millones de dólares que había costado, sin seguro que cubriera las pérdidas.

Posteriormente, un comité de expertos independiente descubrió la causa del fallo: una línea de software incorrecta. Una, entre los millones que tenía el sistema. Fue, posiblemente, el fracaso más fulgurante de toda la historia del software. ¿Una negligencia de los ingenieros? El comité de expertos no lo consideró así. Hay quien equipara el trabajo de los ingenieros informáticos al de los poetas. Al igual que éstos, trabajan únicamente con palabras. Una sola palabra mal puesta puede arruinar la mejor de las poesías. La desventaja de los informáticos es que escriben poesías de millones de líneas.

El 15 de febrero de 2000 el diario El País publicaba una noticia que escandalizó a muchos. El Windows 2000, recién salido al mercado, tenía 63.000 defectos potenciales demostrados. ¿Incompetencia de los programadores? No. 'Los fallos son inherentes a la ciencia informática', alegó uno de los máximos responsables de Microsoft. Se basaba en lo que Alan Turing, uno de los grandes científicos del siglo XX, demostró matemáticamente -o sea, con absoluta certeza- en 1936: que es imposible asegurar objetivamente que un programa de ordenador no trivial esté libre de errores. Si esto ocurre en estos tipos de proyectos de software, qué no ocurrirá en los de empresa, en los que las limitaciones de tiempo y presupuesto reducen normalmente la etapa de prueba intensiva de los nuevos sistemas. No abusaré de la paciencia del lector, no le voy a explicar historias como la del banco australiano Westpac Banking Corporation -150 millones de dólares evaporados-, o la del aeropuerto de Denver -varios cientos de millones de dólares de pérdidas-; tampoco le voy a contar historias más próximas a nosotros, para no herir susceptibilidades. A buen seguro, el lector ha vivido y conoce más de una.

¿Cómo se gestionan en estas circunstancias los proyectos informáticos? Distinguiendo entre error, fracaso y desastre. Sólo si aceptamos que el error es inevitable, asumiremos que la incertidumbre del éxito es consustancial a estos proyectos. Incertidumbre que, por cierto, no es tan ajena al mundo de la empresa. Por ejemplo, en el lanzamiento de nuevos productos hay estudios que indican que la tasa de fracasos es del 40%. Pero nadie se escandaliza, todos lo saben, lo asumen y gestionan las contingencias. Tienen la certeza de la incertidumbre.

En algunas actividades humanas los errores son ineludibles; los fracasos, impredecibles; pero llegar a la catástrofe es imperdonable. Lo inexcusable del caso FoxMeyer mencionado en esta página fue que apostaron la supervivencia de la empresa a la consecución exacta de un proyecto informático. La ironía del asunto es que, después de la quiebra, la empresa que compró FoxMeyer (por un importe semejante al del proyecto) consiguió hacer funcionar esos mismos sistemas. En FoxMeyer no entendieron la poesía que hay en el software. No supieron gestionar la incertidumbre.

Archivado En

_
_