YAGNI en el desarrollo de aplicaciones: qué es, la esencia del principio y su beneficio práctico

¿Qué es YAGNI?

YAGNI (You Aren't Gonna Need It) — un principio de programación extrema (XP) que significa “no lo vas a necesitar”. La regla dice: nunca implementes funcionalidad que no sea requerida por las historias de usuario actuales. Si una función no se necesita hoy — no la hagas, ni siquiera “por si acaso”.

El término fue acuñado por Ron Jeffries, uno de los coautores de la metodología XP (junto con Kent Beck). Jeffries afirmaba: “Implementa la cosa más simple que funcione y no añadas nada hasta que sea necesario”. YAGNI no es una prohibición de planificar, sino una prohibición de implementación prematura.

Según el Standish Group CHAOS Report (2023), el 64% de las funciones en un producto de software promedio se usan rara vez o nunca. Extrapolando a una aplicación móvil — más de la mitad del código escrito no aporta valor al usuario. YAGNI previene este desperdicio de recursos.

Aplica YAGNI como un filtro estricto: cada función debe responder a la pregunta “¿qué problema específico de un usuario resuelve ahora mismo?” Si no hay respuesta — la función no es necesaria.

Diferencia entre YAGNI y la pereza o los atajos

YAGNI no es un rechazo a la arquitectura de calidad. YAGNI prohíbe escribir código innecesario, pero no prohíbe escribir código correcto. Si una función actual necesita una capa de abstracción limpia — créala. Si la capa no es necesaria — no la crees. Diferencia clave: YAGNI trata sobre funcionalidad, no sobre calidad.

Los desarrolladores a menudo confunden YAGNI con la acumulación intencional de deuda técnica (la deuda técnica siempre es un compromiso, YAGNI es un principio de eficiencia). La diferencia es que la deuda técnica se reconoce y documenta, mientras que violar YAGNI es simplemente trabajo extra.

Pregúntate: “Si no creo esta abstracción ahora, ¿cuánto tiempo tomará la refactorización cuando se necesite?” Si el tiempo de refactorización es menor que el tiempo de escritura ahora — pospónlo.

¿Por qué YAGNI es crítico para proyectos móviles?

El desarrollo móvil es especialmente sensible a las violaciones de YAGNI por tres razones: el tamaño del APK/IPA afecta directamente la tasa de conversión de instalación, el tiempo de compilación de los proyectos móviles crece linealmente con el volumen de código, y cada función adicional añade puntos de fallo. YAGNI no es sobre pereza, sino sobre enfoque.

Un estudio de Google Play Console Data (2023) mostró: cada 10 MB de tamaño del APK reduce la probabilidad de instalación en un 1.2%. El código no utilizado no es solo basura en el repositorio — es una pérdida financiera directa. Las bibliotecas adicionales (para funcionalidad que “tal vez añadamos después”) son la fuente más común de inflación del APK.

Según el Gradle Build Performance Report (2024), cada módulo adicional en un proyecto Android aumenta el tiempo de compilación completa en 3–7 segundos. Si añades 5 módulos “por si acaso” — el incremento del tiempo de compilación será de 15–35 segundos por cada compilación. En un año, un equipo de 5 desarrolladores pierde hasta 200 horas-persona esperando la compilación.

Monitorea el tamaño del binario en CI: establece un límite de advertencia (por ejemplo, +500 KB por commit). Si el tamaño creció sin una nueva función — es una violación de YAGNI que debe discutirse en la revisión de código.

YAGNI vs gold-plating: ejemplos prácticos

Gold-plating: animación prematura

Gold-plating — añadir funcionalidad más allá de los requisitos en un intento de “mejorar” el producto. Un ejemplo típico: un desarrollador añade una animación compleja de transición entre pantallas, aunque el diseño especifica un fade simple. La animación toma 2 días, el usuario no la nota y los errores en diferentes dispositivos persiguen el proyecto durante años.

Según el UX Collective Annual Report (2023), el 78% de los usuarios evalúan una aplicación por su velocidad y estabilidad, no por sus animaciones. YAGNI dice: si la animación no está especificada en los requisitos — no la implementes. El diseñador añadirá la animación cuando realmente sea necesaria para resolver un problema de UX.

Implementa solo lo que está en los diseños. Si el diseñador no dibujó una animación — no debería existir. Cualquier desviación del diseño es una violación de YAGNI.

Localización prematura a 20 idiomas

Un error común de las startups: incorporar inmediatamente soporte para 20+ idiomas “para la futura entrada al mercado internacional”. YAGNI recomienda: localiza solo al idioma del mercado actual. Añadir cada nuevo idioma requiere tiempo de traductores, pruebas de cadenas para recorte y depuración de diseños RTL.

Según el Deloitte Digital Globalization Survey (2022), el 60% de las aplicaciones móviles nunca salen de su primer mercado. Si ese es tu caso — los recursos invertidos en soporte multilingüe se desperdician. Enfoque YAGNI: inglés (base) + idioma del mercado objetivo. Los demás — a medida que realmente entres en una región.

Usa YAGNI para priorizar: si una función no está en la hoja de ruta de los próximos dos trimestres — no la empieces. La hoja de ruta debe estar documentada y aprobada por el product manager.

¿Cómo aplicar YAGNI en Android e iOS?

YAGNI en Android: no añadas bibliotecas innecesarias

Los proyectos Android sufren de inflación de bibliotecas. Los desarrolladores añaden Retrofit, OkHttp, Gson, Room, Dagger Hilt, Navigation Component, DataStore — incluso antes de escribir la primera línea de lógica de negocio. YAGNI recomienda: añade bibliotecas según la necesidad real, no de forma preventiva.

// Violación de YAGNI: inclusión preventiva de bibliotecas
// build.gradle (module)
implementation("com.squareup.retrofit2:retrofit:2.9.0")
implementation("com.squareup.retrofit2:converter-gson:2.9.0")
implementation("androidx.room:room-runtime:2.6.0")

// Y la aplicación solo muestra "Hello World"

Las bibliotecas son dependencias con su propia complejidad. Cada una requiere actualizaciones de versión, migración en cambios disruptivos y aumenta el tamaño del APK. Añade una biblioteca cuando surja una tarea específica que esa biblioteca resuelva. Comienza con OkHttp (cliente HTTP mínimo), añade Retrofit cuando necesites un cliente REST, y así sucesivamente.

YAGNI en iOS: no fuerces SwiftUI

SwiftUI es un framework potente, pero su adopción debe estar impulsada por necesidades reales. Si un proyecto comienza con iOS 14+ y los requisitos de componentes UI personalizados son mínimos — SwiftUI es una buena opción. Si un proyecto debe soportar iOS 13 o requiere gestos personalizados complejos — UIKit sigue siendo la solución correcta. YAGNI se opone a migrar a SwiftUI “porque está de moda”.

// YAGNI: usa UIKit mientras no haya un beneficio real de SwiftUI
class ProfileViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "Perfil"
    }
}

// Si se necesita SwiftUI — intégralo a través de UIHostingController
let swiftUIView = ProfileView()
let hostingVC = UIHostingController(rootView: swiftUIView)

El análisis de Point-Free: “SwiftUI vs UIKit Decision Guide” (2024) recomienda: no migres pantallas UIKit existentes a SwiftUI sin una razón de negocio clara (por ejemplo, la necesidad de Live Preview para el diseñador). Reescribir código que funciona es una violación directa de YAGNI. SwiftUI — para nuevas pantallas, UIKit — para las existentes.

Errores típicos al seguir YAGNI

YAGNI como excusa para una mala arquitectura

El error más peligroso es usar YAGNI como excusa para una mala arquitectura. “No crearemos una capa de repositorio porque YAGNI — escribiremos la consulta directamente en el ViewModel”. Esto no es YAGNI, es acumular deuda técnica. YAGNI prohíbe la funcionalidad innecesaria, no la integridad arquitectónica.

La arquitectura es una inversión en mantenibilidad. Si estás escribiendo más de 3 pantallas — una capa arquitectónica básica (MVVM, repositorio) ya está justificada. Si es 1 pantalla — puedes permitirte un enfoque más simple. La clave: determina el mínimo arquitectónico necesario para las funciones actuales y no añadas más.

Separa las decisiones en “arquitectónicas” y “funcionales”. Las decisiones arquitectónicas (capas, navegación, DI) no están cubiertas por YAGNI — son necesarias para la mantenibilidad. Las decisiones funcionales (funciones, capturas de pantalla, animaciones) — sí están cubiertas.

Seguir YAGNI ciegamente al trabajar con APIs

Otro extremo — ignorar los contratos futuros de la API. Un desarrollador recibe un JSON del backend con 5 campos y analiza solo 3, porque “los demás no son necesarios según YAGNI”. El problema: al añadir un campo, el backend podría romper el análisis si la respuesta cambió. La solución es mapear todos los campos de la respuesta, incluso si no todos se usan ahora.

Según las Meta API Design Guidelines (2023), el cliente debe analizar todos los campos que devuelve el servidor, ignorando los no utilizados, pero sin descartar toda la estructura. YAGNI aquí trata de otra cosa: no añadas manejo de campos que aún no están en la especificación “por si acaso el backend los devuelve”.

Analiza toda la estructura de la respuesta (todos los campos que el servidor devuelve actualmente). No añadas manejo de campos que no están en la especificación actual de la API. Este es un equilibrio entre YAGNI y la resiliencia al cambio.