El 31 de diciembre de 1999, mientras millones de personas celebraban la llegada del nuevo milenio, miles de ingenieros informáticos permanecían frente a sus ordenadores, esperando comprobar si los sistemas que habían revisado durante años continuarían funcionando después de medianoche.
En España, 35.000 profesionales formaban parte de un dispositivo especial para vigilar las infraestructuras críticas: bancos, hospitales, aeropuertos, compañías eléctricas y redes de telecomunicaciones.
El mundo llevaba años preparándose para una posible catástrofe tecnológica.
¿La causa? Una decisión informática tomada varias décadas atrás: representar los años utilizando únicamente dos dígitos.
Cuando llegó la medianoche, prácticamente todo siguió funcionando.
Pero aquello no significaba que el problema no hubiera existido.
En los años cincuenta y sesenta, la memoria y el almacenamiento informático eran recursos extraordinariamente caros. Los programadores debían optimizar cada byte y evitar cualquier consumo innecesario de capacidad. Por eso, representar 1965 como 65 o 1987 como 87 tenía todo el sentido.
Ahorrar dos caracteres podía parecer insignificante, pero cuando esa información se almacenaba millones de veces, el ahorro era considerable. Además, pocos imaginaban que aquellos programas continuarían funcionando cuarenta años después. Sin embargo, muchos sobrevivieron.
Las empresas continuaron utilizando sus aplicaciones de contabilidad, facturación y gestión financiera. Esos sistemas se conectaron con nuevas tecnologías y sus dependencias fueron creciendo.
El problema apareció cuando el año 1999 pasó a 2000.
Un programa que almacenaba 99 podía interpretar el siguiente año, 00, como 1900.
Las consecuencias potenciales eran importantes: cálculos incorrectos de intereses, errores en las fechas de vencimiento de contratos, problemas de inventario o fallos en determinados sistemas industriales.
En septiembre de 1999, Fernando Sáez Vacas, catedrático de la Universidad Politécnica de Madrid, publicó en El País un artículo titulado Tecnología global con fecha de caducidad.
Su reflexión era especialmente interesante: utilizar dos dígitos para representar los años no había sido necesariamente un error de programación. Era una decisión perfectamente comprensible dadas las limitaciones de la tecnología disponible.
El problema no estaba tanto en la decisión original como en la incapacidad de anticipar cuánto tiempo permanecerían funcionando aquellos sistemas.
Y es que muchas veces las limitaciones tecnológicas no aparecen porque algo esté mal diseñado, sino porque las circunstancias para las que fue diseñado han cambiado.
A finales de los noventa, miles de organizaciones comenzaron a revisar sus sistemas informáticos. El problema resultó mucho más complejo que modificar la representación de las fechas.
Había que identificar aplicaciones afectadas, localizar dependencias, actualizar bases de datos, revisar dispositivos y comprobar que los cambios no provocaban nuevos errores.
Muchas empresas todavía utilizaban aplicaciones desarrolladas décadas atrás, especialmente en COBOL, cuyo funcionamiento conocían cada vez menos profesionales.
Según una estimación retrospectiva de IDC publicada por Computerworld, el coste mundial de preparación para el efecto 2000 alcanzó aproximadamente los 308.000 millones de dólares.
Algunas cifras permiten comprender la magnitud del esfuerzo:
General Motors: entre 540 y 600 millones de dólares previstos para adaptar sus sistemas.
Citigroup: alrededor de 900 millones presupuestados.
Exxon: 250 millones.
Procter & Gamble: aproximadamente 90 millones.
En Estados Unidos, la Administración federal también destinó miles de millones a revisar sus infraestructuras.
La inversión permitió solucionar problemas relacionados con las fechas, pero también modernizar numerosos sistemas que llevaban años funcionando con tecnologías antiguas.
En muchos casos, el efecto 2000 fue la excusa definitiva para abordar proyectos que las organizaciones habían aplazado repetidamente.
Y, finalmente, llegó la medianoche.
¿Qué ocurrió realmente?
Mucho menos de lo que se había temido.
Los sistemas bancarios continuaron funcionando, las redes eléctricas no experimentaron interrupciones generalizadas y los aviones siguieron volando.
Sin embargo, sí se produjeron algunos incidentes.
En Japón, varias centrales nucleares registraron anomalías en sus sistemas de monitorización y transmisión de datos. Ninguna comprometió la seguridad de los reactores.
En Estados Unidos, un problema informático afectó a sistemas terrestres utilizados para procesar información procedente de satélites de reconocimiento militar.
También se registraron errores en dispositivos electrónicos, sistemas administrativos y aplicaciones que mostraban fechas incorrectas.
Pero las grandes catástrofes previstas nunca llegaron.
¿Significa que los riesgos se habían exagerado?
Probablemente algunas previsiones fueron demasiado alarmistas. También es posible que determinadas organizaciones realizaran inversiones innecesarias. ¿Ves algún paralelismo con la IA, la AGI,…?
Sin embargo, hay otro dato relevante.
En mayo de 1997, solamente el 21 % de los sistemas críticos de las principales agencias federales estadounidenses estaban preparados para el cambio de fecha.
En diciembre de 1999, el porcentaje había alcanzado el 99,9 %.
La ausencia de grandes incidentes no puede separarse del enorme esfuerzo realizado para prevenirlos.
Y aquí aparece una paradoja habitual de los proyectos preventivos: cuando funcionan correctamente, los problemas que evitan terminan siendo invisibles.
La historia podría parecer una curiosidad de los primeros años de la informática, pero seguimos enfrentándonos a problemas muy similares.
De hecho, algunos tienen una fecha perfectamente identificada.
El efecto 2038: cuando Unix se quede sin tiempo
Muchos sistemas informáticos representan las fechas mediante el número de segundos transcurridos desde el 1 de enero de 1970. Es una solución sencilla y eficiente, pero las implementaciones que utilizan enteros de 32 bits con signo tienen un límite.
El 19 de enero de 2038, a las 03:14:07 UTC, alcanzarán su valor máximo.
Un segundo después, determinados sistemas podrían interpretar incorrectamente la fecha, llegando a situarla en diciembre de 1901.
La mayoría de las plataformas modernas ya utilizan representaciones de 64 bits, pero todavía existen dispositivos industriales, sistemas embebidos y aplicaciones antiguas que requieren atención. El problema recuerda inevitablemente al efecto 2000: una representación numérica diseñada décadas atrás que termina agotando su capacidad.
El GPS también tiene su propio efecto 2000
El sistema GPS original utiliza un contador de semanas de diez bits, capaz de representar únicamente 1.024 semanas. Aproximadamente cada 19,7 años, el contador vuelve a cero.
El primer reinicio ocurrió en agosto de 1999 y el segundo, en abril de 2019.
Durante este último, algunos dispositivos antiguos comenzaron a mostrar fechas incorrectas o necesitaron actualizaciones para continuar funcionando.
El siguiente reinicio está previsto para noviembre de 2038.
Las señales GPS modernizadas han ampliado esta capacidad, pero determinados receptores antiguos podrían seguir viéndose afectados.
Microsoft Exchange sufrió un problema parecido en 2022
El 1 de enero de 2022, algunos servidores Microsoft Exchange dejaron de procesar correctamente los correos electrónicos. La causa estaba relacionada con un identificador numérico utilizado para las actualizaciones de su motor antimalware.
Al comenzar el nuevo año, el identificador superó el máximo admitido por el sistema. Microsoft tuvo que publicar una solución para corregir el problema. Veintidós años después del cambio de milenio, una limitación numérica volvía a provocar una interrupción informática.
Internet también se quedó sin direcciones
Otro ejemplo, aunque sin una fecha exacta de interrupción, es el agotamiento de las direcciones IPv4.
Cuando se diseñó este protocolo, sus aproximadamente 4.300 millones de direcciones parecían más que suficientes.
Sin embargo, el crecimiento de Internet terminó superando aquella previsión.
En noviembre de 2019, RIPE NCC anunció el agotamiento de su reserva de direcciones IPv4 para nuevas asignaciones ordinarias.
Internet no dejó de funcionar gracias a mecanismos para compartir direcciones y a la progresiva adopción de IPv6. Pero una decisión de diseño tomada décadas atrás había terminado condicionando la evolución de toda la red.
Y existe otro desafío importante que probablemente nos ocupará durante los próximos años: la transición hacia la criptografía poscuántica.
La aparición de ordenadores cuánticos suficientemente potentes podría comprometer determinados algoritmos criptográficos que utilizamos actualmente.
El NIST ya ha publicado estándares para preparar esa transición.
A diferencia del efecto 2000, no conocemos la fecha exacta en la que esos algoritmos podrían dejar de ser seguros.
Pero el reto es similar: revisar y adaptar una enorme cantidad de sistemas antes de que sus mecanismos de protección resulten insuficientes.
También déjame recordarte que si te gusta la tecnología, el podcast de Código Abierto puede ser una muy buena opción.
Food for thought
En 1997, James Dale Davidson y William Rees-Mogg publicaron El individuo soberano (The Sovereign Individual). Mientras Davidson y Rees-Mogg describían cómo las tecnologías digitales iban a transformar el mundo, miles de ingenieros trabajaban para corregir las limitaciones de sistemas informáticos diseñados cuarenta años antes.
El futuro se estaba construyendo sobre decisiones tomadas en el pasado.
Y eso sigue ocurriendo.
Cuando diseñamos una arquitectura informática, siempre trabajamos dentro de determinadas restricciones: capacidad de procesamiento, almacenamiento, presupuesto, conocimientos disponibles o necesidades del momento.
Cada decisión representa un compromiso entre lo que necesitamos y lo que podemos construir. El problema aparece cuando esas decisiones permanecen durante décadas, mientras las circunstancias cambian. Algo especialmente frecuente en los sistemas que tienen éxito, porque cuanto más extendida está una tecnología, más difícil resulta sustituirla.
Lo hemos visto con Internet y su protocolo IPv4, con los sistemas de representación temporal y con numerosas aplicaciones empresariales que siguen utilizando tecnologías desarrolladas hace décadas. Y probablemente volveremos a verlo con algunas de las arquitecturas que estamos construyendo alrededor de la inteligencia artificial.
No sabemos qué decisiones actuales terminarán pareciendo equivocadas dentro de veinte años. Quizá sean determinados formatos de datos, modelos de seguridad, mecanismos de interoperabilidad o dependencias de servicios tecnológicos.
Lo que sí sabemos es que ninguna arquitectura puede diseñarse suponiendo que las circunstancias permanecerán invariables. Por eso, una de las características más importantes de un buen diseño tecnológico no es solamente su eficiencia actual, sino su capacidad de adaptación.
Una arquitectura preparada para el futuro no tiene que anticipar todos los escenarios posibles. Tiene que permitir evolucionar cuando las hipótesis sobre las que fue construida dejan de ser válidas.
Aquellos ingenieros que, en los años sesenta, decidieron ahorrar dos caracteres difícilmente podían imaginar que su decisión movilizaría a miles de profesionales y costaría cientos de miles de millones de dólares cuatro décadas después.
Probablemente tampoco podían imaginar que muchos de sus programas continuarían funcionando tanto tiempo.
Y quizá esa sea la enseñanza más interesante del efecto 2000.
Las decisiones tecnológicas no siempre envejecen mal porque fueran equivocadas. A veces, simplemente, sobreviven demasiado tiempo al mundo para el que fueron diseñadas.
Que nunca te falten ideas, ni ganas de probarlas.
A.
PD. Seis libros para entender cómo envejece la tecnología. Si te interesa comprender cómo se diseñan los sistemas, por qué envejecen y cómo podemos adaptarlos a nuevas circunstancias, aquí tienes seis lecturas que complementan la historia de hoy.
The Soul of a New Machine de Tracy Kidder. Premio Pulitzer en 1982, relata la carrera de un equipo de ingenieros por construir un nuevo ordenador. Una historia real que ayuda a comprender las limitaciones y decisiones técnicas de la informática de aquella época.
The Mythical Man-Month de Frederick P. Brooks. Un clásico de la ingeniería del software que explica por qué desarrollar sistemas complejos es tan difícil y cómo pequeñas decisiones pueden acabar teniendo consecuencias enormes.
How Buildings Learn de Stewart Brand. ¿Qué tienen en común un edificio y una arquitectura informática? Ambos deben adaptarse a necesidades que sus diseñadores originales nunca imaginaron. Una excelente reflexión sobre la capacidad de evolución de lo que construimos.
The Phoenix Project de Gene Kim, Kevin Behr y George Spafford. Una novela empresarial que muestra cómo la deuda tecnológica, los sistemas heredados y las malas decisiones organizativas pueden terminar poniendo en peligro toda una compañía.
Working Effectively with Legacy Code de Michael Feathers. Una guía práctica para comprender, modificar y mantener aplicaciones antiguas sin comprometer su funcionamiento. Justo el desafío al que se enfrentaron miles de ingenieros durante el efecto 2000.
Seis libros con una idea en común: construir tecnología es importante, pero conseguir que siga siendo útil cuando el mundo cambia es un desafío todavía mayor.