YAGNI in app-ontwikkeling: wat is het, essentie van het principe en praktisch voordeel

Wat is YAGNI?

YAGNI (You Aren't Gonna Need It) — een principe van extreem programmeren (XP) dat „je zult het niet nodig hebben“ betekent. De regel zegt: implementeer nooit functionaliteit die niet vereist is door de huidige gebruikersverhalen. Als een functie vandaag niet nodig is — doe het dan niet, zelfs niet „voor het geval dat“.

De term is geïntroduceerd door Ron Jeffries, een van de co-auteurs van de XP-methodologie (samen met Kent Beck). Jeffries stelde: „Implementeer het eenvoudigste dat werkt en voeg niets toe totdat het nodig is“. YAGNI — is geen verbod op planning, maar een verbod op voortijdige implementatie.

Volgens Standish Group CHAOS Report (2023) wordt 64% van de functies in een gemiddeld softwareproduct zelden of nooit gebruikt. Als we dit extrapoleren naar een mobiele app — meer dan de helft van de geschreven code biedt geen waarde voor de gebruiker. YAGNI voorkomt deze verspilling van middelen.

Pas YAGNI toe als een strikt filter: elke functie moet de vraag beantwoorden „welk probleem van een concrete gebruiker lost het nu op?“ Als er geen antwoord is — is de functie niet nodig.

Verschil tussen YAGNI en luiheid en hoeken afsnijden

YAGNI — is geen afstand doen van kwaliteitsarchitectuur. YAGNI verbiedt het schrijven van overbodige code, maar verbiedt niet het schrijven van correcte code. Als voor de huidige functie een schone abstractielaag nodig is — creëer deze. Als de laag niet nodig is — creëer deze niet. Belangrijkste verschil: YAGNI gaat over functionaliteit, niet over kwaliteit.

Ontwikkelaars verwarren YAGNI vaak met het opzettelijk ophopen van technische schuld (technische schuld is altijd een compromis, YAGNI is een principe van efficiëntie). Verschil is dat technische schuld bewust en gedocumenteerd is, terwijl het schenden van YAGNI gewoon overbodig werk is.

Stel jezelf de vraag: „Als ik deze abstractie nu niet doe, hoeveel tijd kost refactoring wanneer het nodig is?“ Als de refactoringtijd korter is dan de schrijftijd nu — stel het uit.

Waarom is YAGNI kritisch voor mobiele projecten?

Mobiele app-ontwikkeling is bijzonder gevoelig voor schending van YAGNI om drie redenen: APK/IPA-grootte beïnvloedt direct de installatieconversie, compilatietijd van mobiele projecten groeit lineair met de codeomvang, en elke extra functie voegt faalpunten toe. YAGNI — gaat niet over luiheid, maar over focus.

Google Play Console Data (2023) toonde aan: elke 10 MB APK-grootte verlaagt de installatiekans met 1,2%. Ongebruikte code is niet alleen rommel in de repository, het is direct financieel verlies. Overbodige bibliotheken (voor functionaliteit die „misschien later toevoegen“) — de meest voorkomende bron van APK-zwelling.

Gradle Build Performance Report (2024), elke extra module in een Android-project verhoogt de volledige buildtijd met 3–7 seconden. Als je 5 modules „voor de toekomst“ toevoegt — bedraagt de toename van de compilatietijd 15–35 seconden bij elke build. In een jaar verliest een team van 5 ontwikkelaars tot 200 manuren aan het wachten op compilatie.

Monitor de binaire grootte in CI: stel een waarschuwingslimiet in (bijv. +500 KB per commit). Als de grootte is toegenomen zonder nieuwe functie — is dit een YAGNI-schending die moet worden besproken tijdens code review.

YAGNI vs gold-plating: praktijkvoorbeelden

Gold-plating: voortijdige animatie

Gold-plating — het toevoegen van functionaliteit boven de vereisten in een poging het product te „verbeteren“. Typisch voorbeeld: een ontwikkelaar voegt een complexe overgangsanimatie tussen schermen toe, hoewel in het ontwerp een simpele fade is gespecificeerd. De animatie kost 2 dagen, de gebruiker merkt het niet, en bugs op verschillende apparaten achtervolgen het project jarenlang.

UX Collective Annual Report (2023) 78% van de gebruikers beoordeelt de app op snelheid en stabiliteit, niet op animaties. YAGNI zegt: als de animatie niet in de vereisten staat — implementeer deze dan niet. De ontwerper voegt de animatie toe wanneer deze echt nodig is om een UX-probleem op te lossen.

Implementeer alleen wat in de ontwerpen staat. Als de ontwerper geen animatie heeft getekend — betekent dit dat deze er niet zou moeten zijn. Elke afwijking van het ontwerp is een YAGNI-schending.

Voortijdige lokalisatie in 20 talen

Een veelgemaakte fout van startups: meteen ondersteuning bieden voor 20+ talen „voor de toekomstige internationale markttoetreding“. YAGNI beveelt aan: lokaliseer alleen in de taal van de huidige markt. Elke nieuwe taal vereist tijd van vertalers, testen van strings op afkapping en het debuggen van RTL-lay-out.

Deloitte Digital Globalization Survey (2022) toonde aan: 60% van de mobiele apps komt nooit buiten de eerste markt. Als dit jouw geval is — zijn de middelen voor meertaligheid verspild. YAGNI-benadering: Engels (basis) + taal van de doelmarkt. De rest — naarmate je daadwerkelijk een regio betreedt.

Gebruik YAGNI voor prioritering: als een functie niet in de roadmap van de komende twee kwartalen staat — begin er dan niet aan. De roadmap moet documentair worden goedgekeurd door de productmanager.

Hoe pas je YAGNI toe in Android en iOS?

YAGNI in Android: voeg geen overbodige bibliotheken toe

Android-projecten lijden aan bibliotheekinflatie. Ontwikkelaars koppelen Retrofit, OkHttp, Gson, Room, Dagger Hilt, Navigation Component, DataStore — nog voordat de eerste regel bedrijfslogica is geschreven. YAGNI beveelt aan: koppel bibliotheken naarmate echte behoefte ontstaat, niet preventief.

// YAGNI-schending: preventief koppelen van bibliotheken
// 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")

// En de app laat voorlopig gewoon "Hello World" zien

Bibliotheken zijn afhankelijkheden met eigen complexiteit. Elke vereist versie-updates, migratie bij breaking changes en vergroot de APK-grootte. Koppel een bibliotheek wanneer er een concrete taak verschijnt die door die bibliotheek wordt opgelost. Begin met OkHttp (minimale HTTP-client), voeg Retrofit toe wanneer een REST-client nodig is, enz.

YAGNI in iOS: forceer SwiftUI niet

SwiftUI — een krachtig framework, maar de implementatie ervan moet worden gedicteerd door echte behoeften. Als het project start met iOS 14+ en de vereisten voor aangepaste UI-componenten minimaal zijn — is SwiftUI een goede keuze. Als het project iOS 13 moet ondersteunen of complexe aangepaste gebaren vereist — blijft UIKit de juiste oplossing. YAGNI is tegen migratie naar SwiftUI „omdat het trendy is“.

// YAGNI: gebruik UIKit zolang er geen echt voordeel is van SwiftUI
class ProfileViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "Profiel"
    }
}

// Als SwiftUI nodig is — implementeer via UIHostingController
let swiftUIView = ProfileView()
let hostingVC = UIHostingController(rootView: swiftUIView)

Point-Free: „SwiftUI vs UIKit Decision Guide“ (2024) migreer bestaande UIKit-schermen niet naar SwiftUI zonder duidelijke zakelijke reden (bijv. behoefte aan Live Preview voor de ontwerper). Het herschrijven van werkende code is een directe YAGNI-schending. SwiftUI — voor nieuwe schermen, UIKit — voor bestaande.

Veelgemaakte fouten bij het volgen van YAGNI

YAGNI als excuus voor slechte architectuur

De gevaarlijkste fout — YAGNI gebruiken als excuus voor slechte architectuur. „We gaan de repositorylaag niet scheiden, want YAGNI — we schrijven de query rechtstreeks in de ViewModel“. Dit is geen YAGNI, dit is technische schuld opbouwen. YAGNI verbiedt overbodige functionaliteit, niet architectonische integriteit.

Architectuur is een investering in onderhoudbaarheid. Als je meer dan 3 schermen schrijft — is de basisarchitectuurlaag (MVVM, repository) al gerechtvaardigd. Bij 1 scherm — kun je een eenvoudige benadering hanteren. Sleutel: bepaal het architecturale minimum dat nodig is voor de huidige functies en voeg niet meer toe.

Verdeel beslissingen in „architectonisch“ en „functioneel“. Architectonische beslissingen (lagen, navigatie, DI) vallen niet onder YAGNI — ze zijn nodig voor onderhoudbaarheid. Functionele beslissingen (functies, schermafbeeldingen, animaties) — vallen er wel onder.

Blind YAGNI volgen bij het werken met API

Het andere uiterste — het negeren van toekomstige API-contracten. Een ontwikkelaar ontvangt een JSON met 5 velden van de backend en parseert slechts 3, omdat „de rest volgens YAGNI niet nodig is“. Probleem: bij het toevoegen van een veld kan de backend het parsen verbreken als het antwoord is veranderd. Oplossing — alle antwoordvelden mappen, zelfs als ze niet allemaal nu worden gebruikt.

Volgens Meta API Design Guidelines (2023) moet de client alle velden parsen die de server retourneert, ongebruikte negeren, maar niet de hele structuur weggooien. YAGNI gaat hier over iets anders: het is niet nodig om verwerking toe te voegen voor velden die nog niet in de specificatie staan, ‡voor het geval de backend ze retourneert“.

Parseer de hele antwoordstructuur (alle velden die de server nu retourneert). Voeg geen verwerking toe voor velden die niet in de huidige API-specificatie staan. Dit is de balans tussen YAGNI en weerbaarheid tegen veranderingen.