Był taki film "Dzień Świstaka", w którym gość przeżywał ciągle ten sam dzień 2 lutego. Najpierw przydarzało mu się wiele pechów, np. szedł ulicą i samochód go ochlapywał itp. A później, ponieważ już ten sam dzień przeżył ileś razy, to wiedział, co się stanie i bawił się tym. Wiedział, w którym miejscu przejedzie samochód, wiedział, kogo spotka, co powiedzieć, czego nie mówić itp.
Tak samo z programistami - przy pierwszej implementacji ilość niewiadomych jest zbyt wielka, żeby od razu napisać prosty jasny kod - dlatego wychodzi spaghetti. Ew. jak ktoś jest "bojący się", to będzie stawiał na elastyczność i wzorce i doprowadzi do overengineeringu, co mu niewiele da (bo problem nie jest z jakością kodu, tylko z brakiem doświadczenia programisty w rozwiązywaniu danego typu problemów).
A jak już się rozwiązywało wcześniej jakiś problem ileś razy, to można pisać od razu lepiej, bo się wie, co się sprawdza, co się nie sprawdza. Łatwiej można przewidzieć różne problemy na długo, zanim wystąpią (bo widzieliśmy je już ileś razy). Jeśli jakichś wzorców warto użyć, to wiemy, jakich, a jakich lepiej nie - bo mamy know-how.
Być może software lepiej by wyglądał, gdyby na wczesnym etapie projektu programiści zamiast pisać produkcję, to robili masę PoCy i przepisywali od nowa po ileś razy, nabywając know how. Na późniejszym etapie ciężko przepisywać wszystko, jednak taką taktykę można by zastosować do nowych ficzerów. Zamiast wrzucać brzydki kod, robić implementację po kilka razy i wrzucić coś dopracowanego.