Todo CTO enfrenta el momento: el sistema legado se traga cada vez más tiempo, el equipo se queja de la base de código, y alguien propone reescribir desde cero. La tentación es real. Pero reescribir es la decisión más costosa que un CTO puede tomar sin datos.
El framework de decisión
Cuatro criterios guían la elección entre refactorizar y reescribir:
Cobertura de pruebas. Si el sistema tiene una cobertura de pruebas confiable, refactorizar es viable. Sin pruebas, cualquier cambio es una apuesta. Refactorizar código sin pruebas es como remodelar una casa sin cimientos.
Acoplamiento externo. Los sistemas con muchas integraciones (APIs, bases de datos, servicios de terceros) son peligrosos de reescribir. Cada integración es una superficie de error que debe reimplementarse y validarse.
Conocimiento vivo. Si nadie que creó el sistema sigue en la empresa, el conocimiento tácito se perdió. Reescribir sin ese conocimiento genera un sistema que repite los mismos errores de forma diferente.
Presión del negocio. Si el negocio necesita cambios rápidos que la arquitectura actual impide, reescribir puede justificarse. Pero solo si los cambios están bloqueados por la arquitectura, no por falta de personas.
Cuándo reescribir tiene sentido
Reescribir funciona cuando la tecnología base está obsoleta (lenguaje sin comunidad, framework sin soporte), cuando la arquitectura es fundamentalmente incompatible con el negocio actual, o cuando el costo de mantener el sistema existente excede el costo de construir uno nuevo.
Incluso en esos casos, reescribir incrementalmente con el patrón Strangler Fig reduce el riesgo. Envuelves el sistema antiguo con capas nuevas, migras funcionalidades una por una y mantienes el sistema funcionando durante la transición.
El costo oculto
Reescribir cuesta entre 3 y 5 veces más de lo estimado. No porque el equipo sea malo, sino porque reescribir incluye redescubrir decisiones de diseño que no están documentadas, reconstruir edge cases que nadie recuerda y reintegrar servicios que cambiaron mientras se construía el nuevo sistema.
La pregunta correcta no es "refactorizar o reescribir". Es "qué está impidiendo exactamente el negocio, y cuál es el cambio más pequeño que lo resuelve".
