Módulo 6: Diseñar para el cambio

La arquitectura sacrificial

Descripción

Las dos lecciones anteriores dieron dos maneras de tratar con un futuro incierto: verlo como un flujo que va a llegar (lección 2) y mantener puertas abiertas para él (lección 3). Esta lección da una tercera, y es la más contraintuitiva de todas: a veces la mejor manera de manejar la incertidumbre no es preparar el sistema para el cambio, sino construir a sabiendas algo que vas a tirar. Una arquitectura sacrificial es una pieza que se construye sabiendo desde el principio que se reemplazará —un prototipo, un primer sistema, un andamio— cuyo trabajo no es durar, sino enseñar: validar una idea, descubrir los requisitos reales, reducir la incertidumbre para que la versión que sí va a durar se construya bien. Y luego se desecha, sin culpa, porque cumplió su función.

Esto suena a herejía en una cultura que premia "construir bien de una" y trata tirar código como un fracaso. Pero es una consecuencia directa de la tesis del módulo. Si la arquitectura es un flujo y el diseño del día uno se erosiona (lección 2), y si el mayor riesgo es construir algo caro sobre suposiciones equivocadas, entonces gastar poco para aprender antes de gastar mucho es de las inversiones más rentables que hace un arquitecto. El prototipo desechable es barato; lo que compra —la certeza sobre qué construir de verdad— vale mucho más que su costo. Esta lección lo mide: compara construir "de producción" desde el día uno bajo incertidumbre (arriesgándose a reconstruir todo si las suposiciones fallan) contra construir primero un prototipo sacrificial que reduce esa incertidumbre —y muestra cuándo el andamio se paga solo—.

Conexión con el módulo. Es la tercera pieza de la postura básica (flujo, optionality, sacrificial). Se conecta directo con la lección 3: la sacrificial architecture es una forma de comprar información en vez de comprar una opción —cuando la incertidumbre no es "¿vendrá este cambio?" sino "¿qué es lo que de verdad necesitamos construir?", un prototipo desechable resuelve esa duda barato—. Y se conecta con los dos abismos que vienen: construir el sistema "de producción" bajo incertidumbre alta es una forma de over-engineering (construyes caro algo que no sabías si servía). Frontera con la guía hermana: aquí no medimos deuda técnica ni clasificamos la decisión formalmente; trabajamos la postura del arquitecto que se permite construir para tirar, y sabe cuándo eso es sabiduría y no desperdicio.

Una analogía: el andamio que levanta el edificio y luego se retira

Mira cualquier edificio en construcción y verás algo curioso: buena parte de lo que hay en la obra no va a ser parte del edificio. El andamio que rodea la fachada, la cimbra de madera que sostiene el concreto mientras fragua, la grúa, las rampas provisionales, el barracón de los obreros. Todo eso se construye con esfuerzo y dinero, se usa durante meses, y luego se retira y se desecha. Nadie mira un edificio terminado y dice "qué desperdicio, gastaron en un andamio que ya no está". Al contrario: el andamio es lo que hizo posible construir el edificio bien. Sin él, no habría cómo levantar los muros ni colar los techos en su sitio.

Piensa en la cimbra en particular, porque es la analogía más exacta. Cuando se cuela una losa de concreto, el concreto es líquido: no se sostiene solo. Así que primero se arma una estructura de madera —la cimbra— con la forma exacta de la losa, se vierte el concreto encima, y se espera a que fragüe. Cuando el concreto ya es sólido y se sostiene por sí mismo, se retira la cimbra. La cimbra nunca fue parte del edificio; fue el molde temporal que le dio forma al edificio mientras se endurecía. Construirla fue trabajo real, con madera real y horas reales, y desecharla es lo correcto —quedarse con la cimbra pegada a la losa "para no desperdiciarla" sería absurdo, arruinaría el edificio—.

Ahora piensa en dos maestros de obra frente a una losa de una forma nueva y complicada que nunca han hecho. El primero desprecia la cimbra: "la cimbra es desperdicio, colemos el concreto directo con soportes definitivos". Como no probó la forma antes, la losa sale torcida, el concreto se derrama, y hay que picar todo y rehacerlo —esta vez sí con cimbra—. Pagó el error de saltarse el andamio. El segundo arma primero una cimbra barata, prueba que la forma funciona, ajusta, y solo entonces cuela el concreto definitivo, que sale perfecto a la primera. Gastó en una cimbra que tiró —pero esa cimbra le ahorró rehacer la losa entera—.

Aquí está el punto: construir a sabiendas algo que se va a tirar no es desperdicio; es el andamio que hace posible construir bien lo que sí va a durar. El prototipo sacrificial de software es la cimbra: se construye barato, se usa para descubrir la forma correcta —los requisitos reales, la que funciona—, y se desecha cuando el sistema "de producción" ya se sostiene solo. El arquitecto que desprecia el prototipo "porque es desperdicio" es el primer maestro de obra: cuela el concreto sobre una forma que no probó, y paga el rework de rehacer la losa. Esta lección mide cuándo la cimbra se paga sola.

Ejemplo trabajado: el prototipo desechable contra construir "de una"

Vamos a poner número a cuándo conviene la cimbra. Mercado quiere construir una capacidad nueva —digamos, un sistema de recomendaciones— y hay incertidumbre sobre los requisitos: no está claro qué datos importan, qué forma debe tener, si el enfoque funcionará. Comparamos dos maneras de construirla:

build_to_keep — construir la arquitectura "de producción" desde el día uno. Cuesta P (la construcción de producción, cara). Pero con incertidumbre alta hay una probabilidad q de haber construido lo equivocado —descubierto solo después de construirlo, cuando ya está en uso o casi—, y entonces hay que reconstruir: pagar P otra vez. Es colar el concreto sin cimbra.
sacrificial — construir primero un prototipo barato y desechable (cuesta S, mucho menos que P) cuyo único trabajo es aprender los requisitos reales. Se tira, y con lo aprendido la versión de producción se construye bien a la primera (cuesta P, sin reconstrucción). Es armar la cimbra, probar la forma, y colar el concreto una sola vez.

La comparación depende de q, la incertidumbre de requisitos. build_to_keep cuesta P + q × P (produce y, con probabilidad q, reconstruye). sacrificial cuesta S + P (tira el prototipo pero construye producción una sola vez):

# Sacrificial architecture: construir A SABIENDAS algo que se va a tirar. Un
# prototipo barato que VALIDA y luego se reemplaza. Comparamos dos formas de
# construir una capacidad nueva de Mercado bajo incertidumbre de requisitos:
#   build_to_keep : invertir en una arquitectura "de produccion" desde el dia 1.
#                   Cuesta P. Pero con incertidumbre alta hay probabilidad q de
#                   haber construido lo equivocado -> se reconstruye -> se paga P otra vez.
#   sacrificial   : construir primero un prototipo BARATO y desechable (cuesta S)
#                   para aprender los requisitos reales; se tira, y con lo aprendido
#                   la version de produccion se hace BIEN a la primera (cuesta P, sin rebuild).
PROD_COST  = 100000  # P: construir la version de produccion
PROTO_COST = 15000   # S: el prototipo desechable, barato


def expected_build_to_keep(q):
    # paga produccion y, con probabilidad q, la reconstruye entera
    return PROD_COST + q * PROD_COST


def expected_sacrificial():
    # tira el prototipo (S) pero construye produccion BIEN una sola vez
    return PROTO_COST + PROD_COST


breakeven_q = PROTO_COST / PROD_COST

print(f"{'incertidumbre q':>16}{'build_to_keep':>16}{'sacrificial':>14}   gana")
print("-" * 62)
for q in [0.10, 0.20, 0.30, 0.60, 0.80]:
    btk = expected_build_to_keep(q)
    sac = expected_sacrificial()
    winner = "sacrificial" if sac < btk else "build_to_keep"
    print(f"{q:>16.2f}{btk:>16,.0f}{sac:>14,.0f}   {winner}")
print("-" * 62)
print(f"Punto de equilibrio: q = {breakeven_q:.2f} ({breakeven_q * 100:.0f}%).")
print(f"Cuando la incertidumbre de requisitos supera {breakeven_q * 100:.0f}%, tirar 15,000 USD")
print("en un prototipo desechable sale mas barato que arriesgar reconstruir")
print("los 100,000 de produccion. El andamio se paga para levantar bien el edificio.")

Qué esperar. Al correr el archivo, la salida es exactamente esta:

 incertidumbre q   build_to_keep   sacrificial   gana
--------------------------------------------------------------
            0.10         110,000       115,000   build_to_keep
            0.20         120,000       115,000   sacrificial
            0.30         130,000       115,000   sacrificial
            0.60         160,000       115,000   sacrificial
            0.80         180,000       115,000   sacrificial
--------------------------------------------------------------
Punto de equilibrio: q = 0.15 (15%).
Cuando la incertidumbre de requisitos supera 15%, tirar 15,000 USD
en un prototipo desechable sale mas barato que arriesgar reconstruir
los 100,000 de produccion. El andamio se paga para levantar bien el edificio.

Lee la columna del ganador de arriba abajo, porque el cruce cuenta toda la historia.

Con q = 0.10 (baja incertidumbre), gana build_to_keep. Cuando estás bastante seguro de los requisitos —solo 10% de probabilidad de haberte equivocado—, construir directo la versión de producción sale más barato: 110000 contra 115000 del camino sacrificial. Aquí el prototipo sería un rodeo innecesario —armar cimbra para una losa que ya sabes hacer con los ojos cerrados—. Cuando sabes qué construir, constrúyelo. El prototipo sacrificial no es un ritual que se hace siempre; es una respuesta a la incertidumbre, y si no hay incertidumbre, no hace falta.

A partir de q = 0.20 (incertidumbre moderada), gana sacrificial, y la ventaja crece rápido. Con 20% de incertidumbre, el prototipo ya conviene (115000 vs 120000). Con 60%, la diferencia es enorme: 115000 contra 160000. Con 80%, 115000 contra 180000. Fíjate en el patrón: el costo de sacrificial es plano (siempre 115000), porque el prototipo elimina la incertidumbre —después de aprender, la producción se construye bien una sola vez, sin importar cuán confuso fuera el problema al inicio—. El costo de build_to_keep crece con la incertidumbre, porque mientras más confuso el problema, más probable reconstruir los 100000 de producción. El prototipo compra certeza a precio fijo; construir de una deja la factura expuesta a la incertidumbre.

Y en el medio, el punto de equilibrio: q = 15%. Sale de S / P = 15000 / 100000. La regla que da: cuando la incertidumbre de requisitos supera el 15%, tirar 15000 en un prototipo desechable sale más barato que arriesgar reconstruir los 100000 de producción. Debajo de ese umbral (sabes bien qué construir), constrúyelo directo. Encima (no estás seguro), construye la cimbra primero. El número convierte "¿hago un prototipo o voy directo?" —que suele decidirse por gusto o por prisa— en una comparación con un umbral.

Fíjate en lo que el modelo captura y que es el corazón de por qué la sacrificial architecture no es desperdicio: el prototipo sacrificial "desperdicia" 15000 en algo que se tira, pero ese gasto compra la eliminación de la incertidumbre, que en build_to_keep cuesta un valor esperado de q × 100000 en reconstrucción. Con q = 60%, esa incertidumbre expuesta vale 60000 esperados; pagar 15000 por eliminarla es un negocio redondo. El arquitecto que dice "no hagamos prototipo, es tirar dinero" ve los 15000 que se desechan, pero no ve los 60000 esperados que se está arriesgando a pagar en rework. La cimbra que se retira no es el desperdicio; saltarse la cimbra y picar la losa es el desperdicio.

Como barras, con q = 0.60:

Costo esperado total (USD), incertidumbre q = 60%
 build_to_keep |################################  160,000
 sacrificial    |#######################           115,000
                 ────────────────────────────────
 El prototipo tira 15,000 pero evita 60,000 esperados de reconstruccion.

Profundización: qué es y qué no es una arquitectura sacrificial

El concepto tiene bordes que conviene afilar, porque es fácil confundir una sacrificial architecture con cosas que no lo son —y esa confusión lleva a usarla mal o a rechazarla por las razones equivocadas—.

Lo que sí es. Una arquitectura sacrificial es una pieza construida con la intención explícita, desde el principio, de reemplazarla. La intención es lo que la define. No es "construimos algo, salió mal, y lo tiramos" —eso es un error—; es "construimos algo barato para aprender, sabiendo que lo tiraríamos, y lo tiramos porque ya cumplió". Martin Fowler da el ejemplo clásico: eBay, Amazon y otros gigantes construyeron primeros sistemas que sabían que no escalarían, los usaron para validar el negocio y aprender el dominio, y los reemplazaron cuando el negocio lo justificó. Esos primeros sistemas no fueron fracasos; fueron andamios que hicieron posible el edificio real. Su valor no estuvo en durar, sino en enseñar y en llevar el producto al mercado mientras la incertidumbre era máxima.

Lo que no es —tres confusiones peligrosas—. Primero, no es una excusa para construir mal sin intención de reemplazar. "Lo hacemos rápido y sucio y ya luego lo arreglamos" no es una arquitectura sacrificial si no hay un plan real de reemplazo; es simplemente deuda técnica disfrazada, y el "luego" no llega nunca. La sacrificial architecture exige el compromiso explícito de tirar el prototipo —si te vas a quedar con él, no era sacrificial, era producción disfrazada de prototipo, y ahí está el peligro—. Segundo, no es un prototipo que se cuela a producción. El error más común y más caro: se construye un prototipo desechable, funciona, y por prisa o por inercia se pone en producción "temporalmente" —y el temporal se vuelve permanente—. Ahora tienes un sistema de producción hecho con la calidad de una cimbra: es dejar la cimbra pegada a la losa. El prototipo sacrificial tiene que desecharse; si sobrevive, dejó de ser sacrificial y se volvió un problema. Tercero, no es lo mismo que un spike. Un spike es una exploración de horas o días para responder una pregunta técnica puntual; una arquitectura sacrificial puede ser un sistema entero que vive meses en producción real mientras el negocio madura. Comparten el ADN —construir para aprender— pero difieren en escala.

La disciplina que hace que funcione: comprometerse a tirar. El riesgo de toda arquitectura sacrificial no es construirla; es no tener el valor de desecharla cuando toca. Un prototipo que funciona genera una presión enorme para conservarlo —"ya funciona, ¿para qué rehacerlo?"—, y ceder a esa presión convierte el andamio en estructura permanente, con todas sus deficiencias. Por eso el arquitecto que usa la sacrificial architecture bien establece desde el inicio, y lo comunica, que la pieza se va a reemplazar: pone la fecha o la condición del reemplazo por escrito (aquí el ADR es el vehículo —su mecánica es la guía hermana architecture-decisions y su uso comunicativo el módulo 3—), para que "lo tiramos" sea una decisión tomada de antemano y no una discusión que se pierde bajo la presión de conservar lo que ya anda. Igual que el maestro de obra sabe, desde antes de armar la cimbra, que la va a retirar: no es una duda que resuelve al final, es parte del plan.

Cómo se relaciona con la optionality de la lección 3. Las dos manejan incertidumbre, pero de tipos distintos, y conviene no confundirlas. La optionality maneja la incertidumbre sobre si un cambio vendrá —mantienes una puerta abierta por si acaso—. La sacrificial architecture maneja la incertidumbre sobre qué construir —construyes algo barato para descubrir la respuesta—. Una compra el derecho a reaccionar; la otra compra información. Y hay un puente entre ambas: el prototipo sacrificial, al reducir la incertidumbre sobre qué construir, te dice dónde poner las costuras de verdad en la versión de producción —o sea, qué opciones comprar—. Aprendes con la cimbra cuáles muros de la casa definitiva conviene dejar móviles. Por eso las tres piezas —flujo, optionality, sacrificial— forman una postura coherente: ver el sistema como una película, mantener abiertas las puertas que la probabilidad justifica, y construir para tirar cuando la mejor inversión es aprender barato antes de gastar caro.

Errores comunes

Despreciar el prototipo "porque es tirar dinero". Qué pasa: el arquitecto se niega a construir un prototipo desechable bajo incertidumbre alta —"no gastemos en algo que vamos a tirar, hagámoslo bien de una"— y construye directo la versión de producción sobre requisitos que no validó; cuando resultan equivocados, reconstruye. Por qué pasa: ve los 15000 que se desechan (visibles, presentes) pero no ve los q × 100000 esperados que se está arriesgando a pagar en reconstrucción (invisibles, futuros). Cómo detectarlo: si hay incertidumbre real sobre qué construir y aun así se salta directo a la arquitectura de producción "para no desperdiciar", es el maestro que cuela concreto sin cimbra. Cómo corregirlo: comparar el costo del prototipo con el valor esperado de la incertidumbre que elimina —si la incertidumbre supera el punto de equilibrio (S/P), el prototipo se paga solo—. El desperdicio no es la cimbra que se retira; es picar la losa por haberla saltado.

No tener el valor de tirar el prototipo (colarlo a producción). Qué pasa: se construye un prototipo desechable, funciona, y por prisa o inercia se pone en producción "temporalmente"; el temporal se vuelve permanente, y ahora hay un sistema de producción con la calidad de un andamio. Por qué pasa: un prototipo que anda genera una presión fuerte para conservarlo —"ya funciona, ¿para qué rehacerlo?"— y ceder a esa presión se siente eficiente. Cómo detectarlo: si un prototipo que se construyó "para aprender y tirar" lleva meses en producción sin plan de reemplazo, se coló la cimbra al edificio. Cómo corregirlo: comprometerse a tirarlo desde el inicio, por escrito (con la fecha o la condición de reemplazo registrada en un ADR), para que "lo tiramos" sea una decisión ya tomada y no una discusión que se pierde bajo la presión de conservar lo que anda. Si te vas a quedar con él, no era sacrificial —era producción disfrazada—.

Llamar "sacrificial" a construir mal sin plan de reemplazo. Qué pasa: un equipo construye algo rápido y sucio y lo justifica como "arquitectura sacrificial", pero no hay ninguna intención ni plan real de reemplazarlo; es deuda técnica con un nombre elegante. Por qué pasa: el concepto suena sofisticado y da permiso para bajar la calidad, así que se usa como coartada. Cómo detectarlo: si al preguntar "¿cuándo y bajo qué condición se reemplaza esto?" no hay respuesta, o la respuesta es "algún día", no es sacrificial —es deuda—. Cómo corregirlo: exigir que toda arquitectura sacrificial tenga, desde el inicio, el compromiso explícito de reemplazo (fecha o condición), porque la intención de tirar es lo que la define. Sin ese compromiso, "sacrificial" es solo una palabra bonita para "lo hicimos mal y no pensamos arreglarlo".

Ejercicios

Ejercicio 1 — ¿Prototipo o directo? Para cada situación de Mercado, di si construirías un prototipo sacrificial primero o irías directo a la versión de producción, usando la idea del punto de equilibrio de la incertidumbre: (a) Mercado quiere un motor de recomendaciones con machine learning, un dominio que el equipo nunca ha tocado y donde no está claro qué datos ni qué enfoque funcionarán; (b) Mercado quiere agregar un campo "nota del regalo" al checkout, un cambio pequeño y bien entendido; (c) Mercado quiere entrar a un modelo de negocio nuevo (suscripciones) donde ni siquiera está claro qué van a querer los clientes ni cómo se cobrará.

Ver solución

(a) Prototipo sacrificial. La incertidumbre es alta —dominio nuevo, sin claridad sobre datos ni enfoque—: está muy por encima del punto de equilibrio. Construir directo el motor "de producción" arriesga reconstruirlo entero cuando se descubra que el enfoque no servía. Un prototipo desechable —un modelo simple con datos de muestra, para aprender qué funciona— cuesta poco y elimina esa incertidumbre antes de invertir en la versión de producción. Es la cimbra para una losa de forma nueva.
(b) Directo a producción. La incertidumbre es bajísima —un campo de texto en el checkout, cambio pequeño y bien entendido—: está por debajo del punto de equilibrio. Hacer un prototipo desechable de "nota del regalo" sería un rodeo absurdo, armar cimbra para colgar un cuadro. Cuando sabes qué construir, constrúyelo. La sacrificial architecture responde a la incertidumbre; sin incertidumbre, es puro overhead.
(c) Prototipo sacrificial, y de los importantes. La incertidumbre es máxima —no está claro ni qué quieren los clientes ni cómo se cobra—: muy por encima del equilibrio, y además el costo de construir "de producción" un modelo de suscripciones equivocado es enorme. Aquí un prototipo sacrificial (quizá hasta un sistema entero, simple, en producción real con clientes reales, para aprender qué funciona) es la inversión más rentable: valida el negocio y descubre los requisitos reales barato, antes de construir el sistema definitivo. Es el caso de eBay/Amazon: el primer sistema que sabías que ibas a reemplazar, que te llevó al mercado y te enseñó el dominio.

El patrón: la sacrificial architecture se justifica por la incertidumbre. Alta (a, c) → prototipo; baja (b) → directo. No es un ritual que se hace siempre, es una respuesta calibrada a cuánto no sabes.

Ejercicio 2 — El prototipo que se quedó. El equipo de Mercado construyó un prototipo desechable del sistema de suscripciones "para aprender y tirar". Funcionó, y ocho meses después sigue en producción, sin plan de reemplazo, acumulando parches. Explica qué salió mal —qué error de los tres cometió el equipo—, por qué es peligroso, y qué debieron hacer para evitarlo.

Ver solución

El error fue no tener el valor de tirar el prototipo: lo colaron a producción. Se construyó una cimbra —un prototipo con la calidad de algo desechable, hecho para aprender rápido, no para durar— y en vez de retirarla se dejó pegada a la losa. La presión típica lo explica: "ya funciona, ¿para qué rehacerlo?". Pero ceder a esa presión convirtió una arquitectura sacrificial (legítima) en un sistema de producción hecho con calidad de andamio (un problema).

Por qué es peligroso: un prototipo desechable se construye con atajos deliberados —sin la robustez, la seguridad, la escalabilidad ni las costuras que un sistema de producción necesita—, porque su trabajo era enseñar, no durar. Dejarlo en producción significa que el sistema de suscripciones de Mercado —que cobra dinero real a clientes reales— corre sobre esos atajos. Y como no fue diseñado para durar, cada cambio pelea contra él y se acumulan parches (el drift de la lección 2). Peor: cada mes que pasa, reemplazarlo es más caro y más riesgoso, porque más cosas dependen de él. La cimbra pegada a la losa va debilitando el edificio.

Qué debieron hacer: comprometerse a reemplazarlo desde el inicio, por escrito, con una condición o fecha de reemplazo registrada (un ADR: "este prototipo se reemplaza cuando superemos los X suscriptores / antes del trimestre Y"). Ese compromiso previo es lo que blinda la decisión de tirar contra la presión posterior de conservar: cuando llega el momento, "lo reemplazamos" ya es una decisión tomada, no una discusión que se pierde ante "pero ya funciona". La disciplina de la sacrificial architecture no está en construir el prototipo —eso es fácil—; está en tener, de antemano, el compromiso de desecharlo. Sin ese compromiso, no era sacrificial: era deuda técnica que se llamó a sí misma prototipo.

Ejercicio 3 — Los 15000 que se ven y los 60000 que no. Un gerente de Mercado se opone a construir un prototipo sacrificial para el motor de recomendaciones (incertidumbre estimada q = 60%): "¿me estás pidiendo 15000 dólares para construir algo que vamos a tirar? Eso es tirar el dinero. Constrúyanlo bien de una vez". Usando los números del ejemplo, responde a su objeción explicando qué costo está viendo y cuál no.

Ver solución

El gerente está viendo un costo real —los 15000 del prototipo que se desecha— pero está ignorando un costo mucho mayor que su objeción esconde: el valor esperado de la reconstrucción que se arriesga al construir "de una" bajo incertidumbre alta. Con q = 60%, construir directo la versión de producción (build_to_keep) tiene 60% de probabilidad de estar equivocado y necesitar reconstruirse entero, lo que suma un valor esperado de 0.60 × 100000 = 60000 en rework sobre los 100000 de la construcción inicial —160000 esperados en total—.

El prototipo sacrificial cuesta 115000 en total (15000 del prototipo + 100000 de la producción construida bien una sola vez, porque el prototipo eliminó la incertidumbre). O sea: los 15000 que el gerente ve como "tirar dinero" compran la eliminación de una incertidumbre que, sin ellos, vale 60000 esperados en reconstrucción. Es un negocio redondo: gastas 15000 para evitar arriesgar 60000. La respuesta concreta al gerente: "no te estoy pidiendo tirar 15000; te estoy pidiendo gastar 15000 para no arriesgar 60000. Construir 'de una' bajo esta incertidumbre no es más barato, es 45000 más caro en valor esperado (160000 vs 115000). El prototipo no es el desperdicio; el desperdicio sería construir el motor de producción sobre suposiciones que no validamos y tener que rehacerlo".

Es exactamente el maestro de obra que ve la cimbra que se retira ("qué desperdicio de madera") pero no ve la losa que habría que picar y rehacer si cuela el concreto sin ella. El costo visible del andamio esconde el costo mayor —e invisible— de saltárselo.

Resumen y siguiente paso

En esta lección instalaste la tercera pieza de la postura, la más contraintuitiva: la arquitectura sacrificial, construir a sabiendas algo que vas a tirar porque su trabajo es enseñar, no durar. Viste, con el andamio y la cimbra, que construir para desechar no es desperdicio sino el molde temporal que hace posible construir bien lo definitivo —y que el verdadero desperdicio es saltarse la cimbra y picar la losa—. Y lo mediste: bajo incertidumbre de requisitos, un prototipo desechable de 15000 elimina una incertidumbre que, construyendo "de una", costaría hasta 60000 esperados en reconstrucción; el punto de equilibrio está en 15% —por encima, la cimbra se paga sola—. Afilaste los bordes del concepto: la intención explícita de reemplazar es lo que lo define, el mayor riesgo es no tener el valor de tirar el prototipo (colarlo a producción), y "sacrificial" sin plan de reemplazo es solo deuda técnica con nombre elegante.

Antes de avanzar deberías poder: explicar por qué un prototipo desechable no es desperdicio sino compra de información; distinguir una arquitectura sacrificial legítima de un prototipo colado a producción y de deuda técnica disfrazada; y calcular a ojo si la incertidumbre de un cambio justifica construir la cimbra primero.

Con esta lección cerraste las tres piezas de la postura básica —flujo, optionality, sacrificial—. La lección 5 abre la segunda mitad del módulo, la de los dos abismos entre los que camina el arquitecto. Empieza por el primero: el over-engineering, y la línea del YAGNI. Vas a ver el error de construir flexibilidad "por si acaso" para futuros imaginados que casi nunca llegan —el urbanista que pavimenta doce carriles para un pueblo—, y a ejecutar cuánto cuesta cargar toda esa flexibilidad no usada contra pagar el rework solo de los cambios que de verdad arriban. Con números, para que "no lo construyas hasta necesitarlo" deje de ser un eslogan y sea una medición.

Recursos

Martin Fowler, "Sacrificial Architecture" (2014) — martinfowler.com/bliki/SacrificialArchitecture.html. El texto que da nombre a la lección y su tesis: los buenos arquitectos construyen sistemas sabiendo que se reemplazarán, y eso no es fracaso sino estrategia. Los ejemplos de eBay y Amazon vienen de aquí. Corto y esencial. En inglés.
Frederick Brooks, The Mythical Man-Month (Addison-Wesley, 1975), cap. 11 "Plan to Throw One Away" — el origen histórico de la idea: en un proyecto con incertidumbre, vas a construir un sistema que tirarás de todas formas, así que planéalo. Brooks luego matizó (no siempre "uno" entero), pero el principio de construir para aprender sigue vigente. En inglés.
Neal Ford, Rebecca Parsons y Patrick Kua, Building Evolutionary Architectures (O'Reilly, 2017) — sobre por qué diseñar para el reemplazo y la evolución es más realista que diseñar para la permanencia. El marco general del módulo. En inglés.
Andrew Hunt y David Thomas, The Pragmatic Programmer, 20th Anniversary Edition (Addison-Wesley, 2019), temas "Prototypes and Post-it Notes" y "Good-Enough Software" — sobre prototipar para aprender y desechar sin culpa, y por qué el software desechable tiene un propósito distinto del de producción. En inglés.

← AnteriorMantener las puertas abiertas Siguiente →La línea del YAGNI