La Crisis del Software

¿Has oído alguna vez hablar sobre la crisis del software? Hoy vamos a tratar sobre un problema del que se dieron cuenta a mediados del siglo XX, en la década de los 60, y hablaremos también de algunas de las consecuencias que tuvo esta crisis. Os damos la bienvenida a Programando Otra Historia. El 11 de octubre de 1968 tuvo lugar una reunión del Comité de Ciencias de la OTAN y durante su exposición Edger Dykstra dijo: Hay una gran diferencia si el mantenimiento significa adaptarse a un problema cambiante o simplemente corregir errores.

Yo me refería al mantenimiento del primer caso. Puede que tenga razón al culpar a los usuarios por pedir equipos teóricos, pero si los fabricantes ofrecen esto con una cara seria, entonces solo puedo decir que todo el negocio se basa en un gran fraude.

Hasta el momento, las ciencias computacionales habían servido para desarrollar soluciones cada vez más complejas, pero el nivel de complejidad aumentó y comenzaron a surgir problemas en los productos de software entregados, que supusieron grandes costes por no saber cómo medir el desarrollo de grandes productos, daños a la propiedad por no tener en cuenta la seguridad y, potencialmente, dejar al descubierto información sensible e incluso problemas que afectaron a la calidad de vida y conllevaron la muerte de algunas personas. Pacientes cuyos equipos de radioterapia no fueron probados de forma adecuada.

La crisis del software. En el libro de historia de los lenguajes de programación años 1940 a 1959 podemos encontrar referencias de cómo trabajaban los grupos de desarrollo de software. En principio, los problemas a resolver a través de programas no estaban pensados para ser excesivamente complejos. La elaboración de tablas de artillería o el cálculo de nóminas eran programas muy específicos que realizaban una una cantidad de cómputos muy específicos y generaban el resultado. La información proporcionada para calcular los datos y la obtención de datos de salida se manejaban manualmente. No obstante, con el tiempo el software fue más y más complejo. Los programas ya no solo hacían una operación sino que mantenían un flujo de ejecución más amplio, realizaban más tareas y disponían de más responsabilidades. Este incremento de complejidad en el software solo incrementó el nivel de fallos y la falta de experiencia de la recién surgida profesión de programador así como el siempre cambiante entorno de trabajo donde surgían máquinas, sistemas operativos y lenguajes cada poco tiempo, hacía difícil mantener un nivel alto de conocimiento y disponer de personal con alta experiencia. Edgar Dijkstra es considerado uno de los principales programadores y científicos de datos de todos los tiempos, y fue uno de los comparecientes en este comité de ciencias de la OTAN para intentar encontrar una solución a este problema creciente que comenzaba a afectar a todas las industrias porque el software comenzaba a estar presente en todas ellas. También se ha dicho que Dijkstra fue uno de los críticos más ácidos dentro del mundo de la computación y por ese motivo no se limitó en su comparecencia y tachó de posible acto de fraude la acción de grandes empresas dedicadas a la computación, en aquellos tiempos empresas como IBM. Aunque en el documento no se menciona la crisis del software como tal, Hay un artículo en ACM de 1972 donde Dijkstra nos dice: Hace pocos años algo cambió. Hablar acerca de la crisis del software era una blasfemia. El punto del cambio fue la conferencia sobre ingeniería del software en Garmisch en octubre de 1968, una conferencia que causó sensación ya que se produjo la primera admisión abierta de la crisis del software. Vamos a citar algunos de los grandes errores cometidos por estas empresas y que aún siguen cometiéndose por empresas de desarrollo de software en todo el mundo. El mito hombre-mes.

En las consultoras de desarrollo de software es muy normal medir el esfuerzo de desarrollo en coste asociado a hombre dedicado 100% durante un mes. Es decir, si un desarrollador de software cobra 10.000 euros brutos al mes y dedica un mes completo a un proyecto, el proyecto ha necesitado un esfuerzo de 1 hombre·mes y un coste de 10.000€. El problema viene de determinar si un proyecto con una dificultad X tarda en hacerse Y, un proyecto de una dificultad 2X debe realizarse en una cantidad de tiempo igual a 2Y, ¿no?

Pues no. Hay tareas secuenciales que no pueden paralelizarse, y aunque pongas a trabajar 1.000 personas a la vez, Si la paralelización de esta tarea no es posible, tendrás a una persona trabajando y 999 ociosas esperando por la finalización de la primera parte de la tarea. Después habrá otro que podrá trabajar mientras los otros 999 quedan igualmente ociosos. Fred Brooks escribió en 1975 el libro The Mythical Man-Month donde explica estas falacias e intenta establecer una explicación clara entre tareas paralelizables, tareas dependientes y la velocidad máxima de un proyecto, así como la máxima cantidad de personas que pueden trabajar en él. Además, el libro explica otros problemas agregados a la cantidad de trabajadores en un proyecto, como el problema de la comunicación. Durante la conferencia se expuso el problema del OS/360 de IBM, que costó 50 millones de dólares con un esfuerzo de 500 hombres/año de inversión y estimaron la construcción del siguiente TSS-360 en 1.000 hombres/año.

Una de las preguntas surgidas por Dagapeyev fue: si la recomendación en 1958 para un fabricante de software era menos de 50 programadores y ahora el número ronda los 1.000 o 2.000, ¿cuántos serán necesarios en 1978? Collins sentenciaba a raíz de la baja calidad de la producción de software en comparación con otras industrias de fabricación: La gestión de la programación seguirá mereciendo su mala reputación actual en cuanto a eficacia en función de los costos y la planificación hasta que se logre una comprensión más completa del proceso del diseño del programa.

Estoy seguro que no soy el único que ha tenido que escuchar una reprimenda a la hora de estimar un proyecto o un desarrollo concreto con la explicación: Una mujer puede tener un bebé en 9 meses, pero 9 mujeres no pueden tener un bebé en un mes. Creo que es uno de los mejores ejemplos para entender que no todo se puede paralelizar. Sin embargo, no siempre es tan obvio saberlo. Para dar un ejemplo, en un artículo escrito por Eduardo Estrella en LinkedIn se puede leer su experiencia con respecto a la construcción de un software grande, y hablamos de nuestros días, no del pasado.

Hace unos años participé en un proyecto grande donde se siguió esa fórmula tan común: fechas imposibles, más personas de las necesarias, sin iteraciones, sin test.

Esta forma de desarrollo fue la llamada ola humana. Cientos de personas trabajan durante varios años resultando en una forma cara y lenta de obtener software. Pero este no es el único problema. Los errores del software cuestan vidas. David y Fraser establecieron que es alarmante la fallibilidad inevitable del software de grandes dimensiones, puesto que el mal funcionamiento de sistemas hardware-software avanzados ya ha costado vidas. Dijkstra nos dejaba otra de sus incisivas frases al respecto: La difusión del conocimiento tiene un valor evidente. La difusión masiva del software cargado de errores es aterradora.

El desarrollo en modo ola humana normalmente se salta un proceso tan importante como son las pruebas. Las pruebas del software consisten en un conjunto de pruebas específicas que aseguran el buen y correcto funcionamiento del software, y tan solo su rigurosidad y cantidad puede ayudar a minimizar los errores del software.

Como bien decía Dijkstra: Las pruebas en los programas pueden ser usadas para mostrar la presencia de fallos, pero nunca mostrarán su ausencia.

Por tanto, aún disponiendo de una gran cantidad de pruebas y con un sentido muy riguroso, podríamos encontrar fallos. Sin embargo, el enfoque contrario, eliminar la generación de estas pruebas, resultará inequívocamente en un desastre, como también decía Klaus Leopold.

Intentar acelerar la planificación de un proyecto reduciendo las pruebas es como perder peso donando sangre.

Establecer y definir en qué consiste crear un software, las fases a seguir y establecer un estándar de calidad parecen ser necesarios porque hay software en uso para la gestión de elementos necesarios para la vida, medios de transporte e incluso equipos militares controlando armas que podrían llevar a un problema desde el punto de vista de naciones enteras. A lo largo de la historia de la computación han surgido algunos casos que ilustran estos problemas y que, como decíamos, han arruinado la vida de personas. Uno de ellos es el llamado caso Therac-25, que entre 1985 y 1987 costó la vida de 3 pacientes por sobredosis de radiación y daños graves a otros 3 pacientes.

El 25 de febrero de 1991, un error de software propagado en el tiempo afectó al sistema de defensa de misiles Patriot de Estados Unidos en Arabia Saudita. No detectó un ataque por culpa de este error de software y costó la vida a 28 soldados norteamericanos.

Otro error en el sistema de alarma de la sala de control de FirstEnergy el 14 de agosto de 2003 en el noroeste y medioeste de Estados Unidos evitó la notificación de un problema y que los operadores no pudiesen reaccionar ante la sobrecarga del sistema eléctrico, produciéndose un apagón y un caos con varias líneas de transmisión cayendo sobre árboles. El apagón produjo muchos daños graves, accidentes y la muerte de 90 personas.

También, y más recientemente, un error de software costó la vida a 157 personas al estrellarse un avión Boeing 737 MAX por inclinar automáticamente el morro del avión hasta que el piloto perdió completamente el control. Este caso llevó a una investigación sobre la compañía y sobre el software del vuelo para el 737 MAX que comenzó a inundar la prensa especializada desvelando nuevos errores descubiertos por peritos especializados.

Aún queda abierto el asunto de si se ha hecho algo al respecto, si esta crisis es cosa del pasado o si es un problema que aún continúa en nuestros días. En el próximo vídeo trataremos las metodologías surgidas como consecuencia de esta crisis, hablaremos del fenómeno bala de plata y concluiremos este asunto, pero... ¿Qué opinas tú? ¿Crees que quedó resuelto?