Módulo 6: Diseñar para el cambio

Pintarse en una esquina

Siguiente →

Descripción

La lección anterior te dejó con una advertencia: si te quedas solo con "no construyas nada por adelantado", caes en el abismo opuesto. Esta lección abre ese segundo abismo, el under-engineering, y su síntoma más gráfico: pintarse en una esquina. Es el error de negarse a dejar ninguna costura —construir lo más barato y directo posible, sin fronteras, sin abstracciones, sin margen— de modo que cuando el cambio probable llega, no hay por dónde entrar: la única salida es reescribir. Donde el over-engineering pecaba por exceso (preparar para todo lo imaginable), el under-engineering peca por defecto (no preparar para lo que casi seguro va a pasar).

Y aquí está la trampa que hace a esta lección necesaria: el under-engineering a menudo se justifica invocando el YAGNI. "No lo vamos a necesitar, hagámoslo simple y directo" suena a la disciplina de la lección 5 —pero aplicada al caso equivocado—. El YAGNI dice "no prepares para lo improbable"; el under-engineering lo tuerce en "no prepares para nada", incluso para los cambios que el negocio claramente va a pedir. La diferencia es la probabilidad del cambio, y confundirlas es cómo un principio sano (no sobre-construyas) se convierte en una excusa para pintarse en una esquina. Esta lección mide el costo de ese error: cuando el cambio es probable, no dejar la costura barata cuesta una fortuna en reescritura.

Conexión con el módulo. Es el segundo abismo (la 5: over-engineering; esta: under-engineering; la 7: el punto sensato). Es el espejo exacto de la lección 5: allá el error era comprar opciones por debajo de su punto de equilibrio (pagar primas por lo improbable); aquí es no comprar opciones por encima de su punto de equilibrio (negarse a la prima barata por lo probable). Juntas, las dos lecciones acorralan el problema desde los dos lados, y dejan a la lección 7 la tarea de encontrar el medio. Frontera con la guía hermana: aquí no clasificamos formalmente la decisión ni medimos deuda técnica; trabajamos la postura del arquitecto que reconoce cuándo la simplicidad se volvió un callejón sin salida, y sabe que YAGNI tiene un límite.

Una analogía: pintar el piso hasta la esquina sin dejar salida

Hay una escena clásica, casi de caricatura, que le da nombre a este error. Alguien pinta el piso de una habitación. Empieza por un rincón y va cubriendo el suelo con pintura fresca, avanzando. Si piensa en el futuro —en cómo va a salir de la habitación—, pinta retrocediendo hacia la puerta, dejándose siempre un camino seco por delante. Pero si solo piensa en cubrir el piso lo más rápido y directo posible, sin mirar hacia dónde va, termina en la esquina más lejana de la puerta, rodeado de pintura fresca por todos lados. Hizo su trabajo —el piso está pintado— pero se pintó en una esquina: no hay manera de salir sin pisar la pintura y arruinarlo todo, o sin esperar horas a que seque. El error no fue pintar; fue pintar sin dejarse una salida.

Lleva la imagen a la casa del módulo. Un dueño construye barato y directo: en vez de dejar muros no estructurales fáciles de mover (la casa de la lección 3), fija todo en concreto —cada muro, cada instalación, cada tubería, soldado, definitivo—. Es más rápido y más barato de construir hoy. Y para la distribución de hoy, funciona perfecto. El problema llega con el cambio que cualquiera podía prever: llega un hijo y hace falta un cuarto, o el trabajo se vuelve remoto y hace falta una oficina. En la casa de muros móviles, eso era un fin de semana. En esta, cada muro es de concreto armado: unir dos cuartos significa demoler estructura, apuntalar, permisos, una obra mayor. El dueño no ahorró; difirió el costo y lo multiplicó. Pagó menos el día uno y pagará mucho más el día —previsible— que la vida cambie.

Fíjate en el contraste con la lección 5, porque es lo que define el abismo opuesto. El urbanista del over-engineering pavimentaba doce carriles para un tráfico que no iba a venir —preparaba de más, para lo improbable—. Este dueño fija todo en concreto ignorando un cambio que sí iba a venir —prepara de menos, para lo probable—. Los dos erran, pero en direcciones contrarias: uno construye el futuro que no llega; el otro se niega a dejar espacio para el futuro que sí llega. Y el under-engineering tiene un agravante psicológico: se disfraza de virtud. "Fijé todo en concreto" suena a "hice algo sólido y simple, sin complicaciones"; nadie lo confiesa como "me pinté en una esquina". Esta lección mide lo que cuesta esa esquina cuando el cambio probable toca la puerta.

Ejemplo trabajado: reescribir sin costura contra la costura barata

Vamos a medir el costo de pintarse en una esquina. La diferencia clave con la lección 5 está en las probabilidades: aquí los cambios no son futuros imaginados improbables; son cambios probables, que el negocio de Mercado casi seguro va a pedir. Cada uno tiene su probabilidad alta (p_happens), el costo de dejar la costura hoy (seam_cost), lo que costaría adaptarse a través de ella si la dejaste (adapt_with_seam), y lo que costaría reescribir si no dejaste ninguna (rewrite_no_seam).

Comparamos dos posturas:

  • no_seam — el under-engineering: no dejar ninguna costura. Cuesta 0 por adelantado (ahorra hoy). Pero cuando el cambio probable llega —y como es probable, llega casi siempre—, no hay por dónde entrar: hay que reescribir, y el costo esperado es p × rewrite_no_seam, con rewrite alto. Es fijar todo en concreto.
  • with_seam — dejar la costura barata. Paga un seam_cost chico por adelantado, y cuando el cambio llega, solo adapta a través de la costura (adapt, barato). Su costo esperado es seam_cost + p × adapt. Es dejar el muro móvil.
# Under-engineering: pintarse en una esquina. El extremo opuesto a YAGNI. Aqui
# los cambios NO son imaginados improbables: son cambios PROBABLES que el negocio
# casi seguro va a pedir. Construir lo mas barato SIN dejar costura ahorra hoy,
# pero cuando el cambio probable llega, no hay por donde entrar: hay que reescribir.
CHANGES = [
    # (nombre, p_happens, seam_cost, adapt_with_seam, rewrite_no_seam)
    ("monolith_to_services",      0.90, 8000, 10000, 90000),
    ("second_payments_provider",  0.85, 4000,  5000, 40000),
    ("swap_notification_channel", 0.80, 3000,  4000, 25000),
]

# no_seam (under-engineered): 0 por adelantado, pero rework catastrofico al llegar.
expected_no_seam = sum(p * rewrite for _, p, _, _, rewrite in CHANGES)
# with_seam: paga una costura barata; al llegar, solo adapta.
expected_with_seam = sum(seam + p * adapt for _, p, seam, adapt, _ in CHANGES)

print(f"{'cambio probable':<28}{'p':>6}{'no_seam(p*rewrite)':>20}{'with_seam':>12}")
print("-" * 66)
for name, p, seam, adapt, rewrite in CHANGES:
    ns = p * rewrite
    ws = seam + p * adapt
    print(f"{name:<28}{p:>6.2f}{ns:>20,.0f}{ws:>12,.0f}")
print("-" * 66)
print(f"{'TOTAL costo esperado (USD)':<34}{expected_no_seam:>20,.0f}{expected_with_seam:>12,.0f}")
print()
print("Cuando el cambio es PROBABLE, no dejar costura no es 'simplicidad': es")
print(f"pintarse en una esquina. Cuesta {expected_no_seam / expected_with_seam:.1f}x mas reescribir sin costura")
print("que haber pagado la costura barata. YAGNI no es 'nunca prepares nada'.")

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

cambio probable                  p  no_seam(p*rewrite)   with_seam
------------------------------------------------------------------
monolith_to_services          0.90              81,000      17,000
second_payments_provider      0.85              34,000       8,250
swap_notification_channel     0.80              20,000       6,200
------------------------------------------------------------------
TOTAL costo esperado (USD)                     135,000      31,450

Cuando el cambio es PROBABLE, no dejar costura no es 'simplicidad': es
pintarse en una esquina. Cuesta 4.3x mas reescribir sin costura
que haber pagado la costura barata. YAGNI no es 'nunca prepares nada'.

Lee la tabla fila por fila, comparando las dos columnas de costo, porque ahí está el argumento.

Fíjate primero en las probabilidades: 0.90, 0.85, 0.80. Todas altas. Estos no son futuros imaginados "por si acaso" como los de la lección 5; son cambios que Mercado casi seguro va a pedir. El monolito casi seguro necesitará partirse en servicios (0.90). Casi seguro habrá un segundo proveedor de pagos (0.85). Casi seguro cambiará el canal de notificaciones (0.80). Esta es la diferencia que lo cambia todo: cuando la probabilidad es alta, el término p × rewrite no es chico —es casi el rewrite completo—.

Mira monolith_to_services. No dejar costura cuesta 0.90 × 90000 = 81000 esperados: con 90% de probabilidad, habrá que reescribir medio sistema para extraer el servicio de un monolito soldado sin fronteras internas. Dejar la costura —una interfaz clara, tablas separadas— cuesta 8000 + 0.90 × 10000 = 17000: la costura de 8000 más una adaptación barata cuando llegue. La diferencia es brutal: 81000 contra 17000. Y ese patrón se repite en las tres filas.

Los totales lo cierran: 135000 sin costura contra 31450 con costura —4.3 veces más caro—. Cuando el cambio es probable, negarse a dejar la costura barata no es simplicidad ni ahorro; es diferir un costo y multiplicarlo. El under-engineering ahorró el seam_cost (8000 + 4000 + 3000 = 15000 en total) el día uno, y a cambio se expuso a 135000 esperados en reescritura. Cambió un ahorro chico y seguro por un costo grande y probable —el espejo exacto del mal negocio del over-engineering, en la dirección contraria—.

Fíjate en el mecanismo, porque es lo que distingue este abismo del anterior. En la lección 5, el over-engineering perdía porque pagaba flexibilidad para futuros improbables (los términos p × rework eran chicos, así que el YAGNI ganaba). Aquí, el under-engineering pierde porque no paga la costura para futuros probables (los términos p × rewrite son grandes, así que la costura gana). La misma estructura de costos, invertida por la probabilidad. Cuando p es baja, no prepares (lección 5); cuando p es alta, prepara (esta lección). El error del under-engineering es aplicar la lógica de la baja probabilidad (YAGNI) a cambios de alta probabilidad —invocar "no lo vamos a necesitar" sobre algo que casi seguro vas a necesitar—.

Como barras, la desproporción:

Costo total esperado (USD): sin costura vs con costura, cambios PROBABLES
 no_seam    |####################################  135,000
 with_seam  |########                               31,450
             ────────────────────────────────────
 4.3x mas caro reescribir sin costura que haber
 dejado la costura barata para el cambio probable.

Profundización: cuándo la simplicidad se vuelve un callejón

El under-engineering es traicionero porque se apoya en valores reales —la simplicidad, evitar la complejidad prematura, el YAGNI— y los lleva un paso demasiado lejos. Vale la pena entender dónde está exactamente ese paso, porque la línea entre "simplicidad sana" y "callejón sin salida" es fina y decide de qué lado del abismo caes.

La simplicidad sana elimina lo accidental; el under-engineering elimina lo esencial. Simplificar bien es quitar complejidad que no aporta: la abstracción especulativa, la capa de configuración que nadie usa, la generalización prematura (todo lo que la lección 5 combate). Eso es correcto y valioso. El under-engineering hace algo distinto: quita una frontera que sí aportaba —la costura entre orders y payments, la interfaz que separaba el catálogo—, porque en el momento se ve como "complejidad innecesaria". La diferencia está en si lo que quitas protege contra un cambio probable. Quitar el muro móvil de una zona que nunca reconfigurarás: simplicidad sana. Quitar el muro móvil de la zona donde casi seguro pondrás la oficina: pintarse en una esquina. La misma acción —"lo hicimos directo, sin la frontera"— es sabia o suicida según la probabilidad del cambio que la frontera protegía.

El disfraz de YAGNI mal aplicado. El under-engineering casi siempre se justifica con el lenguaje del YAGNI, y por eso es tan difícil de combatir: usa las palabras de la disciplina. "No lo vamos a necesitar, hagámoslo directo", "no compliquemos con una interfaz, que orders lea las tablas de payments directo", "un solo proveedor de pagos, YAGNI el segundo". El problema no es el YAGNI; es aplicarlo al caso equivocado. YAGNI es una afirmación sobre la probabilidad: "no lo vas a necesitar" solo es cierto si el cambio es improbable. Cuando alguien invoca YAGNI sobre un cambio que el negocio ya está señalando —finanzas negociando el segundo proveedor, el monolito crujiendo bajo el crecimiento—, no está aplicando la disciplina; está usando su nombre para justificar no preparar lo que sí hace falta. La pregunta que desenmascara el disfraz es la misma de siempre, invertida: en la lección 5 preguntabas "¿este futuro es probable o solo imaginable?" para no sobre-construir; aquí preguntas "¿este futuro es improbable de verdad, o es probable y le estoy poniendo el nombre de YAGNI a mi pereza?".

La asimetría que hace al under-engineering especialmente peligroso. Hay una razón por la que, en la duda, conviene inclinarse un poco más hacia dejar la costura que hacia no dejarla, y es una asimetría de costos. Una costura que resultó innecesaria (dejaste el muro móvil y nunca reconfiguraste) cuesta lo que costó construirla —el seam_cost chico, unos miles—: un desperdicio acotado, molesto pero menor. Una costura que faltó cuando hacía falta (fijaste todo en concreto y llegó el cambio) cuesta la reescritura —el rewrite alto, decenas de miles— más el tiempo perdido, el riesgo de romper cosas al reescribir, y a veces la oportunidad de negocio que se pierde mientras reescribes. El costo de una costura de más es pequeño y acotado; el de una costura de menos es grande y con cola larga. Esta asimetría no significa "deja todas las costuras" (eso sería over-engineering); significa que, para los cambios cuya probabilidad está cerca del punto de equilibrio, el error de quedarse corto duele más que el de pasarse, así que la duda se resuelve hacia la costura. Es el reverso prudente de la lección 5: allá, ante lo claramente improbable, no construyas; aquí, ante lo probable o lo dudoso-pero-caro-de-reparar, deja la costura.

Por qué el under-engineering se acumula (y se conecta con la lección 2). Un sistema construido sin costuras no falla en un solo cambio; se va soldando. Cada vez que se elige la ruta directa —orders lee las tablas de payments, catalog hace joins con las de shipping— se borra una frontera, y las piezas quedan más pegadas. Con el tiempo, el sistema entero se vuelve una bola sin fronteras internas donde cualquier cambio es caro, porque nada está separado de nada. Es el monolito doloroso de la lección 2, naciendo de mil decisiones de under-engineering, cada una "simple" en su momento. Por eso pintarse en una esquina rara vez es un evento único y dramático; es la acumulación de muchas simplificaciones que borraron fronteras, hasta que un día un cambio trivial toca cinco módulos y nadie entiende cómo se llegó ahí. El under-engineering es a las fronteras lo que el drift de la lección 2 es a la estructura: un deterioro por acumulación que no se ve venir hasta que ya te rodeó de pintura fresca.

Errores comunes

Invocar YAGNI para no dejar una costura que sí hace falta. Qué pasa: ante un cambio probable —que el negocio ya está señalando—, el arquitecto se niega a dejar la costura diciendo "no lo vamos a necesitar, hagámoslo directo", y construye pegado, sin frontera. Cuando el cambio llega, hay que reescribir. Por qué pasa: YAGNI es una disciplina sana y su lenguaje da cobertura; es fácil (y cómodo) aplicarla al caso equivocado y llamar "simplicidad" a lo que es pereza o prisa. Cómo detectarlo: si se invoca "no lo vamos a necesitar" sobre un cambio que el negocio ya mencionó, o si la respuesta a "¿y si esto que finanzas está negociando llega?" es "ya reescribiremos", es YAGNI mal aplicado. Cómo corregirlo: preguntar honestamente "¿este cambio es improbable de verdad, o es probable y le estoy poniendo el nombre de YAGNI a no querer prepararlo?" —YAGNI solo aplica a lo improbable—. En el ejemplo, negarse a la costura de 8000 del monolito expone a 81000 esperados de reescritura.

Borrar fronteras "para simplificar" y soldar el sistema. Qué pasa: se elige repetidamente la ruta directa —un módulo lee las tablas de otro, se hacen joins entre dominios, se pega todo— porque en cada caso individual "es más simple así"; con el tiempo el sistema queda sin fronteras internas y cualquier cambio se vuelve caro. Por qué pasa: cada borrado de frontera se ve local y sano ("es una llamada menos, una capa menos"); el daño solo aparece en la acumulación. Cómo detectarlo: si un cambio que debería ser local toca varios módulos, o si "todo está pegado con todo" y nadie sabe cuándo pasó, se soldó el sistema por acumulación. Cómo corregirlo: distinguir simplicidad sana (quitar lo accidental: abstracciones especulativas) de under-engineering (quitar lo esencial: fronteras que protegen cambios probables); conservar las costuras que separan dominios que el negocio va a querer mover. Es el monolito doloroso de la lección 2 naciendo de mil simplificaciones.

Ignorar la asimetría entre costura de más y costura de menos. Qué pasa: ante una decisión dudosa (¿dejo la costura o no?), el arquitecto trata los dos errores como igual de graves y, en la duda, elige no dejar la costura "por simplicidad", sin notar que quedarse corto suele doler mucho más que pasarse. Por qué pasa: el costo de una costura de más es visible hoy (el seam_cost que se ve en el presupuesto); el de una costura de menos es futuro e invisible (la reescritura que vendrá). Cómo detectarlo: si las decisiones dudosas se resuelven sistemáticamente hacia "no lo dejemos, por si es over-engineering", sin pesar el costo del rework, se está ignorando la asimetría. Cómo corregirlo: recordar que una costura innecesaria cuesta unos miles acotados, mientras que una costura faltante cuesta decenas de miles con cola larga (riesgo, tiempo, oportunidad); para cambios dudosos-pero-caros-de-reparar, resolver la duda hacia la costura. (Esto no contradice el YAGNI: para lo claramente improbable, sigue sin construir; la asimetría solo mueve la duda cerca del punto de equilibrio.)

Ejercicios

Ejercicio 1 — ¿YAGNI sano o esquina? Para cada decisión en Mercado, di si invocar YAGNI ("hagámoslo directo, sin costura") es la disciplina sana de la lección 5 o el under-engineering de esta lección, y justifica con la probabilidad del cambio: (a) que orders lea y escriba directamente las tablas de payments, cuando el negocio ya planea sacar payments a un servicio propio el próximo semestre; (b) no construir una capa de plugins para terceros, cuando no hay estrategia de plataforma ni nadie la pidió; (c) hardcodear "un solo país, una sola moneda" en todo el checkout, cuando marketing ya anunció la expansión a tres países para el año entrante.

Ver solución

  • (a) Under-engineering (esquina). El negocio ya planea sacar payments a un servicio el próximo semestre: el cambio es probable y cercano. Que orders lea directamente las tablas de payments borra la costura entre los dos, y cuando payments se extraiga, habrá que desenredar todos esos accesos directos —reescritura—. Invocar YAGNI aquí es aplicarlo al caso equivocado: sí lo vas a necesitar. La costura sana es que orders hable con payments por una interfaz.

  • (b) YAGNI sano (lección 5). Sin estrategia de plataforma ni demanda, una capa de plugins para terceros es un futuro imaginable, no probable. Aquí "no lo construyamos" es la disciplina correcta: no prepares para lo improbable. Es exactamente el over-engineering que la lección 5 evita. No dejar esa flexibilidad no te pinta en ninguna esquina, porque el cambio casi seguro no viene.

  • (c) Under-engineering (esquina). Marketing ya anunció la expansión a tres países: multi-país y multi-moneda son cambios probables y con fecha. Hardcodear "un país, una moneda" en todo el checkout es fijar todo en concreto justo donde la vida va a cambiar; cuando llegue la expansión, habrá que tocar el checkout entero. Invocar YAGNI sobre algo ya anunciado es ponerle el nombre de la disciplina a no querer preparar. La costura sana es aislar la moneda y el país en vez de esparcirlos hardcodeados.

El patrón: (a) y (c) son cambios probables/anunciados → dejar costura es preparación sana, no dejarla es pintarse en una esquina; (b) es imaginable → no construir es YAGNI sano. La misma frase ("hagámoslo directo, YAGNI") es sabia o suicida según la probabilidad del cambio.

Ejercicio 2 — El espejo de la lección 5. El texto dice que el under-engineering y el over-engineering son "la misma estructura de costos, invertida por la probabilidad". Explica qué significa eso comparando el mecanismo de por qué pierde cada uno, usando los términos p × rework (lección 5) y p × rewrite (esta lección).

Ver solución

Las dos lecciones usan la misma estructura: comparan pagar por adelantado (la flexibilidad / la costura) contra pagar el costo esperado de adaptarse después (p × costo_de_reparar). Lo que cambia entre ellas —y lo que invierte el resultado— es la probabilidad p.

En la lección 5 (over-engineering), los cambios eran improbables (p chica, sumando 0.25 esperado). Con p chica, el término p × rework es chico: el costo esperado de no preparar y adaptarse después es bajo, porque casi nunca hay que adaptarse. Por eso pre-construir la flexibilidad (pagar por adelantado, garantizado) pierde: pagas mucho seguro para evitar poco improbable. Gana no preparar (YAGNI).

En esta lección (under-engineering), los cambios son probables (p alta: 0.90, 0.85, 0.80). Con p alta, el término p × rewrite es grande —casi el rewrite completo—: el costo esperado de no preparar y reescribir después es enorme, porque casi siempre hay que reescribir. Por eso no dejar la costura (ahorrar por adelantado) pierde: ahorras poco seguro para exponerte a mucho probable. Gana preparar (dejar la costura).

O sea: es literalmente la misma fórmula (pagar_hoy vs p × reparar_después), y el ganador se voltea según si p está por debajo (lección 5: no prepares) o por encima (esta: prepara) del punto de equilibrio de la lección 3. Los dos abismos son el mismo cálculo mal resuelto en direcciones opuestas: el over-engineering prepara cuando p es baja; el under-engineering no prepara cuando p es alta. Y el punto de equilibrio —el umbral de probabilidad— es la línea que separa los dos, exactamente lo que la lección 7 usa para encontrar el medio.

Ejercicio 3 — La asimetría en la duda. Un arquitecto de Mercado enfrenta una decisión dudosa: un cambio cuya probabilidad estima en torno al punto de equilibrio —podría ir para cualquier lado—, y cuya reescritura, si faltara la costura, sería cara. Dice: "en la duda, mejor no la dejo, para no caer en over-engineering". Usando la idea de la asimetría de costos, explica por qué su regla de desempate está mal calibrada para este caso, y cómo debería resolver la duda.

Ver solución

Su regla de desempate ("en la duda, no la dejo") ignora la asimetría entre el costo de una costura de más y el de una costura de menos, y por eso está mal calibrada justo para este caso —un cambio dudoso cuya reescritura sería cara—.

Los dos errores posibles no cuestan lo mismo. Si deja la costura y el cambio no llega (costura de más), desperdicia el seam_cost —unos pocos miles, un costo pequeño y acotado: se sabe exactamente cuánto se perdió y ahí termina—. Si no deja la costura y el cambio llega (costura de menos), paga la reescritura —decenas de miles— más una cola larga de costos: el riesgo de romper cosas al reescribir bajo presión, el tiempo perdido, y a veces la oportunidad de negocio que se pierde mientras se reescribe en vez de avanzar. El costo de pasarse es chico y cerrado; el de quedarse corto es grande y abierto.

Cuando dos errores no cuestan lo mismo, la regla de desempate no debería tratarlos como iguales. Para este caso —probabilidad cerca del equilibrio y reescritura cara—, la duda debería resolverse hacia dejar la costura, no en contra, porque el error de quedarse corto duele mucho más que el de pasarse. Su regla "en la duda no la dejo" solo estaría bien calibrada si los dos errores costaran parecido, o si la reescritura fuera barata —pero él mismo dijo que sería cara—.

El matiz que evita el malentendido: esto no contradice el YAGNI ni te empuja al over-engineering. La asimetría solo mueve la decisión en la zona dudosa (cerca del punto de equilibrio). Para cambios claramente improbables, la regla sigue siendo no construir (lección 5) —ahí no hay duda que resolver—. La asimetría dice: cuando de verdad no sabes y equivocarte hacia el under-engineering sería caro, inclínate hacia la costura. La regla del arquitecto bien calibrado no es "en la duda no prepares" ni "en la duda prepara"; es "en la duda, prepara si quedarte corto dolería mucho más que pasarte" —que aquí es el caso—.

Resumen y siguiente paso

En esta lección abriste el segundo abismo del módulo: el under-engineering, pintarse en una esquina. Viste, con quien pinta el piso hasta el rincón sin dejarse salida y con la casa de concreto, que negarse a dejar ninguna costura no es simplicidad ni ahorro cuando el cambio es previsible —es diferir un costo y multiplicarlo—. Y lo mediste: para cambios probables (0.90, 0.85, 0.80), no dejar costura cuesta 135000 esperados en reescritura contra 31450 de dejar la costura barata —4.3 veces más—. Entendiste que es el espejo exacto de la lección 5 (la misma fórmula, invertida por la probabilidad), que se disfraza de YAGNI mal aplicado ("no lo vamos a necesitar" sobre algo que sí vas a necesitar), que se acumula soldando fronteras hasta recrear el monolito doloroso, y que la asimetría de costos —una costura de menos duele más que una de más— inclina las decisiones dudosas-y-caras hacia la costura.

Antes de avanzar deberías poder: distinguir YAGNI sano (no preparar para lo improbable) de under-engineering (no preparar para lo probable, con el nombre de YAGNI); explicar por qué los dos abismos son el mismo cálculo invertido por p; y aplicar la asimetría de costos para resolver una duda cerca del punto de equilibrio.

Ya tienes los dos abismos: el over-engineering (preparar de más, para lo improbable) y el under-engineering (preparar de menos, para lo probable). La lección 7 los junta y encuentra el camino entre ellos: diseñar las costuras en el punto sensato. Vas a ver que diseñar para el cambio no es diseñar para todo cambio imaginable, sino construir la costura solo donde el cambio es bastante probable para que se pague sola, y diferir el resto —y a ejecutar el right-sizing que le gana a los dos extremos a la vez—. La síntesis del módulo, con números.

Recursos

  • Martin Fowler, "Design Stamina Hypothesis" (2007) — martinfowler.com/bliki/DesignStaminaHypothesis.html. El texto que enmarca los dos abismos: hay un punto de diseño por debajo del cual (under-engineering) el sistema se vuelve rígido y caro de cambiar, y por encima del cual (over-engineering) se sobre-invierte. Esta lección es el lado de "por debajo". En inglés.
  • Michael Feathers, Working Effectively with Legacy Code (Prentice Hall, 2004) — el manual de qué hacer después de haberse pintado en una esquina: cómo introducir costuras (seams) en un sistema soldado sin fronteras para poder cambiarlo y probarlo. La cura del under-engineering acumulado. En inglés.
  • Sam Newman, Building Microservices, 2ª ed. (O'Reilly, 2021), cap. sobre monolitos y extracción — sobre por qué un monolito sin fronteras internas es carísimo de partir después, y cómo dejar las costuras (bounded contexts, módulos) que hacen la futura extracción barata. El caso monolith_to_services del ejemplo. En inglés.
  • Andrew Hunt y David Thomas, The Pragmatic Programmer, 20th Anniversary Edition (Addison-Wesley, 2019), temas "Decoupling" y "Reversibility" — sobre por qué acoplar todo (borrar fronteras) cierra puertas caro, y por qué el buen diseño mantiene las piezas separables. En inglés.
← AnteriorLa línea del YAGNISiguiente →Diseñar las costuras