Módulo 6: Diseñar para el cambio
La arquitectura nunca es final
Descripción
La lección anterior instaló la tesis con una medición: en cinco años, tres cuartas partes de las suposiciones del diseño del día uno de Mercado se invalidan. Esta lección toma esa tesis y la convierte en una postura operativa: si el diseño se erosiona sí o sí, entonces la arquitectura no es un artefacto que se congela —un plano que se dibuja, se aprueba y se archiva—, sino un flujo de decisiones que corre mientras el sistema esté vivo. Cada vez que una suposición cae, el sistema recibe una decisión nueva. La pregunta del arquitecto no es "¿está terminada la arquitectura?" —nunca lo está— sino "¿está postulada para recibir la siguiente decisión barata, o va a pelear contra ella?".
Este cambio de mentalidad —de la foto a la película— tiene una consecuencia que no es obvia y que esta lección mide: lo que quiebra un sistema casi nunca es un cambio individual. Un cambio grande, doloroso, se ve venir y se maneja. Lo que quiebra es la acumulación: cientos de cambios pequeños empujados contra una estructura que se trató como final, cada uno un poco más caro que el anterior porque la estructura no fue diseñada para moverse. El drift se acumula despacio, invisible, hasta que un día un cambio trivial toma tres semanas y nadie entiende por qué. Esta lección pone número a esa acumulación: compara el costo total, a lo largo de la vida de Mercado, de tratar la arquitectura como congelada contra tratarla como un flujo —y muestra que la diferencia no está en ningún cambio, sino en la suma de todos—.
Conexión con el módulo. Es la primera de las tres lecciones que instalan la postura básica (esta: la arquitectura es un flujo; la 3: mantener opciones abiertas; la 4: construir para tirar). Aquí no hablamos todavía de cómo dejar costuras —eso son las lecciones 5, 6 y 7—; instalamos el marco mental que hace que dejarlas tenga sentido: si no crees que la arquitectura es un flujo, no vas a molestarte en postularla para el cambio. Frontera con la guía hermana: la mecánica de gestionar el cambio decisión por decisión (deuda técnica, último momento responsable) es architecture-decisions; aquí trabajamos la disposición de ver el sistema como una película en curso, no como una foto terminada.
Una analogía: la casa que se habita contra la casa que se termina
Piensa en dos maneras de tener una casa, y en cómo envejece cada una.
La casa que se termina. Una pareja construye la casa de sus sueños con un plano perfecto: cada muro en su sitio, cada toma de corriente calculada, la cocina exactamente donde la quisieron el día que la diseñaron. El día que se mudan, la casa está terminada —esa es la palabra que usan—. Y la tratan como terminada: es una obra concluida que hay que conservar. Pasan los años. Llega un hijo, y hace falta un cuarto más: pero los muros son de carga, moverlos es carísimo, así que aprietan al niño en un rincón. Cambia el trabajo, hace falta una oficina: pero no hay dónde, todo está fijado, así que trabajan en la mesa del comedor. Llega el momento de instalar paneles solares, cargadores, fibra: pero la instalación eléctrica se calculó para los electrodomésticos de hace veinte años, y actualizarla implica romper paredes. Cada necesidad nueva pelea contra una casa que se declaró terminada, y cada pelea es más cara que la anterior, porque cada arreglo se apila sobre los parches del anterior. La casa no falló por un golpe; se volvió inhabitable por acumulación.
La casa que se habita. Otra pareja construye pensando distinto: la casa no es una obra que se termina, es un espacio que se va a habitar y a cambiar durante décadas. Así que dejan cosas puestas para el futuro que no conocen: muros interiores no estructurales, fáciles de mover; una instalación eléctrica con capacidad de sobra y registros accesibles; un desván que se puede convertir en cuarto; tuberías con tomas tapadas donde algún día habrá un baño. Nada de eso es construir el cuarto del hijo o la oficina por adelantado —no saben aún que vendrán—; es dejar la casa dispuesta a recibirlos. Cuando llega el hijo, mover un muro no estructural es un fin de semana. Cuando llega el trabajo remoto, el desván se convierte en oficina en dos semanas. Cuando llegan los paneles, la instalación ya tenía capacidad. La casa envejece bien, no porque adivinaran el futuro, sino porque nunca se declaró terminada: se diseñó para seguir cambiando.
Aquí está el punto, y es sutil: la diferencia entre las dos casas no se ve el día que se construyen —las dos se ven perfectas—; se ve a lo largo de los años, en la suma de todos los cambios. La primera casa no es peor el día uno; es peor en el tiempo, porque cada cambio pelea contra una estructura congelada y los costos se acumulan. La segunda no es una casa "más flexible" en abstracto; es una casa que reconoció que iba a cambiar y se postuló para ello. El sistema de software es igual. La arquitectura tratada como "terminada" no falla el día que se lanza —se ve perfecta—; falla en la acumulación de cambios que pelean contra ella. La arquitectura tratada como un flujo envejece bien porque nunca se declaró final. Esta lección mide esa acumulación, que es donde vive la diferencia.
Ejemplo trabajado: el costo acumulado de congelar contra fluir
Vamos a medir lo que la analogía afirma: que la diferencia entre las dos posturas no está en ningún cambio individual, sino en la suma a lo largo de la vida del sistema. Tomamos la misma secuencia de ocho cambios de negocio que Mercado recibe, un trimestre tras otro —los mismos cambios, en el mismo orden, con el mismo costo base—, y los pasamos por dos arquitecturas.
frozen— la arquitectura que se trató como final. Cada cambio pelea contra una estructura que no fue diseñada para moverse, y el drift se acumula: mientras más lejos queda el sistema del diseño congelado original, peor encaja el siguiente cambio. El multiplicador de costo empieza en 1.0 y sube medio punto con cada cambio que se apila.evolving— la arquitectura que se trató como un flujo. Fue postulada para recibir cambios, así que cada uno cuesta cerca de su costo base (un multiplicador constante y bajo, de 1.1). No hay drift acumulado porque el sistema estaba dispuesto a moverse.
Fíjate en el diseño del experimento: el costo base de cada cambio es idéntico en las dos arquitecturas. Lo único que difiere es cómo la estructura recibe el cambio. Así aislamos el efecto de la postura:
# La arquitectura no es un artefacto que se congela el dia uno; es un FLUJO de
# decisiones a lo largo de la vida del sistema. Dos posturas frente a la MISMA
# secuencia de 8 cambios de negocio que Mercado recibe, un trimestre tras otro:
# frozen : se trato la arquitectura como final. Cada cambio pelea contra una
# estructura que no fue disenada para moverse, y el "drift" se acumula:
# mientras mas lejos del diseno original, mas caro encajar el siguiente.
# evolving: se trato la arquitectura como un flujo. Fue disenada para RECIBIR
# cambios, asi que cada uno cuesta cerca de su costo base.
CHANGES = [
# (trimestre, cambio, costo_base_usd)
("Q1", "add_wishlist", 8000),
("Q2", "split_search_service", 12000),
("Q3", "second_payments_provider",10000),
("Q4", "reviews_and_ratings", 14000),
("Q5", "international_currencies", 16000),
("Q6", "seller_self_service_api", 20000),
("Q7", "async_shipping_events", 12000),
("Q8", "recommendations_ml", 18000),
]
def frozen_multiplier(step):
# El drift se acumula: cada cambio deja la estructura mas lejos del diseno
# congelado, asi que el siguiente encaja peor. Empieza en 1.0 y sube 0.5 por paso.
return 1.0 + 0.5 * step
EVOLVING_MULTIPLIER = 1.1 # una arquitectura disenada para recibir cambio cuesta ~su base
print(f"{'trim':<6}{'cambio':<26}{'base':>8}{'frozen':>10}{'evolving':>10}")
print("-" * 60)
frozen_total = evolving_total = 0
for step, (q, name, base) in enumerate(CHANGES):
fc = base * frozen_multiplier(step)
ec = base * EVOLVING_MULTIPLIER
frozen_total += fc
evolving_total += ec
print(f"{q:<6}{name:<26}{base:>8,}{fc:>10,.0f}{ec:>10,.0f}")
print("-" * 60)
print(f"{'TOTAL acumulado (USD)':<40}{frozen_total:>10,.0f}{evolving_total:>10,.0f}")
print()
print("Ningun cambio individual quiebra el sistema; lo que quiebra es la")
print(f"ACUMULACION a lo largo de la vida del sistema: {frozen_total / evolving_total:.1f}x mas caro")
print("tratar la arquitectura como final que como un flujo de decisiones.")Qué esperar. Al correr el archivo, la salida es exactamente esta:
trim cambio base frozen evolving
------------------------------------------------------------
Q1 add_wishlist 8,000 8,000 8,800
Q2 split_search_service 12,000 18,000 13,200
Q3 second_payments_provider 10,000 20,000 11,000
Q4 reviews_and_ratings 14,000 35,000 15,400
Q5 international_currencies 16,000 48,000 17,600
Q6 seller_self_service_api 20,000 70,000 22,000
Q7 async_shipping_events 12,000 48,000 13,200
Q8 recommendations_ml 18,000 81,000 19,800
------------------------------------------------------------
TOTAL acumulado (USD) 328,000 121,000
Ningun cambio individual quiebra el sistema; lo que quiebra es la
ACUMULACION a lo largo de la vida del sistema: 2.7x mas caro
tratar la arquitectura como final que como un flujo de decisiones.
Lee la tabla fila por fila, porque el argumento entero está en cómo se separan las dos columnas con el tiempo.
En el primer cambio (Q1), las dos arquitecturas cuestan casi lo mismo. frozen cuesta 8000, evolving 8800 —de hecho frozen es un poquito más barata al inicio, porque no pagó la "prima" de estar postulada para el cambio (el multiplicador 1.1)—. Este es el detalle que engaña a tanta gente: el día uno, congelar se ve igual o mejor que fluir. El arquitecto que congela ahorró la pequeña inversión de dejar el sistema dispuesto a moverse, y en el primer cambio no se nota la diferencia. Igual que las dos casas se ven perfectas el día que se construyen.
Pero mira cómo divergen. En Q4, frozen ya cuesta 35000 contra 15400 de evolving —más del doble—. En Q8, el mismo tipo de cambio (recommendations_ml, base 18000) cuesta 81000 en la arquitectura congelada contra 19800 en la fluida —más de cuatro veces—. El costo base es idéntico; lo que cambió es que en frozen el drift se acumuló: cada cambio dejó la estructura más lejos de su diseño original, así que el octavo cambio tiene que abrirse paso a través de siete capas de parches previos. En evolving, el octavo cambio cuesta casi lo mismo que el primero, porque la estructura seguía dispuesta a recibirlo.
Y ahí está la lección, en los totales: 328000 contra 121000, 2.7 veces más caro. Pero el número que importa no es el 2.7; es de dónde sale. No sale de ningún cambio catastrófico —no hubo un "gran rediseño" que costó una fortuna—. Sale de la acumulación: ocho cambios normales, cada uno un poco más caro en la arquitectura congelada, que sumados triplican el costo. Este es el corazón de por qué "la arquitectura nunca es final" es una postura y no una frase bonita: el que trata la arquitectura como terminada no paga el día uno —paga en cuotas crecientes durante toda la vida del sistema, y la factura total es brutal—.
Como barras, la divergencia por trimestre se ve así:
Costo por cambio (USD): frozen vs evolving, trimestre a trimestre
Q1 frozen |## 8,000 evolving |## 8,800
Q4 frozen |######### 35,000 evolving |### 15,400
Q8 frozen |#################### 81,000 evolving |### 19,800
─────────────────────
frozen se dispara; evolving se mantiene plano. La brecha ES la postura.
Profundización: por qué "final" es la palabra peligrosa
El experimento modeló el drift acumulado con un multiplicador que crece, y vale la pena entender qué representa ese crecimiento en el mundo real, porque no es un truco del modelo: es un fenómeno bien documentado.
Cuando una arquitectura se trata como final, cada cambio que el negocio impone se implementa contra la estructura, no con ella. Como la estructura no fue diseñada para ese cambio, el cambio se mete como puede: un parche aquí, una excepción allá, una dependencia nueva que cruza una frontera que "no debería" cruzar. Cada uno de esos parches deja el sistema un poco más lejos de cualquier diseño coherente, y —esto es lo clave— hace que el siguiente cambio sea más difícil, porque ahora hay que entender y sortear también los parches anteriores. Es un interés compuesto: el desorden de hoy encarece el trabajo de mañana, que a su vez agrega más desorden. Eso es exactamente lo que la guía hermana architecture-decisions estudia como deuda técnica —y su mecánica, cómo medirla y pagarla, es de esa guía, no de esta—. Aquí lo que importa es la postura que la genera: la deuda técnica no nace de programadores descuidados; nace, en buena parte, de tratar la arquitectura como un artefacto terminado que hay que defender en vez de un flujo que hay que acompañar.
Hay una razón psicológica por la que "final" es tan tentador, y conviene nombrarla. Un diseño terminado se siente como un logro. Cuesta esfuerzo, se presenta, se aprueba, y produce la sensación de haber cerrado algo. Un flujo, en cambio, no se cierra nunca: siempre está en curso, siempre hay una decisión más por venir. Para un arquitecto que necesita la satisfacción de "terminar", el flujo es incómodo —parece que el trabajo nunca acaba—. Pero esa incomodidad es la señal de haber entendido el oficio: el trabajo del arquitecto, por diseño, no acaba mientras el sistema viva. No es un defecto del rol; es su naturaleza. El arquitecto que busca la paz de "ya está terminado" va a tratar cada cambio posterior como una intrusión, y va a congelar. El que hace las paces con el flujo va a recibir cada cambio como lo normal, y va a fluir.
Y hay un matiz que evita el malentendido opuesto, importante para no caer del otro lado. "La arquitectura nunca es final" no significa "rediséñala todo el tiempo" ni "nunca te comprometas con nada". Un arquitecto que rehace la estructura cada trimestre por moda o por ansiedad es tan dañino como el que la congela —de hecho, es la parálisis por el otro extremo—. Fluir no es cambiar por cambiar; es estar dispuesto y postulado a cambiar cuando el negocio lo pida, y quieto cuando no. La arquitectura fluida del ejemplo no se rediseñó ocho veces; se diseñó una vez para recibir los ocho cambios baratos. La postura correcta es un compromiso estable con una estructura que, a propósito, dejó margen para moverse —ni el congelamiento que pelea contra todo cambio, ni el nerviosismo que no se compromete con nada—. Esa calibración fina es justo lo que las lecciones 5, 6 y 7 van a enseñar a medir: dónde dejar margen (costura) y dónde no.
Una consecuencia para cómo el arquitecto mide su propio trabajo. Si la arquitectura es un flujo, entonces el arquitecto no debería medir su éxito por "qué tan bueno fue el diseño inicial" —esa métrica premia congelar—, sino por "qué tan barato le sale al sistema absorber los cambios que el negocio pide". Un diseño inicial elegante que encarece cada cambio posterior es un mal diseño, por bonito que fuera el día uno; un diseño inicial modesto que recibe cambios baratos durante años es un gran diseño. La métrica del oficio no es la belleza del plano; es la pendiente del costo de cambio a lo largo del tiempo. La arquitectura frozen tenía, quizá, un diseño inicial más "limpio" (no pagó la prima de las costuras); su pendiente la hundió. La evolving pagó un poco más el día uno y mantuvo la pendiente plana. Esa pendiente es lo que un arquitecto que entiende el flujo vigila.
Errores comunes
Declarar la arquitectura "terminada" y defenderla. Qué pasa: el arquitecto invierte en un diseño inicial, lo aprueba, y a partir de ahí trata los cambios del negocio como amenazas a una obra concluida —"eso rompe la arquitectura"— en vez de como el estado normal de un sistema vivo. El sistema acumula parches porque nadie quiere moverlo "de verdad". Por qué pasa: un diseño terminado se siente como un logro que da paz, y el flujo —que nunca cierra— es incómodo; además, la gramática de "el sistema es así" empuja a pensar en fotos. Cómo detectarlo: si escuchas "eso rompe la arquitectura" ante features razonables, si cada cambio se vive como emergencia, o si el arquitecto se resiste a tocar la estructura aunque el negocio claramente cambió, se está defendiendo una foto. Cómo corregirlo: adoptar la métrica del flujo —medir la pendiente del costo de cambio, no la belleza del plano— y recibir cada cambio como lo esperado. El ejemplo lo mide: la postura congelada cuesta 2.7 veces más en total, no por un cambio, sino por la acumulación.
Confundir "no final" con "rediséñalo todo el tiempo". Qué pasa: el arquitecto, entendiendo a medias que la arquitectura no es final, cae del otro lado: reestructura por moda o por ansiedad, nunca se compromete con nada, y el equipo vive en una obra permanente que jamás se estabiliza. Por qué pasa: se lee "fluir" como "cambiar", cuando fluir es "estar dispuesto a cambiar cuando haga falta". Cómo detectarlo: si la estructura base cambia cada pocos meses sin que el negocio lo haya pedido, si hay migraciones perpetuas que nadie termina, o si el equipo no puede construir sobre nada estable, es cambio por cambio. Cómo corregirlo: comprometerse con una estructura estable que, a propósito, dejó margen para moverse —y moverla solo cuando el negocio lo justifique, no por reflejo—. La arquitectura fluida del ejemplo se diseñó una vez para recibir ocho cambios, no se rediseñó ocho veces.
Juzgar el diseño solo por el día uno. Qué pasa: se evalúa una arquitectura por qué tan limpia y elegante se ve al lanzarla, no por cómo envejece —y se premia el diseño que ahorró la "prima" de las costuras porque el día uno se ve más barato y más pulcro—. Por qué pasa: el día uno es visible y presentable (un diagrama bonito, un lanzamiento exitoso); la pendiente del costo de cambio es invisible hasta que se acumula, meses después. Cómo detectarlo: si la conversación sobre una arquitectura termina el día del lanzamiento, o si nadie mira cuánto cuesta cambiarla seis meses después, se está juzgando la foto. Cómo corregirlo: juzgar (y revisar) las arquitecturas por su pendiente de costo de cambio en el tiempo, no por su elegancia inicial; en el ejemplo, frozen empezó más barata (8000 vs 8800 en Q1) y terminó tres veces más cara. El día uno miente; la acumulación dice la verdad.
Ejercicios
Ejercicio 1 — La trampa del primer cambio. En el ejemplo, la arquitectura frozen es más barata que evolving en el primer cambio (8000 contra 8800). Un ingeniero mira ese primer número y concluye: "congelar es más barato, dejémoslo así, no paguemos la prima de las costuras". Explica por qué esa conclusión es un error, y qué tendría que mirar en su lugar.
Ver solución
La conclusión es un error porque mira una foto de un flujo. El primer cambio es el único momento en que congelar se ve mejor, precisamente porque frozen no pagó la pequeña prima (el multiplicador 1.1) de dejar el sistema postulado para el cambio. Pero esa prima no es un desperdicio: es la inversión que mantiene la pendiente del costo de cambio plana. En el segundo cambio frozen ya cuesta más (18000 vs 13200), y la brecha solo crece: en Q8, frozen cuesta 81000 contra 19800. El ingeniero está optimizando el primer dato de una serie que va a divergir dramáticamente.
Lo que tendría que mirar no es el costo del primer cambio, sino la pendiente del costo de cambio a lo largo del tiempo —el total acumulado sobre la vida del sistema—. Ahí frozen cuesta 328000 y evolving 121000: 2.7 veces más. La regla del oficio: nunca juzgues una arquitectura por su costo el día uno (la foto), júzgala por cómo envejece el costo de cambiarla (la película). El día uno miente a favor de congelar; la acumulación cuenta la verdad. Es exactamente el error de las dos casas: las dos se ven perfectas el día que se construyen, y la diferencia solo aparece en los años de cambios.
Ejercicio 2 — De dónde sale el 2.7x. El texto insiste en que el número que importa no es el 2.7, sino de dónde sale. Explica, sin código, qué representa el multiplicador creciente de frozen (1.0, 1.5, 2.0, ...) en términos reales de un sistema de software, y por qué ese crecimiento es el mecanismo del daño —conéctalo con la idea de deuda técnica y con la frontera del ecosistema—.
Ver solución
El multiplicador creciente de frozen representa el drift acumulado: cada cambio que se mete a la fuerza contra una estructura no diseñada para él deja el sistema un poco más lejos de cualquier diseño coherente —un parche, una excepción, una dependencia que cruza una frontera que no debía—. Y el punto clave es que ese desorden encarece el siguiente cambio: el cambio número ocho no solo tiene que hacer su propio trabajo, sino entender y sortear los siete parches anteriores. Por eso el multiplicador sube: no es que los cambios sean intrínsecamente más caros, es que la estructura sobre la que caen está cada vez más enredada por los cambios previos.
Eso es un interés compuesto: el desorden de hoy cobra intereses en el trabajo de mañana, que agrega más desorden, que cobra más intereses. Es precisamente el mecanismo de la deuda técnica: una estructura tratada como final acumula deuda con cada cambio forzado, y la deuda se paga con intereses en cada cambio futuro. Aquí está la frontera del ecosistema: cómo medir esa deuda, cuándo pagarla, cómo clasificarla, es la mecánica que enseña la guía hermana architecture-decisions. Lo que esta lección aporta es la postura que la origina: la deuda técnica no viene principalmente de código descuidado, sino de tratar la arquitectura como un artefacto terminado que se defiende, en vez de un flujo que se acompaña. La arquitectura evolving, con su multiplicador plano de 1.1, no acumula esa deuda porque cada cambio se recibe con la estructura, no contra ella.
Ejercicio 3 — Fluir no es rediseñar. Un arquitecto de Mercado, convencido de que "la arquitectura nunca es final", empieza a reestructurar el sistema cada trimestre: un trimestre migra a un patrón, al siguiente a otro, siempre persiguiendo el "diseño evolutivo perfecto". El equipo se queja de que nunca hay una base estable sobre la que construir. ¿Malinterpretó la lección? Explica qué es fluir de verdad, y cómo se distingue del cambio por cambio.
Ver solución
Sí, la malinterpretó, y del lado opuesto al congelamiento —pero es igual de dañino—. Confundió "la arquitectura nunca es final" con "hay que estar rediseñándola siempre". Fluir no es cambiar la estructura todo el tiempo; es estar dispuesto y postulado a cambiarla cuando el negocio lo pida, y quedarse quieto cuando no. Este arquitecto está cambiando por reflejo, por moda o por ansiedad de perfección, sin que ningún cambio de negocio lo justifique. El resultado —un equipo sin base estable, en obra perpetua— es el mismo tipo de daño que el congelamiento, solo que por el otro extremo: la parálisis del que nunca se compromete.
Fluir de verdad se distingue del cambio por cambio por su detonante: el arquitecto que fluye mueve la estructura cuando una suposición cae y el negocio empuja una costura —un cambio real, externo, que la arquitectura estaba postulada para recibir—; el que cambia por cambio mueve la estructura por impulsos internos, sin detonante de negocio. Fíjate en el ejemplo: la arquitectura evolving no se rediseñó ocho veces. Se diseñó una sola vez, con las costuras puestas, para recibir los ocho cambios baratos. Eso es fluir: un compromiso estable con una estructura que, a propósito, dejó margen para moverse. La calibración —cuándo el margen se justifica y cuándo no— es lo que miden las lecciones 5, 6 y 7. La postura correcta vive en el medio: ni el congelamiento que pelea contra todo cambio, ni el nerviosismo que no deja nada quieto.
Resumen y siguiente paso
En esta lección convertiste la tesis en una postura operativa: la arquitectura no es un artefacto que se congela, sino un flujo de decisiones que corre toda la vida del sistema. Viste, con las dos casas, que la diferencia entre congelar y fluir no se ve el día uno —las dos se ven perfectas— sino en la acumulación de cambios a lo largo de los años. Y lo mediste: pasando la misma secuencia de ocho cambios por las dos arquitecturas, la congelada cuesta 328000 y la fluida 121000 —2.7 veces más— no por ningún cambio catastrófico, sino por la acumulación de ocho cambios normales, cada uno un poco más caro en la estructura que se trató como final. Aprendiste que la métrica del oficio no es la belleza del plano inicial, sino la pendiente del costo de cambio en el tiempo, y que "no final" no significa "rediseña siempre" —fluir es estar postulado a cambiar cuando el negocio lo pida, no cambiar por reflejo—.
Antes de avanzar deberías poder: explicar por qué el costo de congelar no se ve el día uno sino en la acumulación; conectar el multiplicador creciente con la deuda técnica (y ubicar su mecánica en la guía hermana); y distinguir fluir (postulado a cambiar) de cambiar por cambio (obra perpetua).
La lección 3 toma la segunda pieza de la postura: la optionality, mantener las puertas abiertas. Si la arquitectura es un flujo que va a recibir cambios inciertos, ¿cuánto vale dejar una opción abierta para un cambio que quizá venga? Vas a ver que una opción abierta tiene valor aunque nunca la ejerzas —como un seguro— pero que cuesta una prima, y a ejecutar el punto de equilibrio: cuándo esa prima vale la pena y cuándo se desperdicia. Con números, para que "mantén las puertas abiertas" deje de ser un consejo y sea una decisión medible.
Recursos
- Neal Ford, Rebecca Parsons y Patrick Kua, Building Evolutionary Architectures (O'Reilly, 2017), cap. 1 ("Software Architecture") — el desarrollo canónico de la idea de esta lección: la arquitectura como algo que evoluciona guiado por fitness functions, no un artefacto que se congela. En inglés.
- Martin Fowler, "Is Design Dead?" (2004) — martinfowler.com/articles/designDead.html. Sobre cómo el diseño no muere con lo evolutivo, sino que cambia de naturaleza: de un plano terminado a una práctica continua. La distinción foto/película de esta lección. En inglés.
- Andrew Hunt y David Thomas, The Pragmatic Programmer, 20th Anniversary Edition (Addison-Wesley, 2019), tema "Reversibility" — la raíz de por qué no hay decisiones finales y por qué el software que envejece bien es el que no se casó con supuestos irreversibles. En inglés.
- Mark Richards y Neal Ford, Fundamentals of Software Architecture, 2ª ed. (O'Reilly, 2020), cap. 19 ("Architecture Decisions") — sobre por qué las decisiones significativas se miden por su costo de cambio en el tiempo, la métrica de la "pendiente" que trabaja esta lección. La mecánica de la deuda técnica y el último momento responsable vive en la guía hermana
architecture-decisions. En inglés.