YAGNI (You Aren't Gonna Need It - „nie będziesz tego potrzebować") to zasada z Extreme Programming: nie buduj funkcjonalności na zapas, tylko dlatego, że „kiedyś może się przydać". Buduj, gdy potrzeba staje się realna - bo większość przewidywanych potrzeb nigdy się nie materializuje, a kod napisany na zapas trzeba utrzymywać, testować i obchodzić przez lata.
Dla analityka YAGNI to narzędzie cięcia zakresu. Interesariusze naturalnie pęcznieją w wymaganiach, dostawcy chętnie sprzedają więcej, a każdy nadmiarowy moduł to koszt: nie tylko budowy, ale utrzymania, regresji, komplikacji interfejsu. Pytanie kontrolne analityka brzmi: jaki zidentyfikowany dziś problem to rozwiązuje? „Może kiedyś" nie jest odpowiedzią.
Przykład z MediFlow: dostawca systemu rejestracji zaproponował w ofercie moduł wielojęzyczny (sześć języków) i architekturę „gotową na 50 placówek". Sieć ma 12 przychodni, plany rozwoju mówią o 15 w trzy lata, a pacjenci obcojęzyczni to mniej niż 1% rezerwacji. Wycięcie obu pozycji obniżyło koszt wdrożenia o blisko 30%. Zostały tylko decyzje architektoniczne nieblokujące przyszłości: teksty interfejsu w plikach zasobów (gdyby języki kiedyś były potrzebne) i identyfikator placówki w modelu danych od pierwszego dnia.
I tu leży częsta pomyłka: mylenie YAGNI z ignorowaniem architektury. YAGNI mówi „nie buduj funkcji na zapas", nie mówi „nie myśl o przyszłości". Projektuje się tak, by rozszerzenie było możliwe, ale samego rozszerzenia się nie buduje, dopóki nie jest potrzebne. Druga pomyłka: używanie YAGNI jako wymówki do cięcia jakości. Testy, obsługa błędów i bezpieczeństwo to nie są „funkcje na zapas".