No hay nada más permanente que una solución temporal

Son las once de la noche y algo está caído. Después de un rato encuentras la manera de levantarlo: abres un puerto, dejas una tarea corriendo, mueves un cable, pones una excepción. Funciona. La operación sigue y todos se van a dormir.

Antes de cerrar la laptop escribes en el chat del equipo: es temporal, mañana lo hacemos bien.

Ese "mañana" tiene fecha en el mensaje, pero no en el calendario. Y esa es toda la historia.

Hay una máxima de ingeniería que se repite en todos lados porque es verdad: no hay nada más permanente que una solución temporal. Vale la pena entender por qué, porque el mecanismo no es el que uno supone.

Sobrevive porque funciona

Aquí está la parte incómoda. La solución temporal no se queda por descuido ni por flojera. Se queda porque resolvió el problema.

Si no funcionara, la quitarías el jueves. Tendrías que quitarla: algo seguiría roto y alguien estaría preguntando. Lo que la protege es precisamente su éxito. Al día siguiente nadie llama, nadie reporta, la operación corre. Desde afuera se ve idéntica a una solución bien hecha.

Y una cosa que funciona no genera urgencia. Nunca. Esa es la primera capa de blindaje.

Primero pierde la etiqueta

El día uno todos saben que es un parche. A la semana lo saben tres personas. Al mes, dos. A los dieciocho meses ya no es una solución temporal: es cómo está armado esto.

Nadie tomó la decisión de volverla definitiva. Simplemente dejó de estar marcada. El mensaje de aquella noche se perdió en el historial del chat, el ticket se cerró como resuelto —porque lo estaba— y la excepción quedó conviviendo con todo lo que sí se diseñó a propósito.

La prueba es fácil de hacer y suele doler: pregunta en tu operación por qué está armado así algo que todos dan por sentado. Si la respuesta más honesta es "así estaba cuando llegué", ya sabes qué encontraste.

Ponerla tuvo dueño y urgencia; quitarla no tiene ninguno de los dos

Instalarla fue un evento. Tuvo hora, tuvo un responsable con el teléfono en la mano y tuvo una consecuencia clarísima si no se hacía. Todo eso genera acción.

Retirarla no tiene nada de eso. No hay hora, no hay quién, y sobre todo no hay consecuencia visible de no hacerlo. Es trabajo que solo aparece si alguien decide buscarlo, en una lista que compite contra cosas que sí están gritando.

Por eso la deuda que se acumula no es de código ni de configuración: es de propiedad. Nadie es dueño del retiro. Y lo que no tiene dueño no se hace, por más obvio que sea. Lo desarrollamos aparte en gobierno de TI: decisiones, dueños y documentarlas, que es el mismo problema visto desde arriba.

La asimetría que nadie dice en voz alta

Esta es la fuerza más poderosa de las cuatro, y casi nunca se admite.

Dejar la solución temporal no tiene riesgo hoy. Quitarla sí.

Si no la tocas, no pasa nada — al menos no hoy, ni esta semana. Si la quitas, algo puede tronar, y si truena va a tronar con tu nombre encima. El cálculo que hace cualquier persona sensata es inmediato: nadie recibe un reconocimiento por retirar un cable que no estaba molestando, pero todo mundo se entera si al retirarlo se cayó la línea.

Así que el cable se queda. No por incompetencia: por una lectura correcta de cómo se reparten las culpas. Y mientras el incentivo esté así de torcido, ninguna política de documentación lo va a resolver. Es la misma dinámica que hace que el parche que no se aplicó siga sin aplicarse.

Y el que sabía se fue

La última capa es la más silenciosa. La persona que puso el parche cambió de puesto, de empresa o de área. Con ella se fue la única memoria de que aquello era provisional, de por qué se hizo así y de qué había que hacer para deshacerlo.

Lo que queda es una configuración sin contexto. Y una configuración sin contexto no se toca, porque nadie sabe qué depende de ella.

Dónde se las encuentra uno años después

Todo esto suena a teoría hasta que lo mides.

Cuando instrumentamos una red industrial y escuchamos el tráfico real durante dos semanas, los hallazgos tienen casi siempre la misma forma: una regla que se abrió para una prueba y lleva dos años, un equipo de un proveedor que se conectó "en lo que terminaba el proyecto", un puerto que se habilitó en una madrugada para levantar la producción. Lo contamos con más detalle en cómo se ve una prueba de visibilidad por dentro.

Ninguno de esos fue un error. Cada uno fue la decisión correcta la noche que se tomó. Lo que falló no fue la decisión: fue que nadie volvió.

Y hay un detalle que vale la pena subrayar, porque es el que convierte esto de anécdota en riesgo real: esas excepciones son justo las que rompen la segmentación. El diagrama de la red sigue siendo correcto en el papel; lo que ya no es correcto es la red. Cómo se cierra esa brecha sin parar la operación está en segmentar IT/OT sin frenar la producción.

Esto no es un llamado a no hacerlas

Sería un mal consejo, y además falso. A las once de la noche con la operación caída, la solución temporal es la decisión correcta. Levantar el servicio ahora y hacerlo bien después es buena ingeniería, no una concesión.

El problema nunca fue haberla hecho. El problema es que la palabra "temporal" se usa como si fuera una promesa, cuando en realidad es apenas una intención — y las intenciones no sobreviven a un cambio de prioridades, mucho menos a un cambio de personal.

Cómo se hace temporal de verdad

Que algo sea temporal no depende de cómo se llame, sino de que existan tres cosas desde el primer día:

• Una fecha, escrita el día que se instala. No "cuando se pueda". Un día del calendario. Si llega y no se retiró, al menos hay que decidirlo otra vez de forma consciente, que es muy distinto a que se quede solo.
• Un dueño del retiro, con nombre. No el área: la persona. El retiro necesita el mismo dueño que tuvo la instalación, o no ocurre.
• Registro donde duela, no donde sea cómodo. Un ticket cerrado no es registro; es un archivo. Va donde alguien lo vaya a ver aunque no lo esté buscando: la documentación de la configuración, el inventario, el tablero que se revisa cada mes.

Y la pregunta que resuelve el asunto en diez segundos, en el momento mismo de instalarla: ¿quién la va a quitar, y cuándo?

Si tienes las dos respuestas, es temporal. Si te falta cualquiera de las dos, no lo es — es permanente, y lo único que pasa es que todavía no lo sabes. Vale la pena aceptarlo en ese momento, porque una solución permanente que se asume permanente se documenta, se dimensiona y se hace bien. La que se sigue llamando temporal simplemente envejece sin que nadie la mire. Ese envejecimiento tiene precio, y lo desglosamos en el costo invisible de "por ahora déjalo así".

Así que la próxima vez que escribas "es temporal, mañana lo hacemos bien", vale la pena detenerse un segundo y preguntarse en serio: ¿lo es, o solo suena mejor que la alternativa?