Toda empresa con años de historia tecnológica ha tenido alguna vez esta conversación:
Sprint Planning, lunes por la mañana…
—Necesitamos hacer esta corrección al sistema, pero, ¿alguien sabe por qué el módulo de conciliación hace eso?
—Ahhh, eso lo desarrolló Pedro.
(silencio en la sala)
—¿Pedro, el ingeniero que se fue hace tres años?
Lo siguiente suele ser conocido: semanas revisando repositorios, buscando a quien “se acuerde” y reuniones para reconstruir una lógica que alguna vez estuvo clara en la cabeza de una persona.
Solemos tratar esto como una incomodidad del día a día. Este artículo propone verlo como lo que es, un riesgo operacional que algunas veces puede salir muy caro.
45 minutos, US$460 millones a la basura
El 1 de agosto de 2012, Knight Capital, una de las mayores firmas de trading de Estados Unidos, activó una actualización de su sistema de enrutamiento de órdenes. Según la investigación posterior de la SEC, pasó esto:
- El sistema tenía una funcionalidad antigua, llamada Power Peg, que la empresa había dejado de usar en 2003. El código nunca se eliminó del todo y seguía en los servidores de producción.
- El desarrollo nuevo reutilizó un indicador (flag) que antes servía para activar esa funcionalidad antigua.
- En el despliegue, un técnico no copió el código nuevo en uno de los ocho servidores. En ese servidor el flag hizo lo que hacía nueve años antes: despertó a Power Peg.
En unos 45 minutos el sistema generó millones de órdenes no deseadas, con más de 4 millones de ejecuciones sobre 154 acciones. La pérdida fue de US$460 millones. La empresa necesitó un rescate de emergencia y al año siguiente fue absorbida por otra firma.
El informe de la SEC deja una frase que conviene leer despacio: Knight no tenía procedimientos escritos para el desarrollo y despliegue de ese sistema, y no exigía que un segundo técnico revisara los despliegues.
No hubo ningún sabotaje ni un error exótico. Hubo algo que la organización sabía nueve años antes y que, en el momento que importaba, nadie tenía presente.
No es la tecnología vieja: es la memoria
Es tentador leer casos así como un argumento para “modernizar”, como si el problema fuera la edad del código. Pero el código antiguo que funciona es un activo: lleva años resolviendo problemas reales.
El riesgo está en otra parte: en la distancia entre lo que el sistema hace y lo que la organización sabe que hace.
Esa distancia crece sola con el tiempo:
- Las personas rotan, y con ellas se va el contexto.
- Las decisiones se toman en reuniones, correos o tickets, y nunca llegan a la documentación.
- Las excepciones se programan “por esta vez” y quedan para siempre.
- La documentación, cuando existe, describe el sistema como era, no como es.
Así aparecen los clásicos que cualquier líder de tecnología reconoce: el proceso que corre a las 3 de la mañana y nadie sabe por qué, la función que “mejor no tocar”, el comentario en el código que dice “revisar con…” alguien que se fue hace años.
Por qué esto es un tema de gobernanza
Cuando los reguladores británicos multaron al banco TSB con £48,65 millones por una migración tecnológica que afectó durante meses a buena parte de sus 5,2 millones de clientes, su diagnóstico no habló de lenguajes de programación. Dijeron que la empresa no planificó adecuadamente y que la gobernanza del proyecto no fue suficientemente robusta.
La lección se repite: en una organización con años de historia, saber qué hace el sistema y qué depende de qué no es un detalle técnico. Es parte de la capacidad de la empresa para cambiar sin romperse. Si ese conocimiento vive solo en algunas personas, la empresa tiene un punto único de falla, aunque no aparezca en ningún mapa de riesgos.
La respuesta tradicional (y por qué no alcanza)
La reacción habitual es “hay que documentar”. Es correcta, pero tiene dos problemas:
- Llega tarde. Documentar un sistema de 20 años es un proyecto en sí mismo, y compite con todo lo demás.
- Se desactualiza. La documentación escrita a mano empieza a envejecer el día en que se termina. El código sigue cambiando y el documento no.
El resultado es conocido: cada cambio importante empieza con una etapa de arqueología. Se revisan repositorios, se busca a quien sepa y se agendan reuniones, antes de escribir una sola línea.
Cómo lo resolvemos en Tinet: una memoria que se mantiene sola
Suite Loica parte de una idea simple: el conocimiento crítico no puede depender de que alguien se acuerde.
Por eso su base es la KDB, la memoria de la empresa. Es una base de conocimiento que guarda el código, las reglas y las decisiones de la organización. Tiene dos características que la separan de la documentación tradicional:
- Se actualiza sola: Cada vez que cambia el código. No envejece.
- Vive solo en la infraestructura del cliente: En sus computadores o en su nube.
Sobre esa memoria trabaja GenDEV. Antes de tocar nada, responde las preguntas que hoy toman semanas: qué ya existe y se puede aprovechar, qué depende de qué y qué se va a ver afectado con el cambio. El resultado es un plano técnico para cada tarea, conectado al sistema real y no a cómo alguien recuerda que funcionaba.
Después de programar, GenQA prueba la aplicación como lo haría un usuario y deja evidencia en fotos y video de cada prueba. Si algo falla, no se publica.
Y en cada etapa decide una persona: Loica propone y el equipo aprueba. Cada cambio guarda su historia, quién lo pidió y para qué. Es el registro que hoy falta en la mayoría de las organizaciones y que un regulador espera encontrar.
En la práctica, entender una idea nueva sobre un sistema existente pasa de tomar unas dos semanas a unas 2,5 horas. Pero el beneficio de fondo no es la velocidad: es que la respuesta a “¿qué se rompe si tocamos esto?” deja de depender de una persona.
Tres preguntas para hacerse esta semana
- ¿Quiénes son sus “Pedros”? Haga una lista de las personas, actuales o que ya se fueron, sin las cuales ciertos cambios simplemente no se hacen. Cada nombre es un riesgo concentrado.
- ¿Cuánto tarda hoy en responder “qué se rompe si tocamos esto”? Tome el último cambio relevante y mida cuánto tiempo pasó levantando contexto antes de empezar a construir.
- ¿Qué código tiene que nadie se atreve a tocar? Si existe (y casi siempre existe), no es un código estable: es conocimiento que se perdió.
Para cerrar
Knight Capital no cayó por usar tecnología antigua, cayó porque su sistema recordaba algo que la organización había olvidado. Toda empresa con años de historia tiene su Pedro, alguien cuyo conocimiento se fue con él. La diferencia está en si lo descubre al planificar un cambio o cuando ya está en producción.
Construimos Suite Loica para que sea lo primero. Si quiere verlo funcionando, le proponemos 45 minutos con nuestro equipo, sobre su código real y sin presentaciones. La primera conversación es un diagnóstico, no una demo.
