Es la conversación que llega siempre en el mismo momento: la aplicación funciona, hay clientes usándola, y añadir la siguiente funcionalidad se ha vuelto tan lento que ya no compensa. Entonces alguien dice «quizá habría que rehacerla», y la sala se divide.
Es una decisión cara en las dos direcciones. Reescribir cuando bastaba con arreglar quema meses y dinero para acabar donde ya estabas. Parchear cuando había que reescribir alarga la agonía y multiplica el coste final. Lo que sigue es el criterio con el que la tomamos.
Esta guía la firma Miguel Quílez, director de Hiberus Booster, la unidad del grupo Hiberus especializada en inteligencia artificial. Hiberus es la primera consultora tecnológica española de capital privado, con más de 4.000 profesionales.
La pregunta está mal planteada
«Parchear o reescribir» sugiere dos opciones. En realidad hay cuatro, y las dos intermedias son las que casi siempre ganan:
| Camino | Qué significa | Cuándo tiene sentido |
|---|---|---|
| Arreglar | Cerrar los fallos concretos sobre lo que hay | El problema es un puñado de cosas identificables |
| Sanear | Arreglar y además reordenar por dentro sin cambiar lo que el usuario ve | Funciona, pero cada cambio da miedo |
| Reescribir por trozos | Sustituir una pieza cada vez, con lo viejo y lo nuevo conviviendo | Hay partes irrecuperables y partes sanas |
| Reescribir entero | Empezar de cero y migrar cuando esté | Lo que hay no se puede tocar sin romperlo |
La discusión útil no es «¿reescribo?», es «¿cuál de los cuatro, y por qué no el anterior?». Cada escalón cuesta aproximadamente el triple que el de arriba, así que la carga de la prueba recae siempre en el que quiere subir.
Señales de que basta con arreglar o sanear
- Sabes nombrar los problemas. «La base de datos está abierta», «no hay copias», «esta pantalla tarda diez segundos». Un problema con nombre es un problema con presupuesto.
- Los fallos se concentran en dos o tres zonas y el resto lleva meses sin dar guerra.
- Puedes cambiar algo y comprobar que no has roto nada, aunque sea a mano y te lleve una tarde.
- El modelo de datos aguanta lo que quieres hacer los próximos doce meses.
- La aplicación hace lo que el negocio necesita; el problema es cómo lo hace por dentro.
Si reconoces cuatro de las cinco, reescribir sería tirar dinero. Lo que tienes es una lista de tareas, no un proyecto nuevo.
Señales de que hay que reescribir, entera o por trozos
- Cada arreglo rompe otra cosa, de forma repetida y en sitios que no parecían relacionados.
- Nadie puede explicar por qué funciona una parte concreta, y da miedo tocarla.
- El modelo de datos impide lo siguiente que el negocio necesita, no solo lo complica.
- La aplicación solo existe dentro de la herramienta con la que se generó y no puedes sacarla.
- Está atada a una plataforma que vas a dejar, o que ha cambiado el precio de forma que no te sale.
- El coste por usuario crece más rápido que los ingresos por usuario, por cómo está construida.
Las tres primeras describen algo concreto: el sistema ha dejado de ser predecible. Cuando no puedes anticipar el efecto de un cambio, el coste de cada mejora deja de ser estimable, y un proyecto que no se puede estimar no se puede gestionar.
Por qué la reescritura completa casi siempre sale mal
Tres razones, y las tres se repiten:
El producto viejo no se para. Mientras reescribes, los clientes siguen pidiendo cosas. O congelas el producto (y pierdes clientes) o mantienes dos frentes (y duplicas el equipo). Casi nadie presupuesta la segunda.
Lo que parecía accidental era necesario. Ese trozo raro que nadie entiende suele resolver un caso real que aparece dos veces al año. Se descubre después de haber lanzado lo nuevo, en forma de incidencia.
Se reescribe con las prisas viejas. Si la aplicación quedó así porque había que salir en tres semanas, y la reescritura también tiene tres semanas, el resultado tendrá los mismos problemas con código más nuevo.
Por eso, cuando la reescritura es inevitable, casi siempre es por trozos: se elige la pieza que más duele, se sustituye con lo viejo todavía en marcha, se comprueba que funciona y se pasa a la siguiente. Más lento sobre el papel, mucho más barato en la práctica, y se puede parar a mitad si el negocio cambia de idea.
Lo que sí se tira siempre
Hay una excepción sin matices: los fallos de seguridad no se heredan, se cierran. Da igual el camino que elijas. Si la base de datos está abierta o hay claves en el navegador, eso se arregla esta semana, no en la versión 2 que llegará en abril. Los detalles están en la lista de errores frecuentes.
Cómo se decide en la práctica
Tres preguntas, en este orden:
1. ¿Cuánto cuesta el siguiente cambio importante en lo que hay? No en abstracto: coge la funcionalidad concreta que toca hacer ahora y estímala sobre el código actual. Si sale una cifra creíble, tienes tu respuesta.
2. ¿Qué porcentaje se salva? Rara vez todo está mal. Normalmente el modelo de datos es recuperable y la capa de encima no, o al revés. Ese porcentaje decide entre reescribir por trozos y reescribir entero.
3. ¿Cuánto tiempo puedes estar sin entregar nada nuevo? Si la respuesta es «dos semanas», la reescritura completa está descartada por aritmética, no por criterio técnico.
Las tres respuestas necesitan que alguien haya mirado el código de verdad. Tomar esta decisión con la impresión de quien la mantiene —que siempre quiere reescribir— o de quien la construyó —que siempre quiere defenderla— es cómo se pierden los seis meses.
El orden que recomendamos
- Semana 1: inspección independiente. Qué se salva, qué no, y qué cuesta cada camino con números.
- Semanas 2-3: cerrar seguridad y copias de seguridad, decidas lo que decidas después.
- Después: sanear si el diagnóstico dice que se salva, o sustituir la primera pieza si dice que no.
- Nunca: parar el producto entero para rehacerlo mientras los clientes esperan.
En la mayoría de los casos que vemos, el diagnóstico honesto es «sanear y sustituir una pieza», no «rehacer». La reescritura completa está justificada, pero es rara, y conviene que quien la proponga no sea quien la vaya a cobrar.
Preguntas frecuentes
¿Cuándo hay que reescribir una app hecha con IA en lugar de arreglarla?
Cuando el sistema ha dejado de ser predecible: cada arreglo rompe otra cosa en sitios que no parecían relacionados, nadie sabe explicar por qué funciona una parte concreta, o el modelo de datos impide —no solo complica— lo siguiente que el negocio necesita. También cuando la aplicación solo existe dentro de la herramienta que la generó y no puedes sacarla.
¿Es motivo suficiente que el código esté mal escrito?
No. Un código feo que funciona, que puedes cambiar sin miedo y que aguanta lo que viene por delante es código que cumple su función. La incomodidad estética de quien lo hereda es la razón más cara y peor argumentada para rehacer un producto que ya factura.
¿Qué es reescribir por trozos?
Sustituir una pieza cada vez manteniendo lo viejo en marcha, comprobar que funciona y pasar a la siguiente. Sobre el papel es más lento que empezar de cero; en la práctica sale mucho más barato, no obliga a congelar el producto y se puede parar a mitad si el negocio cambia de idea.
¿Por qué fracasan tantas reescrituras completas?
Por tres motivos que se repiten: el producto viejo no se para y acabas manteniendo dos frentes con un solo equipo; ese trozo raro que nadie entendía resolvía un caso real que aparece dos veces al año y se descubre en forma de incidencia; y la reescritura se hace con las mismas prisas que causaron el problema, así que llega al mismo sitio con código más nuevo.
¿Cuánto cuesta cada camino?
Como regla práctica, cada escalón cuesta unas tres veces el anterior: arreglar, sanear, reescribir por trozos, reescribir entero. La carga de la prueba recae siempre en quien quiere subir de escalón, y los números concretos solo salen después de que alguien haya mirado el código.
¿Qué se arregla sí o sí, decida lo que decida?
Los fallos de seguridad. No se heredan a la versión siguiente ni esperan a la reescritura: si la base de datos está abierta o hay claves en el navegador, eso se cierra esta semana, sea cual sea el camino que elijas después.
¿Quién debería tomar esta decisión?
Alguien que haya mirado el código y no tenga interés en el resultado. Quien mantiene la aplicación casi siempre quiere reescribir; quien la construyó casi siempre quiere defenderla. Así es como se pierden seis meses en la dirección equivocada.
¿Cuál es el orden recomendado?
Primero una inspección independiente que diga qué se salva y qué cuesta cada camino con números. Después, cerrar seguridad y copias de seguridad, decidas lo que decidas luego. Y solo entonces sanear o sustituir la primera pieza. Nunca parar el producto entero para rehacerlo mientras los clientes esperan.
Antes de decidir, que alguien mire lo que hay
Es una decisión de decenas de miles de euros y no debería tomarse a ojo. Cuéntanos qué tienes y en cinco días te decimos qué se salva, qué no y cuánto cuesta cada camino.
✓ ¡Recibido!
Gracias. Un especialista de Hiberus Booster te contacta en menos de 24 horas.
