Cada Cambio Tarda Más que el Anterior

Una funcionalidad pequeña tardaba tres días y ahora tarda tres semanas. Nadie se atreve a tocar el módulo de facturación. La única persona que entendía el despliegue se fue el año pasado. Eso no es mala suerte, es deuda técnica acumulando intereses, y tiene un tipo de interés medible. Auditamos el código, cuantificamos lo que la deuda te cuesta cada mes y te entregamos un plan de refactoring priorizado que avanza en paralelo a tu hoja de ruta en lugar de sustituirla.

¿Qué Cubre una Auditoría de Deuda Técnica?

• Auditoría de Código con Evidencias: Análisis estático más revisión manual de las partes que importan: complejidad ciclomática, duplicación, acoplamiento, código muerto y los módulos que tu histórico de git delata como temidos por todos. Cada hallazgo apunta a un fichero y una línea concretos, nunca a un vago "la arquitectura necesita trabajo".
• La Deuda Expresada en Dinero y Tiempo: Traducimos los hallazgos a las cifras con las que tu dirección decide de verdad: horas extra de desarrollo por sprint que causa cada foco de deuda, ralentización de la entrega, frecuencia de incidencias e infraestructura que estás sobrepagando. Una cifra convierte una queja de ingeniería en un caso de negocio.
• Revisión de Dependencias y Seguridad: Librerías desactualizadas, paquetes abandonados, vulnerabilidades conocidas y runtimes fuera de soporte. Separamos lo genuinamente urgente de lo que un escáner marcó en una dependencia que nunca invocas, para que tu equipo gaste el presupuesto de actualización donde está el riesgo real.
• Un Plan de Refactoring en Fases Entregables: Ordenado por retorno, no por cuánto nos ofende el código. Cada fase entra en un sprint normal, deja el sistema funcionando y se puede detener tras cualquier paso sin dejar el código a medio migrar. La reescritura de golpe es precisamente el modo de fallo que nos contratan para evitar.
• Modernización Legacy sin Reescritura: Patrón strangler, módulo a módulo: el código nuevo asume una responsabilidad cada vez detrás de una interfaz estable mientras el sistema antiguo sigue sirviendo todo lo demás. Los usuarios no ven interrupción, y puedes parar o revertir en cualquier momento porque ambas versiones conviven.
• Red de Seguridad Antes de Operar: Refactorizar sin tests es solo mover el riesgo de sitio. Añadimos tests de caracterización alrededor del código que vamos a cambiar, montamos CI para que una regresión se detecte en minutos, y documentamos qué hace realmente el módulo, que a menudo es el primer registro escrito que existe.

Cómo Funcionan la Auditoría y la Remediación

1. Acceso de Solo Lectura y Contexto: Obtenemos acceso de lectura al repositorio, al gestor de incidencias y a la monitorización, y entrevistamos a quien mantiene el sistema. El equipo ya sabe dónde están los cadáveres: la auditoría existe para demostrarlo con cifras y para encontrar lo que nadie había notado.
2. Análisis Automatizado: Complejidad, duplicación, acoplamiento, cobertura de tests, escaneo de dependencias y vulnerabilidades, más minería del histórico de git para encontrar los ficheros que cambian más a menudo y se rompen más a menudo. El solape de esas dos listas es el mapa de dónde te duele la deuda de verdad.
3. Revisión Manual Donde Cuenta: Las herramientas encuentran síntomas, no causas. Leemos a mano los caminos críticos: autenticación, facturación, todo lo que toca dinero o datos personales, y las integraciones que fallan en silencio. Aquí es donde una auditoría deja de ser un informe y empieza a ser útil.
4. Valoración y Priorización: Cada hallazgo recibe un esfuerzo estimado de remediación y un coste mensual estimado de no tocarlo. Ordenar por la relación entre ambos produce el plan, y suele sorprender: el código más feo no es a menudo el más caro.
5. Informe y Sesión de Decisión: Recibes los hallazgos, los costes y el plan por fases, y lo recorremos contigo con tus perfiles técnicos y de negocio en la misma sala. Algunos puntos decidirás no arreglarlos nunca, y es un resultado legítimo: lo importante es que pase a ser una decisión en lugar de un accidente.
6. Ejecución Incremental (Opcional): Si quieres que lo ejecutemos, trabajamos por fases en paralelo a tu hoja de ruta: primero los tests, luego el refactor, luego la medición que demuestra que la fase se pagó. Puedes parar tras cualquier fase, y tu equipo puede tomar el relevo en cualquier momento porque el plan está documentado, no en nuestras cabezas.

Lo que Cuesta la Deuda Mientras la Aplazas

Estos son los cuatro costes que medimos en cada auditoría. El patrón es siempre el mismo: la deuda nunca es lo más urgente de la lista, y precisamente por eso no deja de crecer.

• Velocidad de entrega: La misma funcionalidad, el triple de estimación: La duplicación y el acoplamiento hacen que un cambio haya que hacerlo en cuatro sitios, y nadie tiene la certeza de haber encontrado los cuatro. La estimación se infla para cubrir la incertidumbre, y el sprint absorbe la diferencia. (Estimaciones infladas por miedo → Estimaciones basadas en el trabajo)
• Incidencias: Producción se rompe en los mismos tres sitios: Sin tests, cada despliegue es una apuesta. El equipo aprende a desplegar los martes por la mañana y a evitar ciertos módulos por completo, que es un apaño para el problema, no una solución. (Despliegues temidos y aplazados → Despliegues aburridos y frecuentes)
• Infraestructura: Pagar servidores para tapar una consulta: Escalar hacia arriba es la forma más rápida de volver invisible un problema de rendimiento, y la más cara de conservarlo. En la mayoría de auditorías, un puñado de consultas sin índice y bucles N+1 explican la mayor parte de la factura mensual de cloud. (Instancias sobredimensionadas como analgésico → Capacidad ajustada a la carga real)
• Personas: Conocimiento que vive en una sola cabeza: La incorporación tarda meses, las vacaciones se convierten en riesgos y una baja puede parar una hoja de ruta. El código sin documentar es un problema de retención disfrazado de problema técnico, y empeora cada trimestre. (Una persona es la documentación → Cualquiera puede coger el módulo)

Stacks que Auditamos y Modernizamos

Trabajamos sobre las plataformas en las que están construidos de verdad la mayoría de sistemas legacy en España, y auditamos código que hoy no elegiríamos: el objetivo es mejorar lo que existe, no mudarlo a nuestro framework favorito.

Preguntas Frecuentes

¿Esto va a acabar con vosotros diciéndonos que lo reescribamos todo?

Casi nunca, y tratamos esa recomendación como último recurso. Las reescrituras completas se desbordan, pierden comportamiento que nadie documentó y congelan el producto durante meses mientras la competencia sigue entregando. En el caso raro en que una reescritura sea genuinamente más barata, te mostraremos la aritmética que nos llevó ahí en lugar de afirmarlo.

¿Tenemos que parar el desarrollo de funcionalidades durante la auditoría?

No. La auditoría es de solo lectura y no toca tu repositorio ni tus despliegues, así que tu equipo sigue trabajando con normalidad. En la fase de remediación trabajamos por fases que entran en tus sprints actuales, lo cual es más lento que una congelación pero es la única versión que sobrevive al contacto con un negocio real.

Nuestro código da vergüenza, ¿es un problema?

Es el caso normal. El código que se ve mal suele haber llegado ahí porque el negocio necesitaba entregar algo, que es un intercambio defendible en su momento. No estamos ahí para juzgar decisiones tomadas bajo presión de plazos, estamos para poner precio a lo que esas decisiones cuestan ahora y decirte cuáles merece la pena revertir.

¿Cuánto cuesta una auditoría de deuda técnica?

Una auditoría enfocada de una sola aplicación suele ir de 3.000 a 6.000 euros, y un parque multiaplicación o de microservicios desde 8.000 euros según cuántos repositorios entren en alcance. La remediación se presupuesta aparte por fases, así que nunca te compromete el plan completo de golpe. La primera consulta es gratuita.

No construimos el sistema nosotros, ¿podéis auditarlo igual?

Sí, y los sistemas heredados son buena parte de este trabajo. No necesitamos al equipo original, solo acceso de lectura al código y al histórico que exista. Cuando no hay documentación en absoluto, reconstruir qué hace realmente el sistema pasa a ser el primer entregable, y normalmente ya justifica por sí solo el coste de la auditoría.

¿Firmáis un acuerdo de confidencialidad antes de ver nuestro código?

Sí, antes de conceder cualquier acceso, y no tenemos problema en trabajar con el vuestro en lugar del nuestro. El acceso es de solo lectura, limitado a las personas que hacen la auditoría, y se revoca al terminar. No conservamos copia de tu repositorio tras la entrega salvo que nos lo pidas para una fase de remediación.