Módulo 1: Por qué no reescribir
Presentación del módulo: por qué no reescribir
Por qué este módulo existe aquí
Hay una frase que todo equipo de software dice tarde o temprano, frente al mismo sistema viejo y enredado: "esto ya no se puede mantener; lo más rápido es reescribirlo desde cero, bien hecho esta vez". Suena a sensatez. Suena a valentía técnica. Y casi siempre es el principio de un desastre caro. Este módulo instala, como idea que sostiene toda la guía, la convicción contraria: la reescritura grande —tirar todo y empezar de nuevo— casi siempre fracasa, y el camino que sí funciona es el incremental: transformar el sistema por partes mientras sigue vivo, sigue en producción y sigue entregando valor al negocio.
Esta guía completa enseña cómo modernizar un sistema legacy sin reescribirlo de cero: ponerlo bajo una red de seguridad (módulo 2), desviar tráfico del viejo al nuevo con un facade (módulo 3), migrar la implementación por dentro (módulo 4), extraer un servicio (módulo 5), migrar sus datos sin apagar el negocio (módulo 6) y medir el avance hasta apagar la vieja ruta (módulo 7). Pero antes de la primera técnica hace falta creer —con evidencia, no con fe— que el camino incremental es el correcto. Ese es el trabajo de este módulo, y por eso va primero: si no te convence que el rewrite es una trampa, ninguna técnica de las que siguen te va a parecer necesaria.
Vamos con el caso que nos acompaña toda la guía. Mercado es un marketplace, y hoy es un monolito legacy de manual:
- El catálogo de productos, los pedidos, los pagos y los envíos viven todos en un solo código, desplegado como una sola unidad.
- Comparten una sola base de datos: todo lee y escribe sobre las mismas tablas.
- No tiene tests. Cambiar cualquier cosa es cambiar a ciegas.
- Hay partes que nadie se atreve a tocar: el que las escribió ya no está, y funcionan "por alguna razón" que nadie recuerda del todo.
Frente a un sistema así, la tentación de reescribir es abrumadora y siempre la misma. Este módulo no la niega —la respeta— pero la desarma con números. Fíjate en algo antes de seguir: este módulo no enseña todavía cómo se moderniza Mercado. No vas a ver el router del strangler, ni los characterization tests, ni la migración de datos: esa es la mecánica de los módulos que siguen. Lo que este módulo hace es lo previo e imprescindible: demostrar por qué el incremental gana, para que cuando llegue la mecánica sepas exactamente qué problema resuelve.
Conexión con el módulo. Esta es la lección-mapa. No entramos a fondo en ninguna técnica todavía; instalamos la tesis (la reescritura grande fracasa, el incremental gana), el vocabulario (big rewrite, incremental, paridad de features, síndrome del segundo sistema, conocimiento tácito, strangler fig, modernizar en su lugar) y el mapa de cómo cada lección construye una parte del argumento. La lección 2 abre la anatomía de la falla: el negocio que no se detiene y la paridad que nunca llega. La 3 diagnostica el síndrome del segundo sistema. La 4 mide el conocimiento tácito que se pierde. La 5 arma el caso a favor de lo incremental. La 6 instala la metáfora del strangler fig. La 7 consolida: modernizar en su lugar vs empezar de cero, sin dogma. Y la 8 te pone a clasificar los módulos de Mercado y a escribir la recomendación, ejecutada. La mecánica del strangler —el router que desvía tráfico— es el módulo 3; caracterizar el legacy con tests para tocarlo sin miedo es el módulo 2; y la decisión formal de migrar —el ADR, el costo, la reversibilidad registrada— vive en la guía hermana architecture-decisions-and-tradeoffs. Aquí solo construimos la convicción.
Y una promesa que se cumple en todo el módulo: nada se afirma "de memoria", todo se mide. Cada simulación corre con Python 3.14 y solo la biblioteca estándar, con datos fijos, así que la salida que ves en cada bloque "Qué esperar" es la salida literal de correr el código. Puedes copiarlo y reproducirlo idéntico.
Una analogía: renovar la casa cuarto por cuarto vs demolerla y quedarte en la calle
Imagina que tu casa está vieja. Las tuberías fallan, la instalación eléctrica es de otra época, la cocina no funciona bien. Hay que modernizarla. Tienes dos caminos, y son de naturalezas opuestas.
Camino 1 — demoler y reconstruir desde cero. Suena tentador: una casa nueva, sin los parches de la vieja, hecha "bien esta vez". Pero fíjate en lo que implica de verdad. Tienes que salir de la casa mientras la reconstruyen. Durante dos años vives en un departamento rentado, pagando dos veces (la renta y la obra), y tu casa no existe: no puedes cocinar en ella, no puedes dormir en ella, no da absolutamente nada mientras se construye. Y las obras se atrasan —siempre se atrasan—: lo que iban a ser dos años se vuelven tres. Mientras tanto, tu vida no se detuvo: nacieron hijos, cambió tu trabajo, y la casa que diseñaste hace tres años ya no es la que necesitas. Cuando por fin te mudas, descubres que olvidaron ese detalle rarísimo de la casa vieja —el clóset bajo la escalera donde guardabas todo— porque nadie lo anotó. Reconstruir desde cero es apostar dos años de tu vida a que todo salga bien, sin recibir nada en el camino.
Camino 2 — renovar cuarto por cuarto mientras vives en ella. Empiezas por el baño. Una semana de obra, y ya tienes un baño nuevo funcionando. Luego la cocina: dos semanas, y cocinas en la cocina nueva. Sigues durmiendo en la casa, comiendo en la casa, viviendo en la casa —cada semana está un poco mejor, y en ningún momento te quedaste sin techo—. Si un cuarto sale mal, lo arreglas sin que se caiga el resto. Si a mitad del proceso cambian tus necesidades, ajustas el plan de los cuartos que faltan. Nunca pagas doble renta, nunca pasas dos años sin casa, y el conocimiento de "cómo funciona esta casa" no se pierde porque nunca dejaste de habitarla.
Aquí está el punto: las dos modernizan la casa, pero solo una te deja vivir mientras tanto. Mercado es una casa habitada —tiene clientes comprando ahora mismo, y no puedes pedirles que vuelvan en dos años—. Demoler y reconstruir es el big rewrite; renovar cuarto por cuarto es el incremental. Todo este módulo te entrena a ver, en números, por qué la segunda casi siempre gana. Y hay una tercera imagen que vas a encontrar en la lección 6, todavía más precisa para el software: la higuera estranguladora, un árbol que crece envolviendo a otro y lo va reemplazando célula por célula, hasta que un día el árbol viejo ya no está —y en ningún momento hubo un bosque sin árbol—.
Ejemplo trabajado: el valor que el rewrite no entrega mientras el negocio no se detiene
No vamos a afirmar que el rewrite entrega poco. Lo vamos a medir. La idea es simple y es el corazón del módulo: durante una reescritura grande, el equipo trabaja duro pero el negocio no recibe nada hasta el corte final —y el negocio no se detiene a esperar—. Cada trimestre pide features nuevas, y durante la reescritura esas features están congeladas: se acumulan en un backlog que nadie atiende.
Vamos a modelar dos estrategias con el mismo equipo y el mismo costo por trimestre, cambiando solo la estrategia. El negocio pide 4 features por trimestre. El rewrite las congela hasta el corte; el incremental las sigue entregando mientras moderniza una rebanada por trimestre:
# El negocio pide 4 features por trimestre y no se detiene a esperar la reescritura.
# Mismo equipo, mismo costo por trimestre: lo unico que cambia es la ESTRATEGIA.
QUARTERS = 12 # ventana de 3 anios
FEATURES_REQUESTED = 4 # lo que el negocio pide cada trimestre
REWRITE_PLANNED_CUTOVER = 8 # cuando el plan prometia terminar la reescritura
REWRITE_REAL_CUTOVER = 13 # cuando de verdad quedaria (fuera de la ventana)
print(f"{'Q':>2} | {'REWRITE':^22} | {'INCREMENTAL':^22}")
print(f"{'':>2} | {'shipped':>8}{'backlog':>8}{'mod%':>6} | "
f"{'shipped':>8}{'backlog':>8}{'mod%':>6}")
print("-" * 54)
rw_shipped = rw_backlog = 0
inc_shipped = inc_backlog = 0
for q in range(1, QUARTERS + 1):
# Rewrite: features CONGELADAS hasta el cutover; el backlog se acumula.
if q >= REWRITE_REAL_CUTOVER:
rw_shipped += FEATURES_REQUESTED + rw_backlog
rw_backlog = 0
else:
rw_backlog += FEATURES_REQUESTED
rw_mod = 100 if q >= REWRITE_REAL_CUTOVER else 0
# Incremental: se moderniza una rebanada por trimestre SIN dejar de entregar.
inc_shipped += FEATURES_REQUESTED # el negocio sigue recibiendo lo que pide
inc_mod = min(100, q * 100 // 8) # ~8 trimestres para modernizar todo
print(f"{q:>2} | {rw_shipped:>8}{rw_backlog:>8}{rw_mod:>5}% | "
f"{inc_shipped:>8}{inc_backlog:>8}{inc_mod:>5}%")
print("-" * 54)
print(f"\nAl cerrar la ventana de {QUARTERS} trimestres:")
print(f" Rewrite: {rw_shipped:>3} features entregadas, "
f"{rw_backlog:>3} en backlog, {'0' if rw_shipped==0 else '100'}% modernizado")
print(f" Incremental: {inc_shipped:>3} features entregadas, "
f"{inc_backlog:>3} en backlog, 100% modernizado")
print(f"\n El plan del rewrite prometia terminar en el trimestre "
f"{REWRITE_PLANNED_CUTOVER}; la realidad lo empujo al {REWRITE_REAL_CUTOVER}.")
print(f" Durante {QUARTERS} trimestres el rewrite entrego 0 valor al negocio.")Qué esperar. Al correr el archivo, la salida es exactamente esta:
Q | REWRITE | INCREMENTAL
| shipped backlog mod% | shipped backlog mod%
------------------------------------------------------
1 | 0 4 0% | 4 0 12%
2 | 0 8 0% | 8 0 25%
3 | 0 12 0% | 12 0 37%
4 | 0 16 0% | 16 0 50%
5 | 0 20 0% | 20 0 62%
6 | 0 24 0% | 24 0 75%
7 | 0 28 0% | 28 0 87%
8 | 0 32 0% | 32 0 100%
9 | 0 36 0% | 36 0 100%
10 | 0 40 0% | 40 0 100%
11 | 0 44 0% | 44 0 100%
12 | 0 48 0% | 48 0 100%
------------------------------------------------------
Al cerrar la ventana de 12 trimestres:
Rewrite: 0 features entregadas, 48 en backlog, 0% modernizado
Incremental: 48 features entregadas, 0 en backlog, 100% modernizado
El plan del rewrite prometia terminar en el trimestre 8; la realidad lo empujo al 13.
Durante 12 trimestres el rewrite entrego 0 valor al negocio.
Lee la tabla con calma, porque en esas dos columnas está la idea central del módulo.
La columna del rewrite es una línea plana de ceros. Trimestre tras trimestre, shipped es 0 y mod% es 0: el equipo trabaja, pero el negocio no recibe nada. Y mira la columna backlog: crece 4 cada trimestre, sin parar, hasta 48. Esas son las 48 features que el negocio pidió y que la reescritura no dejó construir —porque durante un rewrite las features se congelan, "para no tener que hacerlas dos veces"—. El plan decía que el corte sería en el trimestre 8; la realidad —como en casi todas las reescrituras— lo empujó más allá de la ventana. Doce trimestres, tres años, y el negocio recibió exactamente cero.
La columna del incremental es lo opuesto: shipped sube 4 cada trimestre (el negocio sigue recibiendo lo que pide), backlog se queda en 0 (no hay features congeladas), y mod% trepa hasta 100 en 8 trimestres. Modernizó el sistema completo y, en el camino, entregó 48 features. No hubo que elegir entre "modernizar" y "seguir dando valor": el incremental hace las dos cosas a la vez, porque nunca detiene el negocio.
Este es el argumento en su forma más desnuda. El rewrite pide una cosa que el negocio no puede dar: dos años de silencio. El incremental no lo pide. Y esto es apenas la punta —la lección 2 va a mostrar que ni siquiera esos "dos años" son reales, porque la paridad de features es un blanco que se aleja mientras corres hacia él—.
Las ideas que instala este módulo, y dónde vive cada una
Ese ejemplo tocó, sin desarrollarlas del todo, las ideas del módulo. Vale la pena verlas explícitas, porque son la columna vertebral de las siete lecciones que siguen.
1. El big rewrite fracasa por cuatro razones concretas (lecciones 2, 3 y 4). No es mala suerte ni mala ejecución: son modos de falla estructurales. El negocio no se detiene (la ventana de silencio que acabas de ver) y la paridad de features nunca llega porque el legacy sigue creciendo (lección 2). El síndrome del segundo sistema infla el alcance hasta que la fecha de cierre se aleja sin fin (lección 3). Y el conocimiento tácito —años de reglas de negocio sin documentar— se pierde en una reescritura a ciegas y reaparece como regresiones (lección 4).
2. El incremental gana porque entrega temprano y arriesga poco (lección 5). Cada rebanada modernizada paga de inmediato, mientras el rewrite no paga hasta el final; y el riesgo "en juego" en cada paso incremental es diminuto (una rebanada), contra el sistema entero que el rewrite arriesga de una vez. La lección 5 lo mide en valor-periodos y en radio de impacto.
3. La metáfora del strangler fig (lección 6). La higuera que envuelve al árbol y lo reemplaza sin talarlo —el sistema siempre vivo, el viejo como fallback—. Modernizar en su lugar en vez de tirar todo. La lección 6 instala la metáfora y mide por qué evita el apagón del corte big-bang. (La mecánica es el módulo 3.)
4. Reescribir no es siempre malo (lección 7). Sin dogma: hay una región estrecha donde una reescritura sí es segura —sistema chico, sin usuarios, bien entendido, bien probado—. La lección 7 puntúa varios sistemas y muestra que Mercado cae en la esquina opuesta.
Guarda este mapa; es la ruta del módulo:
Idea Lección Concepto clave
─────────────────────────────────────── ──────── ──────────────────────────────
Por qué el big rewrite fracasa L2 negocio que no se detiene,
paridad como blanco movil
El sindrome del segundo sistema L3 inflacion de alcance, la fecha
de cierre que se aleja
El conocimiento tacito perdido L4 el legacy es la especificacion,
regresiones silenciosas
El caso a favor de lo incremental L5 valor-periodos, riesgo en juego
La metafora del strangler fig L6 reemplazar sin talar, en su lugar
─────────────────────────────────────── ──────── ──────────────────────────────
Consolidar: en su lugar vs de cero L7 rewrite_score, la region estrecha
Defensa contra el rewrite de Mercado L8 el mini-proyecto, ejecutado
El mapa: dónde está este módulo en la guía y en el ecosistema
Este módulo es la puerta de entrada. Así se conecta con el resto de la guía:
flowchart TD
M1["M1 · Por qué no reescribir<br/>(la conviccion: incremental gana)"]
M2["M2 · Caracterizar y fijar el legacy<br/>(la red de seguridad)"]
M3["M3 · El patrón strangler fig<br/>(la mecánica del router)"]
M4["M4 · Branch by abstraction"]
M5["M5 · Extraer un servicio"]
M6["M6 · Migrar datos sin downtime"]
M7["M7 · Medir el progreso de la migración"]
M8["M8 · Proyecto: modernizar una rebanada de Mercado"]
M1 --> M2 --> M3 --> M4 --> M5 --> M6 --> M7 --> M8
Léelo así: aquí te convences de que el incremental gana; en M2 pones el legacy bajo una red de seguridad (characterization tests) para poder tocarlo sin miedo; en M3 aprendes la mecánica del strangler (el router que desvía tráfico); en M4 migras la implementación por dentro; en M5 extraes un servicio; en M6 migras sus datos sin apagar el sistema; en M7 mides el avance hasta apagar lo viejo; y en M8 haces todo el recorrido con una rebanada real de Mercado.
Y la frontera con las guías hermanas del ecosistema, que hay que respetar: esta guía es la técnica de migración, no el destino. A dónde migras —el estilo destino, sea eventos, microservicios o una API— lo enseñan event-driven-architecture, architectural-styles-and-boundaries y api-design-and-integration. La decisión de migrar y su registro —el ADR, el costo, la reversibilidad— es architecture-decisions-and-tradeoffs. Y los pipelines de datos a escala son el ecosistema de Data Engineering. Cuando una lección diga "extraer el catálogo a un servicio", no va a re-enseñar qué es un servicio ni cómo decidir si conviene: va a enseñar cómo migrar hacia allá desde el monolito que ya tienes, sin big-bang.
Errores comunes
Creer que "esta vez el rewrite sí va a salir bien". Qué pasa: el equipo reconoce que las reescrituras suelen fracasar, pero cree que la suya es la excepción —"nosotros sí conocemos el dominio", "nosotros sí vamos a congelar el alcance", "el equipo anterior era el problema"—. Por qué pasa: el fracaso del rewrite no se siente como un riesgo estructural sino como una falla de ejecución ajena, y todos creemos que ejecutamos mejor que el promedio. Cómo detectarlo: la frase reveladora es "sí, pero en nuestro caso...", seguida de una razón por la que las reglas generales no aplican. Cómo corregirlo: los cuatro modos de falla de este módulo (el negocio que no se detiene, la paridad móvil, el segundo sistema, el conocimiento tácito) no dependen de la habilidad del equipo —son propiedades del problema, no de quién lo ataca—. Un equipo brillante que reescribe un sistema vivo se choca con los mismos cuatro muros. La disciplina no es "reescribir mejor"; es no reescribir y modernizar por rebanadas. La lección 7 muestra cuándo un rewrite sí es defendible, y Mercado no cumple ninguna de esas condiciones.
Tratar la reescritura como un problema puramente técnico. Qué pasa: la discusión sobre "reescribir o no" se centra en el stack —el lenguaje viejo, el framework obsoleto, la deuda técnica— y olvida al negocio que corre encima. Por qué pasa: los ingenieros ven el código feo todos los días y el dolor es real y técnico; el costo de negocio (la ventana de silencio, el backlog congelado, los clientes que se van a la competencia mientras esperas) es invisible desde el editor. Cómo detectarlo: si la justificación de reescribir es "el código es un desastre" sin una sola cifra de lo que el negocio deja de recibir durante la reescritura, falta la mitad del análisis. Cómo corregirlo: toda decisión de reescribir es una decisión de negocio antes que técnica —cuánto valor deja de fluir, por cuánto tiempo, con qué riesgo—. El ejemplo de este módulo pone esa cifra sobre la mesa: 48 features congeladas, 3 años de cero entrega. La deuda técnica se paga incrementalmente, sin cerrar la caja.
Ejercicios
Ejercicio 1 — Casa o demolición. Para cada uno de estos sistemas, di si lo tratarías como candidato a reescritura de cero (demoler y reconstruir) o a modernización incremental (renovar cuarto por cuarto), y justifica con al menos una de las razones del módulo (el negocio no se detiene, la paridad móvil, el conocimiento tácito): (a) un script interno de 200 líneas que un becario usa una vez al mes para generar un reporte; (b) el sistema de pagos de Mercado, que procesa transacciones de clientes 24/7; (c) un prototipo que armaste el fin de semana y que aún no tiene usuarios; (d) el monolito completo de Mercado.
Ver solución
- (a) Script interno de 200 líneas → reescritura viable. Es chico, tiene un solo usuario, se usa una vez al mes (si falla el rewrite, el costo es bajísimo y hay tiempo de sobra para corregir), y su comportamiento es fácil de entender de una lectura. No hay negocio 24/7 que se detenga ni conocimiento tácito enterrado. Reescribirlo en una tarde es razonable. Es la región estrecha que la lección 7 identifica.
- (b) Sistema de pagos de Mercado → incremental, sin duda. Procesa dinero de clientes todo el tiempo: el negocio no se detiene ni un minuto. Además carga conocimiento tácito peligrosísimo (reglas de fraude, redondeos, casos de países y monedas que se acumularon en años). Una reescritura a ciegas convierte ese conocimiento en regresiones que cuestan dinero real. Es la casa habitada que no puedes demoler.
- (c) Prototipo del fin de semana → reescritura viable. Sin usuarios, sin negocio encima, y tú acabas de escribirlo, así que el conocimiento está fresco en tu cabeza (no es tácito, es explícito y reciente). Ninguno de los cuatro modos de falla aplica. Reescribir un prototipo para "hacerlo bien" antes de que tenga usuarios es legítimo.
- (d) Monolito completo de Mercado → incremental, el caso central de la guía. Es grande, está en producción con clientes comprando ahora, no tiene tests, y tiene partes que nadie entiende. Los cuatro modos de falla aplican a la vez. Es exactamente la casa que hay que renovar cuarto por cuarto. Reescribirlo entero es la apuesta de tres años de silencio que el ejemplo de esta lección midió.
Ejercicio 2 — El backlog congelado. En el ejemplo trabajado, el rewrite terminó con 48 features en el backlog al cabo de 12 trimestres. Explica, en tus palabras, por qué esas 48 features no son "trabajo pendiente que haremos después" sino un costo real que Mercado paga durante la reescritura. Nombra al menos dos cosas concretas que le pasan a Mercado por no entregar esas features.
Ver solución
Esas 48 features no son trabajo diferido neutro: son valor que el negocio necesitaba y no recibió durante tres años. Lo que le pasa a Mercado concretamente:
- La competencia no se congela. Mientras Mercado no entrega nada, sus competidores siguen sacando features. Al cabo de tres años, Mercado no solo está donde empezó: está tres años detrás del mercado, con un backlog de 48 cosas que sus clientes ya esperan en cualquier marketplace moderno. La ventana de silencio no es neutral; es terreno cedido.
- Los clientes y el equipo comercial se frustran. Cada feature pedida y no entregada es una promesa incumplida: un cliente grande que pidió una integración y no la tuvo, un equipo de ventas que no pudo cerrar un trato por una capacidad faltante. Tres años de "está en el backlog, lo veremos después de la reescritura" erosionan la confianza en que el equipo técnico puede entregar.
Además, el propio rewrite se vuelve más frágil: cuanto más largo el congelamiento, más presión política para "descongelar solo esta feature urgente", lo que reintroduce trabajo en el sistema viejo que supuestamente ya no se toca —y ahora hay que hacerlo dos veces—. La lección 2 muestra que ese congelamiento, además, alimenta el blanco móvil de la paridad.
Ejercicio 3 — Desarma la frase. Un compañero dice: "el código de Mercado es un desastre imposible de mantener; la única salida responsable es reescribirlo desde cero con un stack moderno". Identifica qué parte de la afirmación es probablemente cierta, qué parte es un salto injustificado, y cómo reformularías la conclusión sin negar el problema real.
Ver solución
Lo probablemente cierto: "el código es difícil de mantener". Es un diagnóstico técnico real y honesto —sin tests, con módulos enredados y partes que nadie entiende, tocar Mercado es caro y arriesgado hoy—. Ese dolor es legítimo y no hay que minimizarlo.
El salto injustificado: de "es difícil de mantener" a "la única salida es reescribir desde cero". Ese por lo tanto no se sostiene. La dificultad de mantención es un argumento para modernizar, no específicamente para reescribir de cero. Reescribir es una de las formas de modernizar, y —como mide todo este módulo— la que casi siempre fracasa cuando el sistema está vivo. La frase confunde "hay que hacer algo" con "hay que hacer esto". También cuela un supuesto no dicho: que un stack moderno resuelve el problema, cuando el problema real (el conocimiento tácito sin documentar, la falta de tests) viaja intacto a cualquier stack si lo reescribes a ciegas.
Reformulación honesta: "el código de Mercado es difícil y arriesgado de mantener, y eso hay que atacarlo en serio. La forma de atacarlo con menos riesgo y sin detener el negocio es modernizarlo por rebanadas: ponerlo bajo una red de seguridad, extraer una pieza a la vez y desviar el tráfico incrementalmente. Reescribir todo de cero es la opción que suena más limpia y que más veces termina en desastre, por las razones que podemos medir". Así se conserva el problema real y se corrige la conclusión. La lección 7 da el criterio exacto para saber cuándo un rewrite sí es la opción correcta —y Mercado no lo cumple—.
Resumen y siguiente paso
En esta lección instalaste la tesis que sostiene toda la guía: la reescritura grande de un sistema legacy vivo casi siempre fracasa, y el camino que gana es el incremental. Viste, con la casa, que renovar cuarto por cuarto te deja vivir mientras modernizas, mientras que demoler te deja dos años en la calle. Y lo mediste: modelaste doce trimestres de rewrite vs incremental y viste, en números, que el rewrite entregó 0 features y acumuló un backlog de 48 mientras el incremental modernizó el sistema completo y entregó las 48. El argumento no es estético ni ideológico: es que el rewrite pide algo que el negocio no puede dar —silencio prolongado— y el incremental no lo pide.
Antes de avanzar deberías poder: explicar por qué "esta vez sí saldrá bien" es una ilusión (los modos de falla no dependen del equipo); nombrar por qué el negocio que no se detiene hunde al rewrite; distinguir un sistema candidato a reescritura de uno candidato a modernización incremental; y argumentar por qué la reescritura es una decisión de negocio antes que técnica.
La lección 2 toma el primer modo de falla y lo abre a fondo: por qué la reescritura grande fracasa. Vas a ver que la "ventana de silencio" es todavía peor de lo que parece, porque la meta se mueve: mientras el rewrite corre hacia la paridad de features, el legacy sigue creciendo, y la paridad se convierte en un blanco que se aleja. Lo vas a medir en varios escenarios de velocidad —incluido uno en el que la paridad, sencillamente, no llega nunca—.
Recursos
- Joel Spolsky, "Things You Should Never Do, Part I" (2000) — joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i. El ensayo fundacional de este módulo: por qué reescribir desde cero fue "the single worst strategic mistake" de Netscape, que regaló años de mercado mientras reescribía. Corto, memorable y directo al hueso. En inglés.
- Martin Fowler, "StranglerFigApplication" (2004) — martinfowler.com/bliki/StranglerFigApplication.html. El origen de la metáfora que instala este módulo y que la lección 6 desarrolla. Fowler cuenta cómo tomó la imagen de las higueras estranguladoras de Queensland. En inglés.
- Michael Feathers, Working Effectively with Legacy Code (Prentice Hall, 2004) — la biblia de trabajar con código que da miedo. Su tesis de fondo (el código sin tests es "legacy" por definición, y se moderniza envolviéndolo en una red de seguridad antes de tocarlo) es la que el módulo 2 desarrolla. En inglés.
- Sam Newman, Monolith to Microservices (O'Reilly, 2019), cap. 1 — el marco de por qué la migración incremental le gana a la reescritura big-bang, y cómo elegir la primera rebanada. La referencia central para los módulos 3 al 6. En inglés.
- Michael Feathers, "Working Effectively with Legacy Code" (resumen y charlas) — michaelfeathers.silvrback.com. Ensayos cortos del autor sobre legacy, seams y caracterización. Buen acompañamiento para todo el módulo y puente al módulo 2. En inglés.