Fajny temat się tutaj pojawił. Warto jest by znaleźć złoty środek między "programowaniem zachłannym" czyli robimy asap a "arcydziełem sztuki" czy cyzelowaniem nawet najmniejszych detali. Generalnie staram się myśleć o tym jak sprawić, by kod który jest w chwili obecnej był w jak najlepszym stanie - najbardziej czytelny, logicznie uporządkowany, pokryty testami etc. bo założenie jest, że kod jest żywy i ważne jest, by jak najłatwiej (niekoniecznie najszybciej) go sensownie rozwijać. Ostatnio w pracy miałem przypadek który oddaje myśl tej zasady- miałem zaimplementować rozwiązanie, które zadziała dla pewnych kombinacji możliwych przypadków - może być sam przypadek lub jego kombinacja z innym. Póki nie ma kombinacji z trzema czynnikami (przypadek A - przypadek B - przypadek C) nie dodałem takiego kawałka kodu, bo nie jest potrzebny, ale obecny kod jest na tyle sensownie napisany, że gdy przyjdzie prośba od product ownera, by zrobić kombinację trzech przypadków, dodanie tego będzie analogiczne, a co za tym idzie łatwe.
Dostrzegam, że dla pewnego grona programistów YAGNI czy KISS są usprawiedliwieniem "robienia na szybko", a zupełnie nie o to chodzi :)
Edit: Inna sprawa, gdy ktoś np. założył taska, by dodać pole A, a też chcą pole B etc. to wtedy robi się to za jednym zamachem, nie czekając aż wystawią kolejny "tiket". Są różne szkoły i niektórzy opóźniają development innych zespołów tłumacząc się jirą czyt. biurokracją, ale wtedy się przydaje trochę rozsądku i empatii :)
Edit2: Zakładanie, że naprawimy buga dopiero jak poleci na produkcji, bo np. może się trafić race condition to najgorsze możliwe założenie... W tym wypadku trzeba przewidywać zawczasu, bo naprawienie buga, którego się samo stworzyło to żaden powód do dumy.