Un cliente me llamó no porque algo se hubiera roto, sino porque algo casi se rompió. Su sistema de procesamiento de pedidos —el único software que decide si una venta realmente se despacha— había funcionado sin un solo incidente importante durante seis años. Entonces el único desarrollador que realmente entendía ese sistema, llamémoslo Diego, porque ese no es su nombre real, presentó su renuncia un viernes por la tarde, con quince días de aviso.
Nadie entró en pánico de inmediato. El sistema funcionaba. Había funcionado toda la semana, todo el mes, todo el año. Iba a seguir funcionando el lunes también, con o sin Diego. Ese era exactamente el problema: que "todavía funciona" no les decía absolutamente nada sobre qué iba a pasar la primera vez que necesitara un cambio, o se rompiera, una vez que él ya no estuviera.
Escucho alguna versión de "si todavía funciona, ¿para qué tocarlo?" en casi todas las conversaciones sobre modernización que tengo con dueños de empresas, y es una pregunta completamente razonable. El software que funciona tiene valor, y cambiarlo implica un riesgo real. Pero la pregunta esconde un supuesto que vale la pena revisar: que "todavía funciona" y "está bien" significan lo mismo. En mi experiencia, casi nunca es así.
Qué mide en realidad "todavía funciona"
"Todavía funciona" significa que el sistema procesó las transacciones de hoy igual que procesó las de ayer. Eso es todo. No dice nada sobre si la tecnología de base todavía recibe soporte, sobre si el conocimiento de una sola persona es lo único que separa "funcionando" de "roto", ni sobre cuánto va a costar el próximo cambio necesario. Esas preguntas viven en un eje completamente distinto, y un sistema puede estar mal parado en las cuatro y, al mismo tiempo, procesar cada pedido correctamente, todos los días, durante años.
La brecha entre funcionar y estar sano
Cuatro cosas suelen separar a un sistema que simplemente funciona de uno que realmente está sano, y ninguna de las cuatro aparece en la operación diaria hasta que aparece:
Dependencias sin soporte. Una librería, una versión de base de datos o un framework del que depende el sistema deja de recibir actualizaciones de seguridad. Nada cambia visiblemente el día que eso ocurre. El sistema funciona exactamente igual al día siguiente de que termine el soporte que al día anterior. El riesgo es silencioso hasta que aparece una vulnerabilidad que nadie va a parchear.
Puntos únicos de falla. La situación de Diego es la versión humana de esto, pero también aparece en la infraestructura: un servidor sin respaldo, una integración sin documentar que solo una persona sabe arreglar. El sistema no muestra ningún punto débil visible, hasta que la única pieza de la que depende desaparece.
Costo de cambio creciente. Todo sistema acumula pequeños atajos con los años: una solución provisoria acá, un campo reutilizado para algo para lo que no fue pensado allá. Nada de eso rompe algo por sí solo. Pero cada cambio nuevo tiene que lidiar con todo lo que vino antes, así que el mismo tipo de pedido que hace cinco años tomaba un día ahora, en silencio, toma una semana, y nadie presupuestó esa deriva.
Un mercado de contratación cada vez más chico. Los frameworks y lenguajes más viejos siguen funcionando perfectamente bien, pero cada vez menos desarrolladores quieren construir una carrera en ellos. Eso no es un problema mientras su equipo actual siga en su lugar. Se vuelve un problema muy caro el día que necesitás contratar, y descubrís que el grupo de personas que puede trabajar con confianza en ese sistema es una fracción de lo que era antes.
Por qué este riesgo permanece invisible hasta que deja de serlo
Estas cuatro cosas comparten un rasgo: no cuestan nada en un día cualquiera. Un sistema con una dependencia sin soporte funciona idéntico a uno que no la tiene, hasta el día en que no. Un sistema con un solo experto irremplazable funciona bien, hasta que esa persona no está disponible. Por eso "si todavía funciona, ¿para qué tocarlo?" suena como una pregunta razonable en el momento en que se hace: todavía no hay ningún síntoma visible al que señalar. El costo de estos riesgos no aparece en una línea de tiempo hasta el día que aparece todo de golpe.
Una lista breve y honesta
Nada de esto significa que todo sistema que funciona necesite una revisión a fondo, y no es motivo para entrar en pánico. Es motivo para mirar, con claridad, un par de preguntas concretas:
- ¿Hay más de una persona que podría arreglar este sistema bajo presión, este mismo mes?
- ¿Las dependencias centrales (framework, base de datos, librerías principales) todavía reciben actualizaciones de seguridad?
- ¿Un cambio reciente, de los "chicos", tardó notablemente más que lo que hubiera tardado hace unos años?
- Si publicara hoy una búsqueda para mantener este sistema, ¿cuánto tiempo tomaría realmente esa búsqueda?
Si la mayoría de esas respuestas son tranquilizadoras, esa es una muy buena noticia: significa que el sistema no solo funciona, está sano. Si una o dos respuestas te hacen dudar, no es una emergencia. Es información útil, del tipo que una auditoría breve y enfocada puede convertir en un plan concreto en lugar de en una preocupación vaga.
La parte tranquilizadora
Un sistema que todavía funciona es un activo, no un pasivo: los años que lleva funcionando sin fallar son evidencia real de que se construyó razonablemente bien. El objetivo de preguntar si está realmente sano, o solo funciona, no es convencer a nadie de una reescritura que no necesita. Es reemplazar una inquietud vaga por una lista concreta y respondible, para que la decisión de dejar el sistema como está —que muy a menudo es la decisión correcta— sea una decisión tomada a propósito, y no simplemente algo que nunca se terminó de mirar.
La empresa de Diego, para que conste, aprovechó bien su período de aviso: lo usaron para documentar lo que él sabía y asegurarse de que una segunda persona pudiera ocupar su lugar. El sistema no necesitaba una reescritura. Necesitaba exactamente eso: que alguien notara el punto único de falla mientras todavía había tiempo de resolverlo, y no un momento después.