¿Qué es la trampa de la reescritura?
Cultura de ingeniería y práctica de software
La trampa de la reescritura es la creencia recurrente de que la forma más rápida de mejorar un sistema de software con problemas es desecharlo y construir un reemplazo limpio desde cero. El problema es que el código nuevo parte con menos conocimiento del mundo real, menos correcciones de errores incorporadas y un largo período en el que el equipo recrea capacidades antiguas en lugar de entregar valor nuevo. Las reescrituras pueden estar justificadas, pero son más raras y arriesgadas de lo que suele sugerir el primer planteamiento.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
El sistema antiguo se siente lento, feo y agotador. Un repositorio en blanco parece limpio, prometedor y lleno de herramientas modernas. Ese contraste emocional es poderoso. También es profundamente engañoso. Un comienzo desde cero es más fácil de admirar que de terminar.
La trampa funciona porque la fase inicial de una reescritura parece rápida. Claro que sí. El nuevo sistema todavía no ha redescubierto las integraciones oscuras, los comportamientos extraños de los clientes, los problemas con datos históricos ni todas las correcciones de errores poco glamurosas que viven dentro del código antiguo. Durante un tiempo, el equipo confunde "pequeño" con "mejor".
Por qué importa
Importa porque hojas de ruta de ingeniería enteras se han hundido por la promesa de un borrón y cuenta nueva. Cuando una reescritura congela la entrega de funcionalidades, divide al equipo entre el sistema antiguo y el nuevo, y consume meses reconstruyendo comportamientos ya conocidos, el coste no es solo técnico. Afecta a los clientes, a la confianza, a la contratación, a la moral y al ritmo competitivo.
También importa porque el lenguaje de la reescritura suele sonar razonable en las reuniones. Se dice que la plataforma antigua ya no escala, que nadie entiende el código o que la productividad de los desarrolladores se está desplomando. Todo eso puede ser cierto. La trampa está en asumir que esos hechos implican automáticamente un reinicio completo, cuando muchos de los bloqueos reales son más específicos y a menudo pueden abordarse de forma más gradual.
Cómo funciona
Por qué las reescrituras son tan tentadoras
Los programadores son constructores. Ante un edificio desordenado, muchos sienten el impulso instintivo de derribarlo y levantar algo elegante. Joel Spolsky describió esa tentación de forma memorable hace años. Leer código antiguo es difícil, escribir código nuevo es emocionante, y el cerebro humano es muy bueno confundiendo la emoción personal con la sabiduría estratégica.
Los sistemas antiguos tampoco se defienden bien solos. Su conocimiento duramente ganado está enterrado en condicionales, migraciones, comentarios, incidentes en producción y soluciones provisionales olvidadas. Mientras tanto, el nuevo sistema imaginado existe solo como diagramas e intenciones. Un lado parece feo porque es real. El otro parece hermoso porque todavía es en gran medida ficción.
Qué se pierde en una reescritura
Lo primero que se pierde es el tiempo. Mientras el equipo reconstruye el comportamiento existente, los competidores y los clientes siguen viviendo en el presente. Lo segundo es la retroalimentación. Una reescritura suele crear un largo período en el que el equipo no puede entregar fragmentos significativos porque todavía falta demasiada base.
La tercera pérdida es el conocimiento incorporado. El código antiguo contiene correcciones de errores que no se anuncian como sabiduría. Un fragmento complicado de manejo de FTP, una ruta de importación extraña, una regla de validación de pagos bizarra: todos pueden existir porque alguien aprendió por las malas cómo se comportan los sistemas reales en producción. Cuando se reescribe, no se elimina la complejidad; a menudo solo se aplaza su redescubrimiento.
También existe una división organizativa. Alguien debe mantener el sistema antiguo en funcionamiento mientras se construye el nuevo. Eso tiende a crear dos categorías de trabajo: el glamuroso futuro y el presente ignorado. Las personas que se quedan con el sistema antiguo pueden sentirse abandonadas, y las que construyen el nuevo pueden ir perdiendo gradualmente el contacto con lo que los usuarios realmente necesitan hoy.
Cuándo una reescritura es razonable, y qué es más seguro que el gran salto
Una reescritura no siempre es una imprudencia. A veces la plataforma está verdaderamente obsoleta, las restricciones legales u operativas son graves, los modelos de datos se han vuelto inviables, o la arquitectura bloquea un cambio estratégico que la evolución incremental no puede alcanzar de forma realista. Pero una reescritura justificada aún necesita ganarse su lugar. Requiere un plan de migración, un plan de coexistencia, fragmentos claros de valor y un análisis sobrio de lo que el sistema antiguo ya sabe.
Por eso los equipos con experiencia prefieren patrones de reemplazo gradual cuando pueden. El enfoque del higo estrangulador reemplaza partes de un sistema heredado a lo largo del tiempo, en lugar de apostar toda la transición a un único corte dramático. La ramificación por abstracción crea una capa que permite que las implementaciones antigua y nueva coexistan mientras el sistema sigue construyéndose y entregando. La arquitectura de transición reconoce una verdad incómoda: que puede ser necesario un andamiaje temporal que se tiene plena intención de desechar más adelante.
También existe una alternativa menos teatral que los líderes suelen olvidar: la limpieza deliberada. Joel la describió en su trabajo sobre FogBugz años después de advertir contra las reescrituras completas de sistemas. En lugar de descartar todo, dedicó un período corto y acotado a remodelar la estructura interna manteniendo el software en funcionamiento continuo. La idea clave no era el glamur. Era preservar el comportamiento y las opciones disponibles.
La trampa de la reescritura, entonces, no es "las reescrituras están prohibidas". Es "reescribir parece más sencillo que entender". En cuanto una propuesta empieza a prometer que el nuevo sistema será por fin limpio, rápido de construir, fácil de probar, más fácil para contratar, nativo en la nube, más escalable y además más rápido que una evolución cuidadosa, la trampilla ya está crujiendo.
Ejemplos
Un equipo que mantiene una gran aplicación interna decide reconstruirla en un lenguaje de moda porque la plataforma actual les resulta vergonzosa. Seis meses después, el nuevo código gestiona los casos sencillos a la perfección. Mientras tanto, la aplicación antigua sigue albergando los flujos de trabajo complicados que realmente importan, por lo que ambos sistemas necesitan personal.
Un grupo de producto quiere pasar de una aplicación grande y única a muchos servicios más pequeños. La migración se plantea como una reescritura porque eso suena más limpio que admitir que hay varios problemas separados: velocidad de despliegue, límites de pruebas, propiedad y preocupaciones de escalado. Al agruparlos todos, el equipo crea un proyecto demasiado grande para aprender de él con rapidez.
Un directivo aprueba una "reescritura de paridad", es decir, el nuevo sistema hará todo lo que hace el antiguo, pero sobre mejor tecnología. Esa frase suena segura y sensata. En la práctica, a menudo oculta el encargo más difícil posible: reproducir años de comportamiento exactamente, sin ofrecer ningún beneficio evidente al cliente hasta el final.
Malentendidos frecuentes
A veces la gente escucha "trampa de la reescritura" y concluye que las reescrituras nunca deberían ocurrir. Eso es demasiado absoluto. Algunos reemplazos son necesarios. El verdadero problema es si el equipo está afrontando la migración con honestidad.
Otro malentendido es que la velocidad inicial demuestra que la reescritura fue la decisión correcta. La velocidad temprana a menudo solo significa que el nuevo sistema todavía no ha encontrado las partes complicadas que ralentizaban al antiguo.
También es un error pensar que refactorizar significa preservar todo para siempre. La evolución cuidadosa puede implicar reemplazar grandes secciones de código, cambiar la arquitectura o abandonar tecnologías obsoletas. La diferencia es que el valor y el conocimiento se trasladan en fragmentos, no en un salto heroico único.
Y la paridad de funcionalidades no es un objetivo modesto. A menudo es el más traicionero, porque le pide a un sistema nuevo que reapprenda todo lo que el antiguo ya sabe antes de que el negocio vea un beneficio significativo.
Riesgos y límites
La expresión puede convertirse en su propio dogma. A veces los equipos se aferran demasiado tiempo a sistemas dolorosos porque "las reescrituras siempre fracasan" se ha convertido en un artículo de fe. Eso puede ser tan cegador como el error contrario. El pragmatismo importa más que los eslóganes.
Aun así, los líderes deberían notar con qué frecuencia el discurso de la reescritura es en realidad una petición de alivio. Los ingenieros pueden estar intentando decir que las pruebas son demasiado débiles, la arquitectura demasiado enredada, los tiempos de compilación demasiado largos o la propiedad demasiado difusa. Si se responde a todo ese conjunto de problemas únicamente con "nueva plataforma", se está tratando el estado de ánimo y descuidando el diagnóstico.
Qué hacer a continuación
Si llega a su mesa una propuesta de reescritura, pregunte qué restricción específica elimina que no pueda abordarse de otra manera. Pregunte qué comportamiento real contiene el sistema antiguo, cómo migrarán los usuarios y los datos, quién mantiene el sistema actual en buen estado y qué puede entregarse en el primer fragmento delgado. Si nadie puede responder esas preguntas, lo que tiene delante es un deseo, no un plan.
Prefiera el reemplazo gradual siempre que sea posible. Invierta en puntos de unión, pruebas más sólidas, abstracciones que permitan que los caminos antiguo y nuevo coexistan, y una secuencia de hitos visibles. Las grandes promesas no son una estrategia de migración.
Sobre todo, no recompense la novedad por sí sola. Los equipos que saben que solo serán reconocidos por trabajo en proyectos nuevos seguirán intentando escapar de los sistemas difíciles en lugar de mejorarlos. El mantenimiento, el desplazamiento cuidadoso y la simplificación poco glamurosa deben contar como logros de ingeniería de alto nivel.
¿Tiene alguna pregunta o sugerencia, o quiere entender cómo investigamos y revisamos estas guías? Lea sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Es una reescritura siempre un error?
No. Algunos sistemas sí necesitan ser reemplazados. El error está en tratar el reemplazo como algo automáticamente más limpio, más barato o más rápido que una evolución cuidadosa.
¿Cuál es la diferencia entre una reescritura y una refactorización?
Una reescritura recrea el comportamiento en una nueva base de código o en una implementación nueva importante. Una refactorización cambia la estructura con el objetivo de preservar el comportamiento en su lugar.
¿Por qué las reescrituras parecen rápidas al principio?
Porque el nuevo sistema empieza siendo pequeño y todavía no ha redescubierto los casos límite complicados, las integraciones y el historial de datos que pesan sobre el antiguo.
¿Qué es el enfoque del higo estrangulador?
Es un patrón de reemplazo gradual en el que la nueva capacidad crece alrededor y a través del sistema antiguo hasta que las partes antiguas pueden retirarse pieza por pieza.
¿Puede una startup reescribir con seguridad?
A veces sí, especialmente si el producto todavía es pequeño y el comportamiento es limitado. Cuantos más usuarios, datos, integraciones e historial de cumplimiento se acumulen, mayor es el riesgo.
¿Cuál es la primera señal de advertencia de la trampa?
Generalmente, una propuesta que agrupa muchas quejas en una única respuesta mágica: nuevo lenguaje, nueva arquitectura, nueva productividad y la promesa de que todo será más rápido.