El sistema que ya funciona y nadie quiere tocar
La mayoría del software pasa mucho más tiempo mantenido que construido, y esa es la parte que nadie planifica. Tomamos sistemas que ya están en producción: mantenerlos vivos, y sacarlos de las versiones que se están volviendo un pasivo.
Hablar con un ingenieroCómo llegan estos casos
- La persona que lo construyó se fue, y el conocimiento se fue con ella.
- Corre sobre una versión de framework que dejó de recibir parches de seguridad.
- Nadie se anima a actualizar una dependencia, así que la brecha crece todos los meses.
- Funciona, pero cada cambio lleva tres veces más de lo que debería.
- Lo construyó una agencia, el contrato terminó, y no hay a quién llamar.
- Se propuso una reescritura, se cotizó, y se abandonó en silencio por cara.
Qué hacemos
Hacernos cargo de un sistema ajeno
Leerlo, mapear lo que existe de verdad, y producir una descripción escrita de los riesgos antes de tocar nada. Heredar un código a ciegas es la forma en que el mantenimiento se convierte en una caída.
Cerrar la brecha de seguridad
Actualizaciones de dependencias y frameworks en pasos reversibles, priorizadas por exposición real y no por número de versión. PHP, Symfony, Laravel, Django, Node y Java, entre otros.
Modernizar sin reescribir
Ir sacando las partes riesgosas de a poco mientras el sistema sigue atendiendo tráfico. Las reescrituras completas fracasan lo bastante seguido como para ser la última opción y no la primera.
Volverlo mantenible
Pruebas donde no había, un despliegue que no dependa de una persona, y la instrumentación para ver qué hace en producción.
Soporte continuo
Un acuerdo mensual con tiempos de respuesta pactados para los sistemas que tienen que seguir funcionando, incluidos los que no construimos nosotros.
Trabajo típico
Heredar un sistema sin documentación
Reconstruir el comportamiento, escribir la arquitectura que existe, y producir una lista de riesgos priorizada. Suelen ser las dos semanas mejor invertidas de un equipo.
Actualizar un framework atrasado varias versiones
Subir por etapas, cada una desplegable y reversible, en lugar de un salto que no se puede deshacer.
Reemplazar un componente sin frenar el sistema
Derivar tráfico de a poco de lo viejo a lo nuevo detrás de un flag, con los dos corriendo hasta que el nuevo se lo haya ganado.
Migrar entre nubes o proveedores
AWS, GCP o infraestructura propia, con la migración de datos ensayada antes de la real.
Cubrir un sistema tras la salida de un equipo
Mantener algo vivo y publicando mientras el cliente contrata, sin quedarnos con el código de rehén.
Qué se lleva
- Un mapa escrito del sistema tal como es, no como dice el diagrama
- Una lista de riesgos ordenada por lo que más probablemente duela, con el esfuerzo de cada uno
- Actualizaciones aplicadas en pasos reversibles, cada una desplegada y verificada
- Pruebas e instrumentación agregadas donde los huecos eran más peligrosos
- Un traspaso que su equipo, o el siguiente, pueda retomar
Preguntas que nos hacen
¿Trabajan con un lenguaje que no figura como especialidad?
Habitualmente sí, y es acá donde menos importa. El trabajo de mantenimiento consiste sobre todo en leer código ajeno con cuidado, entender por qué se escribió así, y cambiarlo sin romper nada. Esa habilidad no depende del lenguaje. Hemos entregado trabajo en producción con Go, Python, TypeScript, PHP, Scala y Java. Si es algo que genuinamente no podemos sostener bien, lo decimos antes de que se comprometa y no después.
¿No sale más barato reescribirlo?
Casi nunca, y la estimación que dice lo contrario suele omitir el comportamiento que nadie documentó. Una reescritura tiene que alcanzar la paridad con años de casos límite acumulados antes de entregar algo nuevo. La modernización incremental entrega valor antes y se puede frenar en cualquier momento. En las pocas veces en que reescribir sí es el camino más barato, se lo decimos con todas las letras.
¿Y si los desarrolladores originales ya no están?
Ese es el caso común. No tener a quién preguntar es un arranque más lento, no un impedimento: el código es la especificación, y lo leemos.
¿Pueden estar de guardia sin construir nada?
Sí. Un acuerdo mensual de soporte con tiempos de respuesta pactados, para sistemas que deben seguir funcionando. Preferimos dedicar las primeras semanas a entenderlo bien, porque estar de guardia de algo que no leíste es una promesa que no se puede cumplir.
Iniciar una conversación
Cuéntenos qué están construyendo, o qué se está rompiendo. Va a recibir una respuesta directa de un ingeniero, no un libreto de ventas.