Reescribir desde cero: la trampa que deja dos sistemas en producción

Simon Willison, conocido por su blog y por su trabajo en el ecosistema Python, ha publicado una advertencia contra la estrategia de reescribir desde cero un sistema cargado de deuda técnica. En respuesta a un comentario en su blog, sostiene que ese enfoque casi nunca funciona y suele terminar con dos sistemas en producción en lugar de uno renovado. Desarrolla el patrón típico: el sistema antiguo sigue siendo crítico para el negocio, así que sigue recibiendo cambios, aunque sus responsables saben que será sustituido y no se esfuerzan en hacerlos bien, acumulando más deuda. El equipo del nuevo sistema, más ambicioso pero menos consciente del alcance, descubre que nadie entiende por completo el sistema heredado. Si hubiera estado bien documentado y probado, probablemente no necesitaría ser reemplazado. Tras meses o años sin entregar valor, la presión obliga a lanzar el nuevo sistema para cubrir solo una parte de las funciones, o para alguna característica nueva que era demasiado difícil de añadir al sistema antiguo. Resultado: dos sistemas coexisten en producción, uno al que nadie quiere tocar y otro que todavía no lo reemplaza.

Willison advierte de que, si la empresa no pierde la paciencia con el nuevo sistema y lo abandona, se queda con dos sistemas donde antes había uno. Su recomendación para quien se enfrente a este escenario es mucho menos glamurosa: reforzar el sistema existente con un conjunto amplio de pruebas automatizadas y luego emprender refactorizaciones dirigidas a la forma deseada. En su experiencia, esa vía tiene una probabilidad de éxito mucho mayor que la llamada del desarrollo en campo abierto. Y para completar el proceso con responsabilidad, recomienda el artículo de Will Larson sobre migraciones, que considera la mejor guía que ha leído al respecto.

Aunque cada caso es distinto, el mensaje encaja con lo que muchas organizaciones aprenden tras intentar "quemar y reescribir". La deuda técnica no se paga eliminándola: se paga entendiendo qué hace cada pieza y poniendo pruebas que lo aseguren, antes de cambiar nada. Si el sistema heredado es opaco y frágil, tal vez necesite más tests y menos romanticismo.