YAGNI

No implementes funcionalidad hasta que la necesites de verdad — no cuando “creés que en algún momento la vas a necesitar”.

Origen

YAGNI es una de las prácticas centrales de Extreme Programming (XP), formulada a finales de los años 90 por Kent Beck, Ron Jeffries y Martin Fowler en el equipo del proyecto Chrysler C3 — un sistema de nóminas en Smalltalk que se convirtió en la cuna de XP. La frase exacta — “You aren’t gonna need it” — se le atribuye habitualmente a Ron Jeffries; las XP rules en c2.com (la primera wiki) la registraron alrededor de 1999. El argumento de los tres tiene base estadística observada: en C3 documentaron cuántas veces los developers habían añadido “ganchos para futuras features” — y cuántas de esas features fueron realmente pedidas después. La proporción era abismal: la mayoría de los ganchos no llegaban a usarse, y los que sí llegaban a usarse eran tan distintos a lo imaginado que el gancho ya no servía y había que rehacerlo.

Ejemplo: el sistema de plugins por si acaso

El antipatrón estrella: el sistema de plugins genérico. “Hagámoslo extensible por si en el futuro queremos integrar X.” Construís un registry, un loader, un hook system, una API de configuración, documentación de extensión. Tres años después: el plugin que justificaba el sistema nunca se escribió, pero el equipo arrastra el doble de complejidad en el core, los tests son más caros, los nuevos developers tardan más en entenderlo, los bugs son más sutiles porque la indirección esconde el flujo.

Otros ejemplos cotidianos: el campo metadata: jsonb “por si acaso” que termina lleno de basura inconsistente, el feature flag que nunca se encendió, la función parseInput() que acepta cuatro formatos cuando el sistema sólo recibe uno, el endpoint v2 desplegado antes de que existiera un cliente que pudiera consumirlo.

El argumento contraintuitivo de YAGNI es financiero: cada feature especulativa cuesta tres veces.

1. El coste de construirla ahora, cuando hay otras cosas más urgentes.
2. El coste de mantenerla todos los meses que está en la base de código, aunque nadie la use (más superficie para bugs, tests, refactors).
3. El coste de reescribirla cuando finalmente aparece la necesidad real — porque casi nunca coincide con la necesidad imaginada.

YAGNI no es un manifiesto contra el diseño; es contra el diseño especulativo. Diseñá el código para ser fácil de cambiar mañana, no para anticipar exactamente qué cambio. La diferencia importa.