Módulo 6: Diseñar para el cambio

La línea del YAGNI

Siguiente →

Descripción

Con las tres piezas de la postura instaladas —flujo, optionality, sacrificial— empieza la segunda mitad del módulo: los dos abismos entre los que camina el arquitecto que diseña para el cambio. Esta lección abre el primero, el más seductor porque se disfraza de prudencia: el over-engineering, y la línea que lo marca, el YAGNI —You Aren't Gonna Need It, "no lo vas a necesitar"—. Es el error de construir flexibilidad, abstracciones y capas "por si acaso" para futuros que el arquitecto imagina pero que casi nunca llegan. El sistema de plugins genérico que soportará extensiones que nadie pidió, el motor de reglas configurable para reglas que solo cambian una vez al año, los microservicios "porque algún día vamos a escalar": cada uno suena responsable, y cada uno paga por adelantado el costo de un problema que quizá nunca tenga.

El YAGNI es contraintuitivo porque contradice un instinto que se siente virtuoso: "prepárate para el futuro". La lección 3 ya sembró la respuesta —una opción cuesta una prima y solo vale la pena por encima de su punto de equilibrio—; esta lección la lleva al extremo del portafolio. Cuando el arquitecto ansioso mira todos los futuros que podría imaginar y decide pre-construir la flexibilidad para cada uno, comete el error de comprar seguros contra dragones: paga muchas primas por eventos que no van a ocurrir. Y como la enorme mayoría de los futuros imaginados son de baja probabilidad, el costo de cargar toda esa flexibilidad no usada supera con creces el de simplemente pagar el rework de los pocos cambios que de verdad arriban. Esta lección lo mide, y el resultado es un orden de magnitud.

Conexión con el módulo. Es el primer abismo (esta: over-engineering; la 6: under-engineering; la 7: el punto sensato entre los dos). Se apoya directo en la lección 3: el over-engineering es comprar opciones por debajo de su punto de equilibrio —pagar primas por cambios demasiado improbables—. Y prepara la tensión que la lección 7 resuelve: si esta lección dijera solo "no construyas nada por adelantado", caerías en el abismo opuesto (under-engineering); por eso la 6 corrige y la 7 encuentra el medio. Frontera con la guía hermana: aquí no medimos deuda técnica ni el costo de acarreo formalmente; trabajamos la postura del arquitecto que resiste la tentación de construir para todo futuro imaginable, y sabe distinguir el cambio probable del imaginado.

Una analogía: el urbanista que pavimenta doce carriles para el pueblo

Vuelve al urbanista de la lección 1, pero ahora enfoca al segundo —el que comete el error del exceso—, porque es el protagonista de esta lección.

Un pueblo de tres mil habitantes necesita, hoy, un par de calles y una carretera de dos carriles que lo conecte con la ciudad. Eso es lo que el tráfico pide. Pero el urbanista está aterrado por el futuro: "¿y si el pueblo crece? ¿y si se vuelve una metrópoli? Mejor construyamos ya la infraestructura para cinco millones de habitantes". Así que pavimenta una avenida de doce carriles con distribuidores viales, construye un aeropuerto internacional, tiende una red de metro subterráneo, e instala capacidad eléctrica para una ciudad industrial. Todo eso para tres mil personas.

¿Qué pasa? Primero, el costo es astronómico: la infraestructura para cinco millones cuesta órdenes de magnitud más que la que el pueblo necesita, y el pueblo se endeuda por generaciones. Segundo, casi nada se usa: doce carriles por los que pasan tres autos, un aeropuerto con un vuelo semanal, un metro vacío. Tercero —y esto es lo que casi nadie anticipa—, mantener lo que no se usa cuesta: el concreto de la avenida se agrieta con el sol sin que un solo auto lo justifique, el aeropuerto necesita personal y mantenimiento, el metro consume electricidad. La infraestructura sobredimensionada no es gratis mientras espera un futuro que no llega; drena el presupuesto del pueblo cada año. Y cuarto, para cuando (o si) el pueblo crezca —dentro de treinta años—, la avenida ya estará obsoleta, el aeropuerto será chico, y habrá que rehacerlo todo de todas formas. El urbanista pagó una fortuna por adelantado, mantuvo un elefante blanco por décadas, y ni siquiera acertó el futuro para el que construyó.

Contrasta con el urbanista bueno de la lección 1: él no pavimenta doce carriles; reserva el derecho de vía —una franja barata por donde, si el tráfico llega, se abrirá la avenida entonces—. La diferencia es enorme: reservar terreno cuesta casi nada y no requiere mantenimiento; pavimentar doce carriles cuesta una fortuna y drena el presupuesto esperando un tráfico que quizá no venga. El over-engineering es pavimentar los doce carriles hoy. El YAGNI es la disciplina de no hacerlo —de construir lo que el tráfico pide y, a lo sumo, reservar el derecho de vía para lo probable, no pavimentar por adelantado para todo futuro imaginable—. Esta lección mide el costo de pavimentar los doce carriles.

Ejemplo trabajado: pre-construir todos los futuros contra pagar el rework de los que llegan

Vamos a medir el costo del over-engineering. Un arquitecto ansioso de Mercado mira un portafolio de futuros imaginados —cambios que teme y quiere pre-construir hoy, "por si acaso"—. Cada futuro tiene tres números: la probabilidad real de que llegue (p_happens), lo que cuesta pre-construir su flexibilidad hoy (flex_now), y lo que costaría adaptarse después si llega y no lo pre-construiste (rework).

Comparamos dos posturas:

  • over_engineered — el arquitecto ansioso: pre-construye la flexibilidad de todos los futuros imaginados. Paga todas las flex_now, sin importar si el futuro llega o no. Es pavimentar los doce carriles.
  • yagni — la disciplina: no pre-construye nada. Solo paga el rework de los futuros que de verdad llegan —y como cada uno tiene su probabilidad, el costo esperado es p_happens × rework sumado sobre todos—. Es construir lo que el tráfico pide, cuando lo pide.

El punto clave que hace la diferencia: los futuros imaginados "por si acaso" son, casi por definición, de baja probabilidad. Fíjate en las p_happens del portafolio —todas pequeñas—, porque es justo lo que caracteriza al miedo del arquitecto ansioso: teme muchos futuros, pero cada uno es improbable:

# YAGNI ("You Aren't Gonna Need It"): construir flexibilidad "por si acaso" para
# futuros imaginados que casi nunca llegan. Un portafolio de cambios que un
# arquitecto ANSIOSO teme y quiere pre-construir hoy. Cada uno:
#   p_happens : probabilidad real de que ese futuro llegue
#   flex_now  : lo que cuesta construir la flexibilidad HOY, por adelantado
#   rework    : lo que costaria adaptarse DESPUES si llega y no lo pre-construiste
FUTURES = [
    # (nombre, p_happens, flex_now, rework)
    ("multi_currency_before_expansion",  0.05, 15000, 20000),
    ("plugin_system_for_unknown_addons", 0.03, 25000, 18000),
    ("swap_database_vendor",             0.04, 20000, 30000),
    ("generic_workflow_engine",          0.02, 30000, 22000),
    ("support_5_payment_providers",      0.08, 12000, 16000),
    ("white_label_multitenant",          0.03, 28000, 26000),
]

# over_engineered: pre-construye la flexibilidad de TODOS los futuros imaginados.
over_engineered = sum(flex for _, _, flex, _ in FUTURES)
# yagni: no pre-construye nada; solo paga el rework (esperado) de los que SI llegan.
yagni = sum(p * rework for _, p, _, rework in FUTURES)
expected_arrivals = sum(p for _, p, _, _ in FUTURES)

print(f"{'futuro imaginado':<36}{'p':>6}{'flex_now':>10}{'p*rework':>10}")
print("-" * 62)
for name, p, flex, rework in FUTURES:
    print(f"{name:<36}{p:>6.2f}{flex:>10,}{p * rework:>10,.0f}")
print("-" * 62)
print(f"{'over_engineered (pre-construye TODO)':<52}{over_engineered:>10,}")
print(f"{'yagni (paga rework solo de los que llegan)':<52}{yagni:>10,.0f}")
print()
print(f"De {len(FUTURES)} futuros pre-construidos, se espera que lleguen {expected_arrivals:.2f}.")
print(f"El over-engineering paga {over_engineered / yagni:.0f}x mas para cargar flexibilidad")
print("que, en su enorme mayoria, nunca se usara. YAGNI: no lo construyas hasta necesitarlo.")

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

futuro imaginado                         p  flex_now  p*rework
--------------------------------------------------------------
multi_currency_before_expansion       0.05    15,000     1,000
plugin_system_for_unknown_addons      0.03    25,000       540
swap_database_vendor                  0.04    20,000     1,200
generic_workflow_engine               0.02    30,000       440
support_5_payment_providers           0.08    12,000     1,280
white_label_multitenant               0.03    28,000       780
--------------------------------------------------------------
over_engineered (pre-construye TODO)                   130,000
yagni (paga rework solo de los que llegan)               5,240

De 6 futuros pre-construidos, se espera que lleguen 0.25.
El over-engineering paga 25x mas para cargar flexibilidad
que, en su enorme mayoria, nunca se usara. YAGNI: no lo construyas hasta necesitarlo.

Lee la tabla columna por columna, porque el contraste entre flex_now y p*rework es todo el argumento.

La columna flex_now es lo que el arquitecto ansioso paga por adelantado, garantizado. Pre-construir el sistema de multi-moneda: 15000. El sistema de plugins genérico: 25000. Cambiar de proveedor de base de datos abstraído: 20000. El motor de workflows configurable: 30000. Y así. Suma 130000 dólares, y los paga ahora, se usen o no. Es el costo de pavimentar los doce carriles: real, presente, garantizado.

La columna p*rework es lo que cuesta, en valor esperado, no pre-construir y adaptarse si el futuro llega. Multi-moneda: 5% de probabilidad por 20000 de rework = 1000 esperados. El sistema de plugins: 3% por 18000 = 540. Y así. Suma 5240 dólares. Fíjate en por qué es tan chico: cada término se multiplica por una probabilidad pequeña, porque estos futuros imaginados casi nunca llegan. No es que adaptarse sea gratis; es que la mayoría de las veces no hay que adaptarse, porque el futuro temido no arriba.

Y ahí está el número que define la lección: 130000 contra 5240, veinticinco veces más caro pre-construir todo. El over-engineering paga 25x por cargar una flexibilidad que, en su enorme mayoría, nunca se usará. La línea del código lo dice sin rodeos: de los 6 futuros pre-construidos, se espera que lleguen 0.25. Cero coma veinticinco. El arquitecto ansioso construyó seis flexibilidades para un futuro que, en promedio, usará una cuarta parte de una. Pagó por seis seguros contra dragones y, en expectativa, ningún dragón vino.

Fíjate en el mecanismo, porque es el corazón del YAGNI: el over-engineering paga el costo de la flexibilidad con certeza (garantizado, hoy) a cambio de evitar un rework que es incierto (probable solo para unos pocos futuros). Cambia un costo seguro por evitar un costo improbable —el peor negocio posible bajo incertidumbre—. El YAGNI hace lo contrario: no paga nada por adelantado y asume el rework solo cuando —y si— el futuro se materializa. Como la mayoría de los futuros imaginados no se materializan, el YAGNI casi siempre gana en el agregado. No porque el futuro nunca traiga cambios (algunos trae: el valor esperado del rework no es cero), sino porque pre-construir todos los cambios imaginables es pagar por una montaña de flexibilidad de la que se usará una brizna.

Como barras, la desproporción se ve así:

Costo total (USD): over-engineering vs YAGNI
 over_engineered |################################  130,000
 yagni            |#                                   5,240
                  ────────────────────────────────
 25x mas caro pre-construir todos los futuros imaginados
 que pagar el rework de los ~0.25 que de verdad llegan.

Profundización: por qué el over-engineering se disfraza de prudencia

El over-engineering es peligroso justamente porque no se siente como un error —se siente como responsabilidad—. Vale la pena entender los disfraces que usa, porque reconocerlos es la mitad de resistirlos.

El disfraz de "prepararse para el futuro". "Un buen arquitecto piensa a largo plazo" es cierto, pero se distorsiona en "un buen arquitecto construye el largo plazo hoy". Son cosas muy distintas. Pensar a largo plazo es reservar el derecho de vía —dejar la costura barata para el cambio probable, como enseñó la lección 3—; construir el largo plazo hoy es pavimentar los doce carriles para todo futuro imaginable. El primero es prudencia; el segundo es ansiedad disfrazada de prudencia. La pregunta que desenmascara el disfraz: "¿este futuro es probable o solo imaginable?". Casi cualquier cosa es imaginable —Mercado podría volverse una red social, podría necesitar 40 idiomas, podría querer un marketplace de plugins—; lo imaginable es infinito y construirlo todo es imposible. Solo lo probable justifica construir por adelantado, y aun así, muchas veces basta con reservar el derecho de vía, no pavimentar.

El disfraz de la generalización elegante. A los ingenieros nos seduce lo general: en vez de resolver este problema, resolver la clase entera de problemas de la que este es un caso. "No hagamos un cálculo de descuento; hagamos un motor de reglas configurable que pueda expresar cualquier descuento futuro". Suena más inteligente, más profesional. Pero un motor de reglas para una regla que cambia una vez al año es doce carriles para tres autos: toda la complejidad de lo general, ninguno de sus beneficios. La regla de oro aquí es la de las "tres apariciones": no generalices en la primera necesidad, ni en la segunda; espera a la tercera, cuando el patrón real ya se reveló y la generalización se apoya en evidencia, no en imaginación. Generalizar antes de ver el patrón es adivinar la forma de la abstracción —y casi siempre se adivina mal, con lo que la abstracción "flexible" resulta flexible en las dimensiones equivocadas—.

El costo que nadie cuenta: el acarreo. El ejemplo midió el costo de construir la flexibilidad no usada (130000), pero hay un costo que el modelo no incluyó y que en la práctica es peor: el costo de acarreo (carrying cost). Cada abstracción, cada capa de configuración, cada indirección "por si acaso" no solo cuesta construirse; cuesta cargarse para siempre. Hace el código más difícil de leer (hay que entender la generalización para hacer un cambio simple), más difícil de cambiar (los cambios tienen que respetar una flexibilidad que nadie usa), más difícil de depurar (más piezas móviles), más lento de onboarding (cada persona nueva tiene que aprender la maquinaria genérica). Es el mantenimiento del aeropuerto vacío: la infraestructura sobredimensionada drena presupuesto cada año, no solo el día que se construye. Por eso el over-engineering es doblemente caro: pagas por construir lo que no usas y pagas por cargarlo durante toda la vida del sistema. El YAGNI ahorra las dos cosas.

El matiz que evita el malentendido —y que la lección 6 desarrolla—. YAGNI no es "nunca construyas nada por adelantado" ni "no pienses en el futuro". Eso sería el abismo opuesto: el under-engineering que se pinta en una esquina. YAGNI es más preciso: no construyas la flexibilidad hasta que el cambio sea bastante probable para justificarla —hasta que cruce su punto de equilibrio (lección 3)—. Para los cambios probables, sí dejas la costura (reservas el derecho de vía); para los imaginables pero improbables, no. La línea del YAGNI no está en "cero preparación"; está en "preparación proporcional a la probabilidad". El error de esta lección es preparar de más (para todo lo imaginable); el error de la próxima es preparar de menos (para nada). El arte, que la lección 7 mide, es preparar lo justo —para lo probable—.

Errores comunes

Construir la abstracción antes de ver el patrón. Qué pasa: ante la primera (o segunda) aparición de una necesidad, el arquitecto construye una abstracción general "para cubrir los casos futuros" —el motor de reglas, el sistema de plugins, la capa configurable— antes de que el patrón real se haya revelado. La abstracción resulta flexible en las dimensiones equivocadas, porque se adivinó su forma. Por qué pasa: lo general seduce (se ve más inteligente que resolver el caso concreto) y "prepararse" se siente responsable. Cómo detectarlo: si hay abstracciones con un solo caso de uso real, o motores configurables cuya configuración nunca cambia, se generalizó antes de tiempo. Cómo corregirlo: la regla de las tres apariciones —resuelve el caso concreto las primeras dos veces, y generaliza en la tercera, cuando el patrón ya se reveló y la abstracción se apoya en evidencia, no en imaginación—. Adivinar la forma de la abstracción casi siempre falla.

Confundir "pensar a largo plazo" con "construir el largo plazo hoy". Qué pasa: el arquitecto justifica pre-construir infraestructura para futuros imaginados diciendo "hay que pensar a largo plazo", y pavimenta los doce carriles por adelantado. Por qué pasa: "pensar a largo plazo" es una virtud real, y es fácil deslizarse de ahí a "construir el largo plazo ahora" sin notar que son cosas distintas. Cómo detectarlo: si la justificación de construir algo es "algún día" / "por si acaso" / "podríamos necesitar", sin un cambio probable y cercano que lo respalde, es construir el largo plazo hoy. Cómo corregirlo: preguntar "¿este futuro es probable o solo imaginable?" —lo imaginable es infinito y no se construye; solo lo probable justifica preparación, y muchas veces basta reservar el derecho de vía (la costura barata) en vez de pavimentar—. Pensar a largo plazo es dejar abierta la posibilidad barata, no construir el futuro caro por adelantado.

Ignorar el costo de acarreo de la flexibilidad no usada. Qué pasa: se justifica una abstracción "por si acaso" mirando solo su costo de construcción ("no cuesta tanto agregarla ahora"), sin contar lo que costará cargarla durante toda la vida del sistema —más difícil de leer, cambiar, depurar y aprender—. Por qué pasa: el costo de construcción es un evento único y visible; el costo de acarreo es un goteo invisible que se paga en cada cambio futuro. Cómo detectarlo: si cada persona nueva tarda en entender maquinaria genérica que nadie usa, o si cambios simples exigen respetar flexibilidad que no aporta, estás pagando acarreo. Cómo corregirlo: contar el costo total —construcción más acarreo de por vida— al evaluar una flexibilidad, no solo el de construirla; la mayoría de las abstracciones "baratas de agregar" son caras de cargar. El aeropuerto vacío no cuesta solo construirse; cuesta mantenerse año tras año.

Ejercicios

Ejercicio 1 — ¿Probable o imaginable? Para cada propuesta en Mercado, di si es preparación legítima para un cambio probable (adelante) u over-engineering para un futuro imaginable (YAGNI, no lo construyas), y justifica: (a) construir un sistema de plugins genérico para que terceros extiendan Mercado, cuando ningún tercero lo ha pedido y no hay estrategia de plataforma; (b) dejar una interfaz sobre el proveedor de pagos, cuando finanzas ya negocia un segundo proveedor; (c) construir soporte para 40 idiomas y 30 monedas, cuando Mercado opera en un solo país sin planes de expansión; (d) diseñar un motor de reglas configurable para los descuentos, cuando las reglas de descuento cambian una vez al año y siempre de la misma forma.

Ver solución

  • (a) Over-engineering (YAGNI, no lo construyas). Un sistema de plugins para terceros que nadie pidió y sin estrategia de plataforma es un futuro imaginable, no probable. Es el aeropuerto para el pueblo: construyes maquinaria genérica enorme para extensiones que no existen. Además tiene un costo de acarreo alto (todo el sistema tiene que respetar la mecánica de plugins). No lo construyas hasta que haya una estrategia de plataforma real y demanda concreta.

  • (b) Preparación legítima (adelante, pero como costura, no como pavimento). Finanzas ya negocia el segundo proveedor: el cambio es probable y cercano. Dejar una interfaz sobre el proveedor de pagos es reservar el derecho de vía —barato, proporcional a una probabilidad alta—. Nota que esto es dejar una costura, no construir los dos proveedores por adelantado; sigue siendo preparación proporcional, no over-engineering.

  • (c) Over-engineering (YAGNI, no lo construyas). Un país, sin planes de expansión: 40 idiomas y 30 monedas son doce carriles para tres autos. Futuro imaginable, no probable. La complejidad de un sistema completo de internacionalización se cargaría durante toda la vida del sistema sin usarse. No lo construyas; si algún día la expansión se vuelve probable, entonces sí prepara —y aun así, quizá baste con una costura—.

  • (d) Over-engineering (YAGNI, no lo construyas). Un motor de reglas configurable para algo que cambia una vez al año y siempre igual es la generalización elegante que no se justifica: toda la complejidad de lo general, ninguno de sus beneficios. Resuelve el descuento concreto; si algún día las reglas empiezan a cambiar seguido y de formas variadas (el patrón se revela, la tercera aparición), entonces generaliza. Adivinar el motor ahora casi seguro lo hará flexible en las dimensiones equivocadas.

El patrón: (b) es probable → prepara (con costura); (a), (c), (d) son imaginables → no construyas. La pregunta que decide es siempre "¿probable o solo imaginable?".

Ejercicio 2 — De dónde sale el 25x. El ejemplo muestra que el over-engineering cuesta 25 veces más que el YAGNI. Un arquitecto objeta: "pero eso es porque elegiste futuros de baja probabilidad; con futuros probables, pre-construir ganaría". ¿Tiene razón? Explica qué asume el ejemplo, por qué esa asunción es correcta para caracterizar el over-engineering, y qué pasaría con futuros de alta probabilidad.

Ver solución

El arquitecto tiene razón en la mecánica —el 25x depende de que las probabilidades sean bajas— pero se equivoca en la conclusión, porque la baja probabilidad es la definición del over-engineering, no un truco del ejemplo. El over-engineering, por definición, es construir para futuros imaginados pero improbables: el "por si acaso". Un arquitecto ansioso teme muchos futuros (por eso el portafolio tiene seis), pero cada uno individualmente es improbable (por eso las p son pequeñas, sumando 0.25 esperado). Elegir probabilidades bajas no sesga el ejemplo; retrata fielmente la situación que la lección critica. Si los futuros fueran probables, ya no sería over-engineering —sería preparación legítima—.

Qué pasaría con futuros de alta probabilidad: si un futuro tiene, digamos, 90% de probabilidad, su término p × rework ya no es chico, y pre-construir su flexibilidad (dejar la costura) empieza a ganar —exactamente el cálculo del punto de equilibrio de la lección 3—. Y ese es el punto que conecta con las lecciones siguientes: para los futuros probables, sí conviene preparar (dejar costura); negarse a hacerlo es el abismo opuesto, el under-engineering de la lección 6. El error del over-engineering no es "preparar"; es preparar para lo improbable. El arquitecto de la objeción, sin querer, describió la solución: distingue los futuros por probabilidad, prepara los probables, deja los improbables. Eso es justo el right-sizing de la lección 7. El 25x no dice "nunca prepares"; dice "no prepares para lo improbable" —que es cosa distinta—.

Ejercicio 3 — El costo que el modelo no midió. El ejemplo midió el costo de construir la flexibilidad no usada (130000), pero el texto dice que hay un costo peor que el modelo no incluyó. Nómbralo, explica por qué en la práctica suele ser mayor que el costo de construcción, y da un ejemplo concreto en Mercado del motor de reglas configurable del ejercicio 1.

Ver solución

El costo que el modelo no midió es el costo de acarreo (carrying cost): lo que cuesta cargar la flexibilidad no usada durante toda la vida del sistema, más allá de construirla. Cada abstracción, capa de configuración o indirección "por si acaso" hace el sistema más difícil de leer, de cambiar, de depurar y de aprender —para siempre, no solo el día que se construye—.

Por qué suele ser mayor que el costo de construcción: el costo de construcción es un evento único (se paga una vez, 130000 en el ejemplo); el costo de acarreo es un goteo que se paga en cada interacción futura con el código —cada cambio tiene que entender y respetar la maquinaria genérica, cada persona nueva tiene que aprenderla, cada bug es más difícil de rastrear por las piezas móviles de más—. Sumado sobre años y sobre todo el equipo, ese goteo constante suele superar con creces el desembolso único de construirlo. Es el aeropuerto vacío: construirlo fue caro una vez, pero mantenerlo drena el presupuesto cada año que espera pasajeros que no llegan.

Ejemplo concreto en Mercado con el motor de reglas configurable (del ejercicio 1d): construir el motor cuesta, digamos, 30000 una vez. Pero luego, cada vez que alguien toca los descuentos —aunque sea para un cambio trivial— tiene que entender el lenguaje de configuración del motor, no un simple cálculo; cada dev nuevo que llega a Mercado tarda días en entender cómo funciona el motor genérico antes de poder cambiar un descuento; cada bug en un descuento es más difícil de rastrear porque la lógica vive en configuración interpretada, no en código directo; y todo eso para reglas que cambian una vez al año. El acarreo —esa fricción constante multiplicada por años y por todo el equipo— termina costando mucho más que los 30000 de construir el motor, y todo por una flexibilidad que casi no se usa. Un simple if habría sido más barato de construir y de cargar.

Resumen y siguiente paso

En esta lección abriste el primer abismo del módulo: el over-engineering, y la línea del YAGNI. Viste, con el urbanista que pavimenta doce carriles para un pueblo, que construir flexibilidad para todo futuro imaginable no es prudencia sino ansiedad disfrazada —cara de construir, y peor aún de cargar—. Y lo mediste: pre-construir la flexibilidad de seis futuros imaginados cuesta 130000 contra 5240 de pagar el rework solo de los que de verdad llegan —25 veces más—, porque de los seis futuros se espera que arribe apenas 0.25. Entendiste el mecanismo (cambiar un costo seguro por evitar uno improbable, el peor negocio bajo incertidumbre), los disfraces del over-engineering (prepararse para el futuro, la generalización elegante), el costo de acarreo que nadie cuenta, y el matiz crucial: YAGNI no es "nunca prepares nada", es "prepara proporcional a la probabilidad".

Antes de avanzar deberías poder: distinguir un futuro probable (prepara) de uno imaginable (no construyas); aplicar la regla de las tres apariciones antes de generalizar; y explicar por qué el costo de acarreo suele superar al de construcción.

Pero cuidado: si te quedas solo con "no construyas nada por adelantado", caes en el abismo opuesto. La lección 6 lo abre: el under-engineering, pintarse en una esquina. Vas a ver el error de negarse a dejar una sola costura y quedar sin salida cuando el cambio probable llega —la casa con todo fijado en concreto—, y a ejecutar cuánto cuesta reescribir sin costura contra haber dejado la costura barata. Con números, para que quede claro que YAGNI tiene un límite: "no prepares para lo improbable" no es lo mismo que "no prepares para nada".

Recursos

  • Martin Fowler, "Yagni" (2015) — martinfowler.com/bliki/Yagni.html. El texto canónico de la lección: por qué construir una "capacidad presuntiva" para un futuro imaginado casi siempre sale caro, y por qué el costo incluye el de acarreo, no solo el de construcción. Corto y esencial. En inglés.
  • Martin Fowler, "Design Stamina Hypothesis" (2007) — martinfowler.com/bliki/DesignStaminaHypothesis.html. El complemento que evita el malentendido: hay un nivel de diseño que sí vale la pena, y el truco es no pasarse (over-engineering) ni quedarse corto (under-engineering, lección 6). En inglés.
  • Andrew Hunt y David Thomas, The Pragmatic Programmer, 20th Anniversary Edition (Addison-Wesley, 2019), temas "Good-Enough Software" y "The Evils of Duplication" — sobre no sobre-construir y sobre cuándo la generalización (DRY) ayuda y cuándo estorba. En inglés.
  • Sandi Metz, "The Wrong Abstraction" (2016) — sandimetz.com/blog/2016/1/20/the-wrong-abstraction. El mejor ensayo sobre por qué generalizar antes de ver el patrón (adivinar la forma de la abstracción) sale más caro que la duplicación que intentaba evitar. La base de la regla de las tres apariciones. En inglés.
← AnteriorLa arquitectura sacrificialSiguiente →Pintarse en una esquina