Reescribir desde cero: 'sujétame el cubata'

Publicado el 10 de abril de 2026  •  12 minutos  • 2412 palabras

Todos los desarrolladores oyen esa vocecita tarde o temprano.

Aparece una tarde cualquiera, después de pelear con un trozo de código que parece escrito con rencor, y susurra algo así como: “esto está hecho un cristo; si me dejan un par de semanas, lo rehago desde cero y lo dejo niquelao”. Habla con la seguridad del que ya ha perdido la paciencia, con cierto desprecio por todo lo que hay construido y con una fe casi religiosa en ese “nuevo yo” que ahora sí, por fin, sabe hacer las cosas bien.

A ese impulso yo lo llamo el síndrome de “sujétame el cubata”.

Es una mezcla muy concreta de orgullo, hartazgo y amnesia selectiva. Orgullo porque, claro, ahora ya “sabemos más” que cuando se escribió aquello. Hartazgo porque llevas meses parcheando un sistema que huele a código viejuno desde la línea uno. Y amnesia porque convenientemente se te olvida todo el dolor, la cantidad de decisiones, compromisos y sustos en producción que han dejado cicatrices en ese código que ahora desprecias.

El escenario clásico del desastre

La historia suele empezar siempre igual. Hay un sistema viejo, feo y con demasiados años encima. Se han ido acumulando parches, soluciones de urgencia, funcionalidades urgentes para ayer. Los logs parecen psicofonías, la base de datos tiene tablas con nombres que ya nadie recuerda quién diseñó, y la documentación… bueno, la documentación es esa carpeta en el repo que todos miran con respeto, pero que nadie se atreve a abrir.

En una de esas tardes especialmente malas, después de pelearte con una función de 800 líneas, lanzas la frase maldita: “Es que esto habría que reescribirlo entero”.

Y a veces cuela.

Hay una anécdota célebre que se ha convertido casi en fábula de “lo que no hay que hacer”: el intento de Netscape de reescribir su navegador desde cero . Decidieron tirar el código existente, empezar un proyecto nuevo y, mientras tanto, el navegador viejo se quedó sin cariño, sin mejoras y sin rumbo. Microsoft, con su Internet Explorer, aprovechó el regalo. Mientras los ingenieros de Netscape estaban ocupados diseñando el futuro perfecto, el presente se les desangraba en mercado y usuarios. Cuando el nuevo producto estuvo “listo”, el mundo había cambiado de dueño.

La moraleja es bastante cruel: tu reescritura perfecta puede llegar tarde a una fiesta a la que ya no te han invitado.

Por qué subestimamos lo que ya existe

No es el único caso. Es un patrón que se repite en startups y en grandes empresas por igual. Un equipo se harta de un monolito insoportable, decide que la solución es hacer uno nuevo – más bonito, más limpio, más modular, esta vez sí – y promete que, en unos meses, sustituirá al viejo. Esos meses se convierten en un par de años . El producto viejo sigue generando negocio, sigue cambiando, sigue acumulando parches… y el nuevo siempre está “a un par de sprints” de poder ir a producción.

El problema de reescribir desde cero no es solo técnico, es profundamente humano. Cuando miras código viejo, lo juzgas con los ojos de hoy pero con memoria de ayer. Ves “malas decisiones” donde en realidad había prisas, restricciones técnicas, falta de experiencia o simplemente contexto distinto. Y, sobre todo, se te olvida que ese amasijo de código ya pasó por batallas que el sistema nuevo todavía ni sospecha: bugs corregidos, casos raros de negocio, condiciones absurdas de clientes grandes que quedaron embebidas en un if perdido.

Además, hay un pequeño truco mental: sabemos ver muy bien la complejidad del código viejo, pero infravaloramos brutalmente la complejidad del nuevo . Y cuando dices “no tardamos tanto, si al final tampoco hace tantas cosas”, lo que suele pasar es que estás contando solo las visibles, las bonitas, las que salen en las demos. Se te olvidan los detalles sórdidos: los informes raros que solo usa una persona del departamento financiero en marzo, el endpoint jurásico que necesita un partner que aún está en integración, la exportación a CSV con un formato absurdo que solo existe para contentar a un cliente grande.

Reescribir desde cero implica reimplementar no solo el happy path, sino todos esos callejones oscuros llenos de comportamiento extraño que el sistema actual ha ido aprendiendo a base de golpes. Y muchos de ellos ni siquiera están escritos en ningún sitio que no sea el propio código.

El coste real de darle al botón rojo

Por eso suele ser un error carísimo: paras o frenas el desarrollo de nuevas funcionalidades, duplicas esfuerzo (mantener lo viejo mientras construyes lo nuevo), introduces toneladas de bugs que ya estaban resueltos en el sistema original y, con suerte, acabas en un punto similar… pero dos años más tarde y con menos moral. En el peor de los casos, mueres por el camino, financieramente o por pura fatiga de equipo.

No es solo una cuestión de horas de desarrollo. Es una hemorragia de energía. Un equipo que se pasa meses o años en “modo reescritura” vive en una promesa constante. Trabaja mucho, pero casi nada llega al usuario hasta muy tarde. Cuesta celebrar avances, porque siempre parecen internos, invisibles. El riesgo de agotamiento y cinismo es altísimo.

Mientras tanto, negocio mira el roadmap y ve cómo se alarga como un chicle. “¿Qué habéis hecho estos últimos seis meses?” “Estamos reescribiendo el core, de verdad que va a ser la bomba.”

Explicar a alguien que paga facturas que estás a medio camino de un sistema que hace lo mismo que el actual, pero de forma más “bonita”, tiene menos glamour de lo que parece cuando lo dices en una daily.

Cuándo una reescritura tiene sentido

Eso no quiere decir que nunca tenga sentido reescribir. Hay casos donde el “tirar y volver a empezar” es casi una cuestión de supervivencia. Uno típico es cuando la tecnología base ha quedado fosilizada. Piensa en sistemas críticos apoyados en versiones obsoletas de lenguajes, frameworks o incluso sistemas operativos que ya nadie mantiene. A veces el coste de parchear, reforzar y apuntalar algo así acaba siendo mayor que levantar una estructura nueva con materiales del siglo actual.

Otro caso razonable aparece cuando el diseño original se queda completamente pequeño frente al problema actual. Un producto que nació como experimento de dos semanas en un hackathon interno y que, 7 años después, mueve millones de transacciones diarias, probablemente está estirando una arquitectura que nunca se pensó para eso. Ahí sí tiene sentido plantearse si seguir soldando piezas al Frankenstein o diseñar un cuerpo nuevo.

Pero incluso en esos casos, las reescrituras que funcionan se parecen menos a una revolución y más a una mudanza bien planeada. No es quemar la casa y construir otra en un solar vacío. Es ir cambiando habitación por habitación, llevando los muebles con cuidado, comprobando que tienes agua y electricidad antes de dormir allí.

Traducido a lo que los programadores conocemos: extraer módulos poco a poco, encapsular lo viejo detrás de interfaces claras, mover funcionalidades aisladas a servicios nuevos mientras el monolito sigue latiendo, usar patrones tipo “strangler” en lugar de “todo o nada”.

El autoengaño del “esta vez sí”

La pregunta incómoda que casi nadie se hace al principio es: “¿Estoy queriendo reescribir porque es lo mejor para el producto o porque estoy hasta las narices del código y me apetece un juguete nuevo?”. La segunda opción es peligrosamente frecuente. La reescritura se convierte, en silencio, en una especie de “proyecto de redención profesional ”: esta vez no cometeré los mismos errores, esta vez el código será bonito, esta vez aplicaré todos los patrones de diseño que no pude usar.

Si quieres saber si te estás autoengañando, puedes hacer un par de cosas muy incómodas, pero necesarias.

La primera: intentar estimar, de verdad, cuánto tiempo necesitas para reescribir todo, contando las cosas feas. No solo los módulos principales, sino todo lo periférico: integraciones, migración de datos, scripts internos, informes, herramientas que usan otros equipos. Si la cifra que sale de ese ejercicio serio no te da un poco de vértigo, probablemente la has subestimado.

La segunda: preguntarte qué va a pasar con el producto mientras tanto. ¿Vas a parar nuevas funcionalidades? ¿Vas a mantener dos líneas de desarrollo en paralelo? ¿Quién se va a comer los bugs que aparezcan al migrar? ¿Qué le vas a decir a negocio cuando te pregunte por qué llevas ocho meses sin sacar nada relevante, aparte de “te juro que estamos construyendo algo increíble, pero aún no puedes verlo”?

Hay otra señal de autoengaño que otros autores han señalado bien: si dices que necesitas reescribir porque “no se puede trabajar con este código” pero al mismo tiempo no estás introduciendo buenas prácticas ni refactorización incremental en el código actual, es probable que el problema no sea solo el código heredado o viejuno, sino cómo trabajas con él.

La alternativa aburrida que suele ganar

Frente a todo esto, la refactorización incremental tiene un marketing mucho peor, pero unas estadísticas de supervivencia bastante más decentes. No tiene titulares épicos, no hay anuncio de “hemos tirado toda esta basura y ahora sí que sí”. Lo que hay es una mejora constante, casi aburrida: dividir funciones monstruosas, extraer módulos, mejorar nombres, añadir tests donde antes solo había rezos.

Es menos atractiva, pero tiende a ser mucho más sostenible. Las empresas que viven de analizar bases de código apuntan a que las estrategias de refactorización bien hechas pueden acelerar el desarrollo y recortar notablemente los bugs en producción. No porque haya magia, sino porque un sistema que entiendes mejor es un sistema al que le puedes tocar piezas sin que explote siempre por el lado menos pensado.

En lugar de una gran apuesta “todo o nada”, tienes muchas apuestas pequeñas, reversibles. Cada cambio se puede probar, medir, revertir si hace falta. Puedes seguir entregando valor mientras limpias la casa. Puedes ir sustituyendo ladrillos del puente sin cortar el tráfico.

La virtud de quedarse y arreglar

Entonces, ¿cuándo sí tiene sentido darle al botón rojo de “empezar de cero”? Cuando el sistema actual es, honestamente, un callejón sin salida. Cuando no se puede desplegar sin rezar, cuando cualquier cambio lleva semanas porque todo está acoplado con todo, cuando ni siquiera puedes ejecutar una batería de tests decente porque no existe. Cuando la tecnología de base te encadena a un entorno inseguro, ineficiente o no soportado. Cuando el propio acto de mantener el código es una sangría constante de tiempo que impide avanzar en cualquier otra cosa.

Pero incluso entonces, el planteamiento sano no es “borro el repo y abro uno nuevo”, sino algo mucho más humilde: “voy a diseñar un camino de salida”. Un camino que admita convivir con lo viejo durante un tiempo, que permita migrar por fases, que tenga puntos de control claros. Un camino en el que se decida de antemano qué funcionalidad mínima tiene que cubrir la primera versión del nuevo sistema para empezar a apagar partes del viejo sin matar al negocio.

Solo después de pensar así tiene sentido hacerse la pregunta final: “si no estuviera cansado, si esto no fuera personal entre mí y este código horroroso, ¿seguiría recomendando reescribir?”. Si la respuesta honesta sigue siendo sí, adelante, pero con respeto. Reescribir no es castigar al pasado, es aprender de él. Y eso implica escuchar qué te está contando ese código feo, entender por qué llegó a ser como es, honrar las decisiones que fueron razonables en su momento, aunque hoy las mires con ceño fruncido.

Epílogo: convivir con el impulso

El síndrome de “sujétame el cubata” no va a desaparecer. Forma parte de la naturaleza humana, igual que tirar a la basura un texto medio escrito porque “ya no me gusta” y empezar de cero en una página en blanco. A veces funciona, pero muchas otras solo cambia un problema difícil por uno diferente, más caro y con menos garantías.

La virtud está, casi siempre, en resistir el impulso y hacer algo mucho más aburrido: quedarse, entender el lío, desmontarlo pieza a pieza y, mientras tanto, seguir entregando valor.

No suena tan glorioso como “reescribimos todo el core en seis meses”, pero suele tener una enorme ventaja: esta historia, a diferencia de muchas otras, sí termina bien.

Glosario rápido

Por si llevas menos tiempo en esto que el código que estás a punto de reescribir.

• Legacy: sistema o código heredado, escrito en otro contexto y otro momento, que sigue en producción porque nadie se ha atrevido (o podido) reemplazarlo. Suele tener cicatrices de decisiones que ya nadie recuerda.
• Strangler pattern: patrón de migración incremental que consiste en ir “estrangulando” el sistema viejo sustituyendo partes poco a poco, mientras el sistema original sigue funcionando. El nombre viene de la higuera estranguladora, que crece alrededor del árbol huésped hasta reemplazarlo.
• Happy path: el flujo ideal de ejecución de un sistema: sin errores, sin casos extremos, sin usuarios haciendo cosas raras. La parte bonita que sale en las demos. El problema es que la realidad rara vez sigue el happy path.
• Refactorización incremental: reestructuración del código en pasos pequeños y controlados, sin modificar su comportamiento externo. El objetivo es mejorar la legibilidad, reducir la deuda técnica y facilitar cambios futuros, sin tirar nada a la basura.
• Monolito: arquitectura de software donde toda la aplicación vive en un único desplegable. No es malo por definición, pero escala mal y hace que cualquier cambio toque más cosas de las que debería.

Fuentes y referencias

Si vas a reescribir este artículo desde cero, al menos consulta estas fuentes antes. Ya sabes cómo acaba eso.

• Things You Should Never Do, Part I (Joel Spolsky) - Joel Spolsky. El artículo clásico de 2000 sobre por qué reescribir software desde cero es “the single worst strategic mistake”. Hilo de r/ExperiencedDevs comentándolo 24 años después: https://www.reddit.com/r/ExperiencedDevs/comments/18vxqqf/24_years_ago_joel_spolsky_joel_on_software_wrote/
• Reescribir desde cero - serch.dev. Análisis de los riesgos y patrones de fracaso en las reescrituras de software.
• La trampa de la reescritura: por qué nunca debes tirar el código y empezar de cero - CrazyImagine. Argumentario sobre los costes reales de una reescritura total frente a la refactorización incremental.
• Lo difícil (imposible) de rehacer de cero un legacy - Javier Garzás. Análisis del caso Netscape y otros ejemplos de reescrituras fallidas en proyectos grandes.
• Síndrome Ícaro en ingeniería de software - cómo vencerlo - Q2B Studio. Sobre la tendencia de los desarrolladores a sobreescalar sus soluciones y creer que pueden hacerlo mejor desde cero.
• Did another developer ever completely rewrite a project from scratch? - r/AskProgramming. Thread con experiencias reales de equipos que acometieron reescrituras totales.