Por defecto, refactorizar. Una reescritura solo se justifica cuando el sistema existente ya no puede evolucionar para cumplir los requisitos a un coste aceptable, y puedes seguir entregando valor mientras lo haces. La mayoría de los instintos de "necesitamos una reescritura" son en realidad un problema de tech debt no gestionada que el refactor incremental resuelve con mucho menos riesgo.
| Señal | Inclinarse a refactor | Inclinarse a reescritura |
|---|---|---|
| La arquitectura encaja con los requisitos | Sí | No |
| Cobertura de tests/especificación | Baja o alta | Suficiente para verificar paridad |
| Se puede entregar incrementalmente | Sí | Difícil, de golpe |
| El equipo entiende el código | Sí | No, y los autores originales se fueron |
La decisión de refactor vs. reescritura es una de las de mayor apalancamiento que toma un Tech Lead. Equivócate hacia la reescritura y puedes congelar la entrega un año y aun así fracasar; equivócate hacia el refactor y sangras velocidad lentamente. Enmarcarla como una decisión de coste y riesgo, no de gusto, es lo que separa el criterio senior de la preferencia.