Software legado, una lección del Y2K

 Al acercarse el año 2000 aparecieron muchos titulares apocalípticos que anunciaban el fin del mundo de diversas y ocurrentes maneras. Entre ellos destacaban los que auguraban grandes desastres provocados por computadoras desequilibradas. Conocido como Y2K o “el error del milenio”, este auguraba el fin de la civilización al desencadenar una serie de fallos en cascada que colapsarían todos los servicios controlados por computadoras. La forma en que el mundo lo enfrentó es una lección que nos deja el Y2K, que no debemos olvidar.

Como pudimos ver en la entrada “El misterio de la i“, los programadores somos criaturas de hábito. Perpetuamos prácticas ancestrales sin conocer a profundidad sus orígenes. Además tenemos la mala costumbre de asumir que nuestro software tendrá una vida corta. Esto puede ser resultado de la forma de trabajo, donde se enfrenta un proyecto a la vez, de inicio a fin (al leer esto, al dios de los proyectos incompletos se le saltan las lágrimas, de la risa *).

El problema

El error estaba relacionado con algo, tan aparentemente trivial, como el formato y forma de almacenamiento de las fechas en las computadoras. Muchos programas y algunos sistemas operativos representaban los años, que son números de cuatro dígitos con solo los dos últimos, lo que hace que el año 2000 sea indistinguible de 1900 o utilizaban un rango de valores demasiado corto.

Curiosamente, el problema era conocido desde mediados de los años 80. En 1984 fue publicado el libro “Computadoras en crisis”, por Jerome y Marilyn Murray y en 1985 se registra una discusión en Usenet abordando el problema de los formatos de fecha y qué ocurriría con el cambio de milenio. La primera persona conocida en referirse al tema fue Bob Bemer, en 1958.

Hay que tener en cuenta que en los comienzos de la computación, el almacenamiento era un recurso muy caro. Para sacar el máximo provecho de la poca memoria disponible muchos trucos u optimizaciones fueron utilizados. Pero a partir de los 90, la restricción no era tan fuerte como para ahorrarse esos dígitos. Al pasar los años se continuaron usando formatos de datos legados de sistemas antiguos.

Aquellos programadores ancestrales no esperaban que sus programas y datos perdurarían en el tiempo y solo el que ha sufrido tener que trabajar con un software legado puede entender los dolores de cabeza que trae modificar su comportamiento. Se impuso la máxima de ingeniería: Si funciona, no lo toques. Pero, eventualmente tuvieron que tocarlo.

Vieja etiqueta: Recuerde apagar su computadora antes de la medianoche del 31 de diciembre de 1999
Vieja etiqueta: Recuerde apagar su computadora antes de la medianoche del 31 de diciembre de 1999

Uno de los ejemplos más extremos de programas ancestrales todavía en uso es el MOCAS (Mechanization of Contract Administration Services), responsable de la gestión de contratos del Departamento de Defensa de los Estados Unidos. Se encuentra en explotación desde 1958 y se ha ido adaptando a las nuevas tecnologías. Simplemente es demasiado costoso y complicado reemplazarlo. En 1999 se realizaron pruebas para comprobar su tolerancia al Y2K.

Un interesante documento con las pruebas realizadas a varios sistemas del Departamento de Defensa de los Estados Unidos, entre ellos el MOCAS, se encuentra público en el enlace: https://media.defense.gov/1999/Nov/09/2001713942/-1/-1/1/00-035.pdf. Alerta de spoiler, podía sufrir problemas con las fechas, pero no por su funcionamiento interno, sino por las interfaces con sistemas externos.

La solución

Aunque algunas voces alertaban que se exageraron las amenazas, el público demandó soluciones. Se realizó un esfuerzo mundial por remediar el error. Gobiernos de todo el mundo, sector privado, desarrolladores de software, entre otros, se pusieron manos a la obra. En tareas de preparación para el cambio de milenio se estima que fueron gastados más de 451 000 millones de dólares.

Fueron creados grupos gubernamentales, páginas web de apoyo, comités. Se crearon certificaciones tipo “amigable con Y2K” y mucho software fue actualizado.

Finalmente llegó la fecha y pasó, el mundo siguió rodando hacia el mismo lado, los aviones siguieron volando, la vida continuó. Los problemas reportados fueron de poca gravedad y su número fue menor del esperado. Una parte afirma que las afectaciones fueron pocas debido a toda la preparación, mientras que la otra básicamente los catalogó de histéricos y afirmó que un enfoque reactivo hubiera sido más barato.

La moraleja

Para muchos programadores los proyectos son como aventuras amorosas, van y vienen. Para las instituciones que adoptan una solución de software, es una relación a largo plazo, define su vida y en los casos exitosos no se abandona. Los desarrolladores de software deben tener en cuenta que sus creaciones pueden estar activas por mucho tiempo, durante el cual requieren mantenimiento y soporte. Aplicar las mejores prácticas de diseño establecidas y arquitecturas robustas ayudarán a prevenir el próximo apocalipsis cibernético.

Más importante aún que el manejo del código, es el tratamiento y almacenamiento de los datos, ya que son estos los que perduran en el tiempo aún cuando el código sea actualizado. Un diseño limpio y sencillo de sus datos ayudará a los programadores del futuro a conservar la cordura.

Tal vez lo más importante de todo sea mantener el principio KISS (Keep it Simple, Stupid!, Mantenlo simple, estúpido!). No hay que sobrecomplicar las cosas para parecer inteligente, en el futuro alguien te lo puede agradecer.

* El número de proyectos de software incompletos en la corta historia de la programación es tan grande y ha creado tanta ansiedad que probablemente algún dios del caos ha sido creado.

Comentarios