Co jest fajnego w informatyce

Kilka dni temu zamieściłem tekst o bylejakości i braku motywacji. Pesymistycznie dość to wszystko zabrzmiało, więc - dla wyrównania - o tym, co jest w informatyce fascynujące. A przy okazji, o pewnej metodzie na udane projekty.

Czemu lubię programować

Chyba najważniejszym powodem, dla którego lubię projektować i programować, jest łatwość tworzenia. Czuję się trochę, jak gdybym ugniatał powietrze w realny kształt. Na początku nie ma nic – tylko bezmyślna maszyna. Na koniec – powstaje użyteczne narzędzie. To nie jest takie ważne, czy pisałem skrypcik reformatujący teksty, ważny komponent dużego systemu biznesowego, czy kawałek hobbistycznego serwisu webowego. Ważne jest poczucie tworzenia, kreowania.

Tak, pewnie sięga to aż do małego chłopca zachwyconego stawianiem zamków z piasku i budowli z klocków. I nastolatka lubiącego rozwiązywać zadania z matematyki. Ale też coś z malarza malującego obraz, pisarza piszącego książkę, ogrodnika sadzącego sad, architekta stawiającego dom, czy inżyniera opracowującego prototypowe urządzenie.

Jest też poczucie ogromnej swobody. W świecie oprogramowania nie obowiązuje wiele fizycznych ograniczeń, mogę wymyślać i wypróbowywać najprzeróżniejsze rzeczy – od pomysłów na aplikacje, po szczegółowe algorytmy czy konkretne teksty. Mogę stosować różnorodne architektury. Mogę próbować różnych ścieżek i się z nich cofać. Pod tym względem mam nieskończenie lepiej niż np. architekt, który przecież nie może próbować stawiać ściany w pięciu miejscach po kolei.

Ludzie odpowiedzialni za pilnowanie pieniędzy, terminów, kontraktów, często mówią o niedojrzałości informatyki, chcieliby, by stała się ona bardziej przemysłowa, projekty bardziej powtarzalne i deterministyczne, harmonogramy przewidywalne i pewne. Rozumiem to, nieraz nad tym pracuję – choćby opracowywując dla firmy takie czy inne metody porządkowania procesu wytwórczego – ale … cieszę się, że żyję w czasach, gdy do tego ideału jeszcze dość daleko, gdy każdy projekt niesie nowe ciekawe wyzwania, gdy co dwa trzy lata można wprowadzać kolejne interesujące narzędzia i pomysły.

Mam też świadomość, że to co robię, jest używane, komuś do czegoś służy. Mogę tego kogoś przynajmniej od czasu do czasu zobaczyć. Widzę, że nawet drobiazgi stają się nieraz ważne. Czasem zyskuję wdzięczność, czasem spotykam irytację, ale nie stoję w próżni.

No i jeszcze – iluż ciekawych rzeczy mogę używać, oglądać, poznawać. Języki, środowiska programisty, biblioteki, frameworki, narzędzia uruchomieniowe, serwery usług sieciowych, systemy operacyjne, programy graficzne, reużywalne komponenty,  … – i w niemal każdym jakiś zestaw ciekawych pomysłów, jakiś interesujący ślad przez kogoś zostawiony.

O udanych projektach

Bardzo lubię małe projekty. Takie do zrobienia w dzień, kilka, tydzień, no – dwa tygodnie. Dobrze się przy tym czuję, bardzo efektywnie pracuję. Dużo mniejszy komfort odczuwam i dużo mniej wydajny jestem, gdy wpada na mnie coś mierzonego na długie miesiące. I chyba nie jestem w tego typu poczuciu odosobniony.

Trochę się nad tym zastanawiałem. Tak naprawdę nie chodzi o rozmiar. Napisałem (oczywiście - nie sam, w zespole) kilka naprawdę dużych, rozwijanych latami aplikacji, nad którymi lubiłem i chciałem pracować. Ale aplikacje, które lubiłem, miały pewien element wspólny: powstawały po trochu. Nie sześć miesięcy dłubania, po których coś się powoli wyłania, tylko tydzień, po którym widać jakiś pierwszy ekran, jakąś pierwszą funkcję. Następny, po którym dochodzi kilka dalszych. Kolejny, pozwalający dodefiniować architekturę. Dalszy, w którym udaje się założyć kluczową dokumentację. Jeszcze dwa doprowadzające do stanu, w którym jest już co zademonstrować klientowi. I tak dalej, i tak dalej…

O znaczeniu iteracyjnego developmentu rozpisuje się masa ludzi, od UMLowych guru z Rational, po specjalistów od extreme programming i agile development (przepraszam za anglicyzmy, ale ekstremalne programowanie jakoś nie chce mi przejść przez usta). Najczęstszym argumentem jest tu zwykle łatwość zarządzania projektem i kontrolowania jego kosztu – na każdym etapie możesz przerwać lub wstrzymać projekt i pozostać z użytecznym produktem (któreś tam z praw XP), a także łatwość adaptowania się do zmieniających się wymagań. A ja bardzo sobie cenię coś trochę innego.

Poczucie sukcesu.

Poczucie, że coś stworzyłem.

To, o czym pisałem na początku jako głównym powodzie, dla którego kocham swój zawód.

Czekanie na sukces przez 6 miesięcy jest makabrycznie stresujące. Długo. Długo. Bardzo długo. Siadam codziennie do kodowania i widzę jedynie ogrom piętrzących się zadań, których koniec znika w sinej dali. Nie mogę się zdecydować, którą z rozlicznych spraw zająć się jako pierwszą. No i przez cały ten długi okres nie mam powodów do satysfakcji. Projekt, nawet gdy jest ciekawy, ciąży. Irytuję się, gdy jestem odrywany do poprawek czy uzupełnień w starszym kodzie - boć tyle do zrobienia, więc wszystko mi przeszkadza – ale z drugiej strony, dają mi to pewną ulgę – dwa-trzy dni na poprawianie jakiegoś zastałego błędu i mam poczucie sukcesu.

Do tego – właściwie czemu 6 miesięcy? Może to jednak 8? A może 5? Dość długo przejmowałem się tym, że robię grube błędy próbując szacować większe projekty. Ciągle chciałbym umieć robić to lepiej, ale … to trochę nie tak. Joel Spolsky napisał: rozpisz swoje zadania na małe fragmenty mierzone w godzinach. Nie więcej niż 16 godzin na jedno. (…) Jeśli bierzesz trzytygodniowe zadanie, to po prostu nie przemyślałeś, co jest do zrobienia. Bah – trzytygodniowe.

Oczywiście te paru/parunastogodzinne zadania można składać w większe pudełka, sumować i budować z tego większe plany. Tylko – one są opatrzone sporym błędem. Kosztują nie tylko zadania ale też przełączanie się między nimi, programiści nie są wymienialni, nie da się przewidzieć dokładnie wszystkich zadań w wielomiesięcznym projekcie, ani nawet jacy ludzie kiedy będą dostępni. Stąd zwykłe odhaczenie jakiegoś zadania nie daje pełnej satysfakcji, gdzieś tam drzemie zawsze wątpliwość ile tak naprawdę jeszcze zostało.

Reasumując – jednym z kluczów do udanego projektu wydaje mi się zaplanowanie go jako serii dość wąskich iteracji. A przynajmniej – rozbicie na małe zadania. Tylko – te zadania muszą mieć wyraźne kryteria powodzenia. Osiągnięcie około 80% kodu komunikacyjnego nie daje satysfakcji sukcesu. Działające okno logowania – i owszem.

Na niskim poziomie (tworzenia bibliotek, funkcji, modułów), fajne poczucie sukcesu daje pisanie unit-testów. Gdy na uruchomienie całej aplikacji muszę poczekać, mogę przynajmniej od czasu do czasu puścić testy, zobaczyć, że coś działa, zobaczyć, że testów przybywa.