Los ordenadores se multiplicaron en número y capacidad entre finales de los 50 y principios de los 60. El ordenador de gama más baja de la línea System/360 de IBM, lanzado en 1964, era 43 veces más rápido y tenía 66 veces la memoria del modelo estrella del gigante azul en 1953, el IBM 650. Y si en 1960 había 4.400 ordenadores en todos los Estados Unidos, el principal mercado de estos cacharrejos por aquel entonces, en 1965 eran ya 21.600.
En esa época, la práctica totalidad de los programas los hacían los propios compradores, o una empresa contratada a tal efecto. Eran programas escritos para ajustarse exactamente a las necesidades de los clientes. Así que, con tamaño incremento en el número de ordenadores, hicieron falta muchos, muchos más programadores, y no había tantos. Además, al ser las nuevas computadoras mucho más capaces, los requisitos se iban ampliando, con lo que los programas crecían en tamaño y complejidad.
Con tanta demanda insatisfecha de código escrito por programadores, los precios aumentaron. Además, aunque los ordenadores no bajasen de precio, sí eran cada vez mejores, de modo que el software era una parte cada vez más importante del coste total de tener una computadora funcionando a pleno rendimiento.
Como si todo esto no fuera suficiente, a medida que aumentaba el tamaño del software –y su complejidad–, más fácil era que aparecieran errores. El caso más famoso de fiasco fue el desastre de la sonda Mariner, lanzada en julio de 1962 y que hubo de ser destruida en el aire por un error en el programa que controlaba su trayectoria. Pero estuvo lejos de ser el único.
Aquella situación se vio reflejada en todo su dramatismo en el proyecto del sistema operativo OS/360, proyectado para los ordenadores System/360. Debía ser capaz de funcionar en todas las computadoras compatibles, fuera cual fuera su potencia y memoria, y poder ejecutar más de un proceso a la vez para que el procesador no perdiera tiempo esperando a que el disco hiciera lo que se le mandaba. El responsable era la misma compañía que estaba desarrollando con éxito el sistema de reservas Sabre, y pese a que su presupuesto era el mayor que ningún programa había tenido hasta entonces, todo lo que pudo ir mal fue mal.
Comenzaron a trabajar en él unas 75 personas, en la primavera de 1964, con la intención de sacarlo dos años después. Costaría entre 30 y 40 millones de dólares. Pero poco a poco los plazos se fueron alargando, y el coste se disparó. A finales del 65 se descubrieron fallos graves en el diseño que llevaron a pensar a parte del equipo que ni siquiera podría ver la luz, pero acabó viéndola a mediados de 1967, un año después de lo previsto, no sin antes ser reescrito casi por completo. El presupuesto se fue a los 500 millones de dólares, y cuando se terminó había 1.000 informáticos trabajando en él. Pero aun así salió de fábrica bien surtidito de fallos que tardaron años en erradicarse, porque más que arreglarlos parecía que se cambiaban unos por otros: cada solución hacía surgir un nuevo problema.
La ingeniería del software
El director del proyecto, Fred Brooks, terminaría publicando en 1970 un libro sobre aquella debacle llamado El mito del mes-hombre. En él explicaba los problemas derivados de abordar un proyecto de esa magnitud, siendo el principal que la vieja contabilidad que estimaba cuánto trabajo llevaría un programa era una trola de colosales proporciones. Por ejemplo, cuando se decía que un proyecto iba a costar 10 meses-hombre, lo que se quería indicar es que un solo programador podría hacerlo en diez meses, dos en cinco y diez en uno. Esa manera de medir el trabajo era razonable en proyectos pequeños, con equipos pequeños, pero no en algo de la magnitud del OS/360.
"Por muchas mujeres que se sumen a la tarea, gestar un niño sigue llevando nueve meses", diría entonces. Y es que buena parte de los problemas del sistema operativo se debieron a que, según se iban alargando los plazos, se dedicaron a echar gasolina al fuego, es decir, a contratar más programadores. Programadores a los que había que explicar qué se había hecho hasta el momento y cómo; cuáles eran los objetivos que se buscaban y qué se esperaba de ellos; y cuyo código debía acoplarse a lo ya hecho por otros anteriormente. Además, la programación es un proceso creativo, como bien saben los hackers, y añadir músculo no soluciona los problemas.
En 1967 tuvo lugar un congreso en Alemania de ingeniería del software organizado por la OTAN, lo que revela la preocupación que tenían los militares por este problema. La idea era que la informática fuera tan predecible como otras ingenierías: si se sabía cuánto iba a costar y cuánto se iba a tardar en construir un puente, ¿por qué no se podía hacer un cálculo así con los programas? Sin embargo, pocas soluciones salieron de aquel congreso.
Aun así, poco a poco se fueron expandiendo ciertas técnicas que aliviaron el problema, pero no lo hicieron desaparecer por completo.
Los informáticos empezaron a emplear mejores herramientas, desde lenguajes de programación más potentes que reducían la complejidad y los errores a cambio de producir programas algo más lentos –lo que fue progresivamente menos importante, al tener ordenadores mejores y más baratos–, hasta depuradores que facilitaban el hallazgo de los bugs. Se hizo especial hincapié en la programación estructurada, que facilitaba la división del software en unidades más pequeñas y manejables y que terminaría llevando al concepto algo más avanzado de programación orientada a objetos. Y en lugar de pensar que un producto de software se proyecta, se programa y santas pascuas, se pasó a considerar que en su ciclo de vida el lanzamiento es sólo un paso más, porque hay que ir mejorándolo, solucionando los errores y atendiendo los problemas que le surjan al cliente.
Pero como escribiría el propio Brooks –ya en los años 80–, no existía ninguna "bala de plata" que pudiera acabar por sí sola con ese "hombre lobo" que eran los proyectos de software con problemas. Y los problemas podrían ser mortales: entre 1985 y 1987, un bug en una máquina canadiense de radioterapia llamada Therac-25 provocó que seis pacientes recibieran una dosis muy superior a la recomendable: tres de ellos acabaron perdiendo la vida. Y aunque fueran franceses, oiga, igual tampoco se lo merecían.
El problema que provocó la crisis ha sido contenido hasta cierto punto gracias al desarrollo de numerosas técnicas, pero sigue ahí... y no parece que vaya a desaparecer así como así. De hecho, y hasta cierto punto, tanto el largo proceso de desarrollo de Windows Vista como los numerosos problemas que presentaba, y que obligaron a lanzar Windows 7, son una demostración de que, en el fondo, casi todo sigue igual.
Sólo los proyectos de código abierto parecen haber encontrado algo parecido a esa "bala de plata". Pero la idea de que la del software podía ser una ingeniería como las demás, con sus plazos bien establecidos y sus certezas de funcionamiento perfecto, hace ya tiempo que ha sido abandonada por todos los que abandonaron la universidad y trabajan en el mundo real.
Pinche aquí para acceder al resto de la serie CEROS Y UNOS.