En marzo publiqué un ensayo cuya conclusión fue que la ineficiencia funciona como un impuesto civilizatorio, la fricción inevitable de los sistemas grandes. Ese texto quedó cerrado, pero mientras lo hacía apareció otra idea que no me quité de la cabeza.
Este nuevo ensayo es más bien exploratorio. Lo pienso como una disección de esa segunda tesis, distinta, aunque emparentada, que recomiendo sobre todo a quienes trabajan en entornos operativos y de producción sujetos a problemas con múltiples variables.
Lo que quiero poner sobre la mesa es sencillo de enunciar, pero complejo de aceptar. Cada vez que una institución, un software o un protocolo empieza a mostrar desgaste, la reacción automática suele ser intentar salvarlo.
Se contratan consultores, se escriben informes, se hacen reformas que prometen darle nueva vida. Y aunque a veces funciona, muchas veces lo único que se logra es prolongar la agonía de algo que ya no debería existir. La tesis del “diseño para la muerte” ofrece otra opción más racional. En vez de obsesionarnos con arreglar sistemas moribundos, deberíamos diseñarlos desde el inicio para que mueran de forma programada.
Decir esto en voz alta incomoda porque la muerte, en nuestra cultura, se asocia casi siempre al fracaso. Cuando un programa deja de recibir soporte, lo llamamos abandono.
Cuando una institución se disuelve, hablamos de decadencia. Pero en biología nada dura para siempre. Y esa finitud cumple una función. Una célula que nunca se apaga se convierte en un tumor. La desaparición de un organismo deja espacio para otros. Morir, en un ecosistema es parte del diseño. Si entendemos esa lógica en la naturaleza, ¿por qué esperamos que nuestras creaciones sociales y tecnológicas sean distintas?
El contraargumento más fuerte
Vale la pena preguntarse qué respondería alguien que defiende la permanencia. No desde la nostalgia, mas bien desde un marco más sólido. Ahí aparece el Efecto Lindy, que sugiere que la edad de una tecnología es en sí misma una señal de resistencia.
El alfabeto latino o las reglas del ajedrez han sobrevivido milenios porque su diseño ha demostrado ser antifrágil, capaz de adaptarse y aportar valor a través de incontables contextos históricos.
Diseñar un sistema con una fecha de caducidad es excluirlo voluntariamente de esta prueba de fuego evolutiva, negarle la oportunidad de convertirse en algo verdaderamente perdurable.
Además, una muerte programada genera un problema de horizonte de inversión. ¿Qué comunidad de código abierto dedicaría una década a construir un ecosistema complejo sobre una arquitectura que tiene una terminación de servicio programada para 2040? …La promesa de permanencia, aunque sea una ilusión, funciona como el dispositivo de compromiso que fomenta la acumulación paciente de valor y la confianza a largo plazo.
El terreno del software da ejemplos claros. Lenguajes de programación de los años setenta siguen en uso, porque las organizaciones que dependen de ellos no se animan a dejarlos ir.
El resultado es una cadena de parches costosos que consume tiempo y recursos. Mientras tanto, nuevas herramientas más simples quedan fuera. El “diseño para la muerte” sería lo contrario… Significaría crear desde el inicio lenguajes y aplicaciones con fecha de caducidad. Significaría acompañarlos con un camino claro para migrar a lo siguiente. Algo así como un manual explícito para desmontar el sistema.
Lo mismo ocurre con las instituciones. Hay oficinas públicas que se mantienen activas solo porque nunca hubo voluntad de cerrarlas. Para justificar su existencia inventan tareas que ya no responden a necesidades reales. La alternativa sería pensar organizaciones que, desde el día en que nacen, saben también cuándo deben apagarse. Podrían ser comisiones creadas para un tema concreto y que, al resolverlo, se disuelven sin drama. Esa caducidad no sería fracaso, sería prueba de haber cumplido su mandato.
Mecanismos perversos
El diseño para morir resuelve un problema, pero introduce otro. Pensemos en una agencia que sabe de antemano que se disolverá cuando logre su meta. En ese escenario, cada paso hacia el éxito también acerca a los empleados a quedarse sin trabajo.
Esto podría engendrar una forma de autopreservación burocrática, donde el objetivo se mantiene siempre cercano pero nunca alcanzado. Podríamos ver una proliferación de informes sobre “nuevas cepas de bacterias resistentes”, solicitudes de fondos para estudiar “impactos ecológicos a largo plazo” y una ralentización general de las medidas más efectivas.
El sistema, diseñado para morir al completar su misión, termina incentivando que la misión no se complete del todo. La cláusula terminal se convierte en un generador de actividad indefinida de bajo impacto.
La resistencia viene de un sesgo cultural profundo. Nos obsesiona la permanencia. Aplaudimos empresas centenarias, monumentos que sobreviven siglos, instituciones que se niegan a desaparecer. Valoramos lo eterno como un logro.
Pero esa obsesión lleva a conservar lo inútil. La verdadera innovación es lo que sabe cuándo dejar de ocupar espacio. A veces es más sensato permitir que algo muera con dignidad que forzar su supervivencia.
Pensar el “diseño para la muerte” implica imaginar cada sistema con dos capas. La primera es la funcionalidad durante su vida útil. La segunda es el mecanismo de salida. Ese mecanismo es parte central del diseño.
En software podría ser un protocolo estandarizado que permita trasladar datos sin fricción. En instituciones podría ser una cláusula que obligue a evaluarse de forma periódica y, si ya no cumplen con su propósito, activar un cierre ordenado. En ambos casos, morir sería la última fase prevista de su existencia.
El costo cuantificable de no morir
Hasta aquí el planteo ha sido conceptual. Para entender la magnitud del problema conviene revisar algunos números. El costo de mantener estructuras obsoletas no es abstracto, se mide en presupuestos y en horas de trabajo.
Pensemos en la industria global del transporte marítimo, que todavía opera en gran medida con el estándar EDIFACT para el intercambio de documentos, un protocolo de la década de 1980 anterior a la internet moderna. Aunque es funcional, su rigidez exige ejércitos de consultores especializados y complejas pasarelas de software para dialogar con las APIs actuales.
Un solo puerto de gran tamaño puede gastar decenas de millones al año únicamente en la fricción que supone traducir mensajes EDIFACT. Si estimamos que apenas un 1% del valor de las mercancías transportadas a nivel mundial se topa con esta fricción, hablamos de un impuesto oculto que asciende a cientos de miles de millones de dólares. Ese es el precio acumulado de eludir una migración coordinada y dolorosa, el interés que pagamos por una deuda técnica contraída hace cuarenta años y que se capitaliza silenciosamente en las cadenas de suministro del mundo.
Lejos de ser un gesto cínico, la idea es pragmática. Reconoce que la utilidad no es eterna. Reconoce también que mantener lo insostenible consume recursos que podrían usarse en otra parte. Diseñar para la muerte libera energía. Permite concentrarse en lo nuevo sin quedar atrapado en lo viejo.
Pienso en dos escenarios si esta lógica se aplicara con rigor. El primero es el de plataformas tecnológicas que nacen anunciando que solo estarán activas durante una década. Sus usuarios lo saben desde el inicio y se preparan para migrar cuando llegue el momento. El segundo es el de instituciones públicas con mandatos específicos que, al concluir su tarea, se disuelven. En ese marco, cerrar seria misión cumplida (y no fracaso).
Las ventajas prácticas son evidentes. En producción y operaciones, un sistema con muerte programada reduce la parálisis que generan las dependencias heredadas. Obliga a preparar planes de migración claros, a documentar mejor, a dejar instrucciones legibles….En gestión institucional, previene la proliferación de organismos cuya única función es su propia supervivencia. Y en cultura organizacional, introduce la idea de que el cierre no es algo que se teme, más bien algo que se planifica.
Un arsenal conceptual más amplio
La propuesta puede entenderse también como un intento de aplicar la “destrucción creativa” de Schumpeter a escala micro.
En lugar de esperar a que una disrupción del mercado arrase con una industria obsoleta, un sistema diseñado para su propio fin ejecuta una demolición controlada sobre sí mismo.
Con ello combate la dependencia de la trayectoria (path dependency), ese estado en que las decisiones iniciales nos confinan a un futuro subóptimo porque el coste de cambio es demasiado elevado. La cláusula de extinción funciona como un compromiso previo para evitar la jaula de la inercia.
La tesis abre también preguntas filosóficas. ¿Por qué nos aferramos tanto a lo permanente? Parte de la respuesta es psicológica. Nos tranquiliza pensar que lo que construimos puede durar para siempre. Parte también es económica. Invertimos capital, tiempo y prestigio en un sistema y queremos estirarlo indefinidamente para amortizarlo.
El problema es que esa lógica ignora los costos invisibles de mantener las estructuras que ya no sirven mucho. Diseñar para la muerte es reconocer que incluso lo más valioso debe dar paso a lo que sigue.
No es un principio nuevo, solo es uno que rara vez aplicamos. En la naturaleza, morir con dignidad es regla. En ingeniería y administración, todavía es excepción.
Quizás haya llegado el momento de asumirlo también en nuestros sistemas sociales y tecnológicos. Si lo logramos, no hablaremos de fracasos ni abandonos. Hablaremos de diseños completos que incluyen tanto el inicio como el final.
La innovación más radical sería crear el primer sistema capaz de morir como parte de su plan original (y no el sistema perfecto).