Wielkim problemem ogromnej części projektów informatycznych jest przeładowanie funkcjonalnością. Często spotykanym błędem popełnianym na etapie planowania wizji softu jest traktowanie mającego powstać systemu jak nieskończonego wora bez dna i dorzucanie do niego i tego, i tamtego i jeszcze stu innych rzeczy. Takie podejście niesamowicie podnosi koszty oraz stopień skomplikowania jego początkowej realizacji. Prawie zawsze przy wycenie specyfikacji projektu staram się zidentyfikować takie “nie-niezbędne” punkty i przekonać klienta, że naprawdę warto dać sobie z nimi spokój. O ile faktycznie nie są absolutnie konieczne do wykonywania przez system planowanych dla niego zadań. Im mniej rzeczy projektant/programista musi mieć w głowie przez rozpoczęciem prac, tym większe szanse na powodzenie projektu. A pozostałe bajery zawsze można dodać później, jeśli samo “core” projektu wypali.
Jak ulał pasuje do powyższych praktyk poniższe zdanie:
The secret to building half a product instead of a half-ass product is saying no. (…) Make each feature work hard to be implemented.
Źródło: “Getting Real” by 37Signals (rozdział Feature Selection: Start With No).
Identycznie jest z silnikami do gier jak ktoś chce napisać własny. Zaczyna się zawsze od super możliwości: post-process i inne, a pózniej się okazuje że tego nie zrobię itd.
Najlepiej od podstaw tak jak napisałeś. Napisać prototyp i do niego coś dodawać aż coś powstanie