TheTarPit

wycieczka do piekła

Im więcej różnych programistów lub zespołów roboczych pracuje nad projektem informatycznym w czasie całej jego historii, tym trudniej jest „zgrać” efekty ich działań i tym niższej jakości jest produkt tego projektu. Obserwacja ta wydaje się oczywista, wręcz banalna, a mimo to bywa zupełnie niepojęta dla przedstawicieli pewnego specyficznego, choć zadziwiająco popularnego nurtu zarządzania.

larum grają

Wbrew temu, co się niektórym wydaje, nie wystarczy znaleźć człowieka, który „zna” dany język czy środowisko i wrzucić go do zespołu na tydzień czy miesiąc aby poprawić kondycję projektu. Wiedza na temat technologii jest niemal zupełnie bez znaczenia wobec faktu braku znajomości danego projektu. Z drugiej strony z moich (zresztą równie oczywistych) obserwacji wynika, że tendencję do wchłaniania wszystkich „zasobów ludzkich” z okolicy przejawiają zazwyczaj projekty w mocno zaawansowanym stadium upadku. Zatem tym bardziej znajomość najróżniejszych „bo tak już jest” i „tak ma być”, których projekt w tym stadium jest pełny, jest niezbędna do tego, by w ogóle zrozumieć co się wokół dzieje.

Pomijam już fakt, że zwiększenie ilości „robotników” w projekcie powyżej pewnej masy krytycznej powoduje spadek ogólnej wydajności ze względu na ogromne (względnie) nakłady na komunikację. Przecież takiego nowego zawodnika nie można pozostawić samego — trzeba mu pokazać, nauczyć, wdrożyć, potem obserwować, kontrolować — trzeba mu poświęcić wiele czasu, którego na pewno nikt w tym momencie nie ma. Pomijam również to, jak (nie)wielu menadżerów zarządzających projektami informatycznymi zdaje sobie z tego prostego faktu sprawę. To kwestia zdolności lub braku zdolności kierowania ludźmi i ewentualnie wpływu polityki na sposób myślenia odpowiedzialnych za „human resources”. Natomiast bardziej interesująca wydaje się kondycja psychiczna programisty postawionego w takiej sytuacji...

przybyłem, zobaczyłem, uciekłem

Sytuacje werbowania wszystkich do projektu w stanie „musimy zdążyć, bo tak nam dołożą, że się nie pozbieramy” widziałem zdecydowanie zbyt wiele razy i wszystkie one wiązały się z bardzo silnym wrażeniem obrzydzenia. Nie chodzi już nawet o bałagan organizacyjny, o niejasne kompetencje, notoryczne niedotrzymywanie terminów najłatwiejszych nawet zadań, czy najróżniejsze drobne nieporozumienia — to są rzeczy oczywiste jeśli potraktujemy je jako ruchy przedagonalne. Moje obrzydzenie dotyczyło kwestii jakości produktu czy samego kodu nawet.

Na przykład co mam myśleć o programie, w którym występuje taka sekwencja wywołań metod:

pobierzListaPismDoWydruku()
  getListaOdwolanDlaRaport()
    dajListeOdwolanDoRaportu()

i na dokładkę istnieje jeszcze getter:

public Vector getListaPisOdw() {
  return listaPismDoWydruku;
}

Gdzie tu jakakolwiek konsekwencja? Gdzie jakikolwiek schemat nazewnictwa? Na jakiej podstawie można się zorientować co jest wołane z czego i dlaczego?

W tym samym programie, kawałek obok znajduję np. taki niezwykle sensowy fragment:

this.lista = null;
if (this.lista==null)
 ...

Oczywiście znając historie projektu potrafię sobie dokładnie wytłumaczyć dlaczego ten kod wygląda właśnie tak — to po prostu efekt wielokrotnego „kopiowania z mniej-więcej-dostosowaniem nazw”, podpatrywania rozwiązań zastosowanych przez kolegów w innym, choćby lekko podobnym module i niejednokrotnie bezmyślnego kopiowania całych fragmentów. W efekcie metoda nazywa się tak, jak nazywała się trochę podobna w innym zupełnie miejscu, a jej kod zawiera to, co pozostało po wycięciu chyba-zbędnych fragmentów z innej chyba-podobnej metody.

I czy ktoś się tym przejmuje? Nie. Ponieważ większość zatrudnionych przy tym projekcie programistów nie czuje z nim absolutnie żadnego związku emocjonalnego — każdy jest tutaj tylko na chwilę, tylko po to, żeby „zaczęło działać”, tylko dlatego, że projekt się walił i zassał wszystkich z okolicy. W efekcie nikomu na tym kodzie nie zależy i każdy działa wg asekuracyjnego schematu „syf zastałem, syf zostawiłem”. A że brzydkie to jest jak nieszczęście..? No fakt, brzydkie, powolne i niekonserwowalne, ale ... „przecież to nie moje”.

dygresja - Java śmierdzi bardziej

Java jako platforma potęguje opisane powyżej zjawisko. I nie mówię tego dlatego, że Javy szczerze nienawidzę. Wręcz odwrotnie — nienawidzę jej właśnie dlatego, że potęguje wszelkie negatywne zjawiska jakie mogą wystąpić w projekcie informatycznym.

W projekcie opartym na Javie nie da się efektywnie uczestniczyć z doskoku. Nie da się wejść na chwilę, zrobić coś i zniknąć. To jest zbyt rozbudowane, zbyt pełne niejasnych zależności i (dla praktyka to pewnik) zbyt nieudokumentowane.

Oczywiście mówię tutaj o projektach rzeczywistych — Java jako platforma z punktu widzenia teoretycznych i akademickich rozważań jest świetna i piękna jak maszyna oszałamiająca mnogością błyszczących trybików. Jednak w rzeczywistości te trybiki są zawsze zardzewiałe, w różnych dziwnych miejscach wiązane drutem czy sznurkiem nawet, a wszystko dookoła śmierdzi zjełczałym smarem. Fuj... Jedyne pocieszenie — „to nie moje”. :-/

Komentarze

beanStronyJSP.pobierzListaPismDoWydruku()
--> jakasSmiesznaFasada.getListaOdwolanDlaRaport()
--> klasaKtoraNieWiemPoCoJest.dajListeOdwolanDoRaportu()
--> stadJuzNiedalekoDoEJBBazy