Kiedy przychodzi nowy projekt, nowe zadanie lub nowy pomysł najchętniej rzucamy się do komputera i zaczynamy pisać mając głowę pełną pomysłów i pracując na naprawdę wysokich obrotach - wymyślamy wszystko na bieżąco. Pracujemy pełni zapału i początkowo wszystko idzie dobrze. Jednak każde zakończenie projektu jakie pamiętam było totalną łataniną podczas której nic nie idzie tak jak powinno, a doskonałe idee o jakie opieraliśmy się na początku - wyglądają szaro i bezsensownie.

W zasadzie można by to porównać do stanu niezłego upojenia w którym większość pomysłów i działań wydaje się doskonała, lecz w miarę jak trzeźwiejemy - powoli ogarnia nas przerażenie, że z tym co popełniliśmy trzeba będzie teraz żyć.

Jeśli ktoś jest ciekaw jak coś takiego wygląda - najłatwiej się przekonać pozostając jedynym trzeźwym na studenckiej imprezie. Albo jeszcze lepiej - zrezygnować z trzeźwości, ale nagrać całość i po paru dniach wszystko sobie obejrzeć.

Dokładnie tak samo piszemy większość programów. Dotyczy to nie tylko tych projektów które robimy dla własnej przyjemności, ale wszystkich. W zasadzie wszystkie powinniśmy pisać dla przyjemności, ale wiadomo jak to jest z teorią. Praktyka pokazuje ze z przyjemnością tylko zaczynamy pisać - powoli organizując sobie piekło wykańczania programu.

Najciekawsze jest to, że nigdy na początku nie mamy czasu by opisać to co chcemy zrobić. Nie ma czasu nic zaprojektować bo mamy w głowie kolejne klasy, które trzeba wpisać, przetestować i użyć.

A potem. Jak już napiszemy 1000 funkcji, 1000 klas i zapiszemy to wszystko w 1000 plików, wierząc ciągle, ze jesteśmy to w stanie zapamiętać - przychodzi niemiłe przebudzenie, gdy szukamy właściwego pliku i funkcji, by zrobić niewielką poprawkę Lub pod koniec programowania staramy się odkryć jak to wszystko działa, by sprawdzić czy poprawkę można zrobić nie przebudowując wszystkiego.

Jeśli porównamy pisanie programów do budowania domu, to wygląda to tak jakbyśmy zaczęli od zaplanowania w jakim kolorze będą ściany i jak wysoko powiesimy lustro w łazience, a po wybraniu wzór wykładziny zaczniemy stawiać fundamenty i dopasowywać dachówki nie wiedząc jeszcze ile postawimy pięter.

A kiedy już zaczniemy budować. Kiedy staną fundamenty oraz fragmenty dachu podparte kijem - to okaże się że mamy znacznie mniej możliwości kontynuowania pracy. Na koniec jesteśmy skazani na wstawianie fragmentów cegieł tak gdzie zostały szpary i mamy ochotę przejechać po wszystkim buldożerem. A wystarczyło przejechać po rozpoczętych fragmentach - tylko wtedy byliśmy skoncentrowani na szczegółach i wszystko wyglądało na genialne.

Jak tego uniknąć?

W praktyce - nie jest to możliwe.

W teorii - jest wiele schematów pozwalających odwlec chwilę gdy tracimy z oczu całość i przestajemy panować nad tym co robimy. Od podziału na procedury, obiekty, poprzez pisanie bibliotek i "czarnych skrzynek", użycie gotowych komponentów, "extreme programming" czy rezygnację z iteracyjnego wykonywania programu: analiza - projekt - program na rzecz kolejnych ciągłego powrotu do analizy i projektowania.

Jeśli jednak zaczniemy - nasze myśli będą zdeterminowane tym co już napisaliśmy, lub tym co już pomyśleliśmy. Nawet pomysły dotyczące analizy są ruchem który pociąga za sobą kolejne kroki.

Czy można tego uniknąć?

Nie można!

Ale można odwlec początek ruchu. Odwlec jakiekolwiek decyzje dotyczące rozwiązań. Ale uwaga: tylko decyzje. Zapisujmy pomysły, stojąc ciągle w miejscu. Pomysły dotyczące zarówno szczegółów jak i założeń całego programu lub systemu. Te najbardziej oczywiste i te najbardziej szalone. Typowe i najbardziej zwariowane. Zapisać, nagrać, narysować. Nawet jeśli będą wymagały nieprzyzwoitych porównań czy odwołań do dowcipów lub kreskówek.

Potem należy wytrzeźwieć.

A jeszcze później - zatrzymać się i wybrać te pomysły które są ciekawe, realne, i sprawiają wrażenie pomagających rozwiązać nasze problemy. Najlepiej całym zespołem. Ten wybór jest początkiem ruchu.

Jeśli pojawią się później dodatkowe pomysły. Wróćmy do etapu burzy mózgów i pozwólmy sobie na odrobinę szaleństwa. Niech nas nie krępuje to co już powstało. Niech nie wiąże napisany kod do którego trzeba to będzie dokleić. Nad tym zastanowimy się później.

Pomysły powinny się pojawiać w oderwaniu od kierunku naszego działania. Powinniśmy wyrzucić z siebie wszystkie pomysły, pełne emocji, a potem wybrać te które są dobre tu i teraz. Pozostałe mogą się jeszcze przydać.

Oczywiście nie jesteśmy w stanie całkowicie się oderwać od poprzednich decyzji i napisanego już kodu, ale to nawet i lepiej. W ten sposób ciągle dążymy do określonego celu, a przynajmniej w tym losowym błądzeniu naszej wyobraźni jesteśmy unoszeni poprzez nieświadomie narzucane pęta podjętych decyzji.

Kiedyś byłem zwolennikiem projektowania programu z wszystkimi możliwymi dodatkami a następnie wybierania tylko tego co jest potrzebne w bieżącej wersji i tego co daje się osiągnąć w przewidzianym czasie. To w teorii pozwalało na przewidzenie co i gdzie będzie dorabiane. Praktyka wykazała jednak, że większość wymyślonych opcji nigdy nie była nikomu do niczego potrzeba, a projektowaliśmy je nie dla tego że mogły być potrzebne, ale dlatego że łatwo je zrobić. To jak sypać piasek do pączków tylko dlatego, że to takie proste.

Zamiast tego. Pobawmy się w pomysły razem z naszymi przyszłymi użytkownikami. Wspólna medytacja pozwala się zrozumieć bez słów.

Potem decyzje możemy podjąć również wspólnie - jak partnerzy w tańcu. Tylko tu trudniej powiedzieć kto kogo prowadzi. A pomiędzy kolejnymi tańcami - pozwólmy sobie na chwilę bezruchu, by zrozumieć błędy, i by móc zacząć tańczyć inny krok, gdy następny taniec będzie miał inny rytm.

Mówi się ciągle o inżynierii programowania. To jak zawody taneczne.

Dla mnie taniec jest sztuką i radością

Tak jak programowanie

Tak jak każda inna droga życia.

I tak jak każde działanie - wymaga nie działania - przed rozpoczęciem. W taki sam sposób jak alpinista stojąc przed skalną ścianą zastanawia się i wybiera drogę, tak stojąc przed zadaniem, wybieramy narzędzia, szukamy drogi, żartujemy i pozwalamy sobie na chwilę odpoczynku i zadumy.