geekyprimitives

Niniejszy wpis jest projekcją moich doświadczeń, przemyśleń i jako taki ma jedynie na celu udowodnienie moich racji, które w innym kontekście mogą kompletnie przeczyć zdrowemu rozsądkowi. Jest też poniższy wpis w swym założeniu ciętą ripostą, zbiorem celnych uwag i głosem wołającym o całościowe spojrzenie na produkcję oprogramowania. Jego celem nie jest przekonanie kogokolwiek, ani też ewangelizacja czy też rozpoczęcie krucjaty przeciwko “innowiercom”. W swym życiu osiągnąłem etap, gdy nie jest w kręgu mych zainteresowań przekonywanie kogokolwiek, lecz sama dyskusja, budowanie pokrętnych analogii, unikanie pułapek semantycznych oraz zabawa słowem i myślą.

Nie powiem żebym zbytnio ostatnio przykładał należną uwagę do mojego bloga. W związku z tym, że większość moich wpisów czyta rodzina, znajomi i opłacani poplecznicy, temperatura komentarzy jest nijaka, wszyscy się ze sobą zgadzają, kontrowersji jak na lekarstwo. Jednym słowem nuda.Jakież było moje zdziwienie, gdy po zalogowaniu zobaczyłem kilka komentarzy do “Slow coding” i “Tezy i twierdzenia”. Poczułem przyjemne podniecenie, gdyż adwersarz nie zgadzał się z poglądami zawartymi w tych wpisach. W jednym z nich posądził mnie o herezje i być może nawet w głębi duszy ekskomunikował. To tylko wzmogło mój apetyt na więcej. Z wypiekami na twarzy podążałem po krętych korytarzach sieci, które to zaprowadziły mnie do “Sprawna Inżynieria Oprogramowania: Ekstremalna obiektowość” oraz “Czego moglibyśmy się nauczyć od naukowców?”. Tu moja cierpliwość została wynagrodzona, a znaleziona pożywka dla szarych komórek zaspokoiła rozbudzony apetyt. Jako osoba posądzona o herezję z hardością wypisaną na twarzy, postanowiłem trwać przy mej teorii iż to jednak Ziemia krąży wokół Słońca, co zostało już dawno potwierdzone naukowymi metodami.

Po dogłębnym zapoznaniu się z pracami autora dzielę się moimi przemyśleniami i czekam na równie ciętą ripostę. Mam nadzieję tylko, że dyskusja nie sięgnie bruku.Mój oponent zadał sobie trud rozbicia mojego artykułu na czynniki pierwsze, z precyzją przynależną jego profesji. Ja też spróbuję się odnieść się do najciekawszych myśli zawartych w komentowanym artykule.

Pierwsze zdanie, które wzbudziło we mnie poczucie wewnętrznej sprzeczności, cytuję poniżej.

“Bo jeżeli rozumiem programistów, że lubią się bawić na koszt klienta, to nie rozumiem dlaczego od razu chcą latać na prototypach samolotów, gorzej, nie chcą czekać na projekt i te śmieszne rysunki techniczne. Dlaczego inżynier mechanik chce zajmować się projektowaniem tego jak ma wyglądać i latać samolot skoro jego rola i kompetencje to konstruowanie a nie np. badanie satysfakcji klienta z lotu na wygodnym fotelu”

Rozumiem, że autora mogą denerwować zabawy programistów kosztem klientów. Czym jednak można nazwać pracę architektów i analityków (których pieszczotliwie nazywam “modelarzami”)? Dla mnie model, diagram, rysunek nie jest niczym innym jak pustą obietnicą zrealizowania wymagań klienta.Droga od tego modelu do działającego systemu wiedzie przez wyboiste i kręte drogi, a dostarczony system po “reverse engeeneringu” kodu z powrotem do UML nie ma nic wspólnego z początkowym projektem. Model jest obietnicą bez pokrycia, tak jak bez pokrycia były derywaty tworzone przez spekulantów na rynku amerykańskim dzień przed wielkim kryzysem finansowym z 2008. Klient dostaje taki model, który jest poprawny i kompletny, i za który zapłacił grube pieniądze. Akceptuje projekt, wypłaca następną transzę i po kilku miesiącach dostaje beznadziejny produkt. Można tutaj zatrzymać się na chwilę i po chwili znaleźć winnego. To programiści źle zinterpretowali co twórcy modelu mieli na myśli? A może model niejednoznacznie przekazał intencje jego autorów? Odpowiedź na to pytanie pozostawiam Wam drodzy Czytelnicy. Ja lubię odwoływać się w tym momencie do Biblii (sic!). Jak wiemy tworzona była w różnych językach i narzeczach, następnie przetłumaczona na grekę i później na łacinę. Jeśli przyjrzymy się jej wersji w języku polskim tłumaczonym z greki i łaciny, dostaniemy dwa dokumenty, które różnią się w kilku kluczowych fragmentach, a których interpretacja przez biblistów wywołuje gorące dyskusje i kontrowersje. Dla mnie droga od modelu do działającego systemu jest niczym innym jak translacją, procesem w którym giną szczegóły stanowiące o kompletności systemu.

Co do analogii do samolotów, która jest mi szczególnie bliska ze względu na moją obecną firmę chciałbym zauważyć, że zanim pierwszy samolot braci Wright wzbił się w powietrze, historia lotnictwa pamięta cała masę prototypów, które upadły nisko, zanim kolejny z nich wzbił się w powietrze, przelatując niewiarygodny dystans 39 metrów. Mimo tego, że być może model na papierze spełniał prawa fizyki i matematyki, ciągle poruszał się w obszarze domysłów i pobożnych życzeń. W jednej z prezentacji Dan North kiedyś zwrócił uwagę, że to nie rzeczy które wiemy decydują o sukcesie aplikacji lecz rzeczy o których nie wiemy, a co za tym idzie nie jesteśmy w stanie się do nich przygotować odpowiednio wcześnie.Cała sztuka polega na poznaniu rzeczy o których nie wiemy (dzięki @szimano za pchnięcie mych myśli w tę stronę).

W kolejnym paragrafie (i też w jednym z komentarzy) odnajdujemy taką oto myśl:

“Ja zapytam: opracowanie i przetestowanie mapy prostego procesu, potem przypadku użycia, kawałka modelu dziedziny i testowanie tego diagramem sekwencji to praca dla mnie, jednej osoby, na kartce papieru, koszt to jakieś np. 1000zł” 

Jako, że zostałem pochwalony za odwołanie się do Wikipedii, tym razem też zabłysnę i odwołam się do definicji słowa model:

“model – system założeń, pojęć i zależności między nimi pozwalający opisać (zamodelować) w przybliżony sposób jakiś aspekt rzeczywistości.”

Nie wiem czy wyczuliście w tej definicji pewną “miękkość”. Słowa “założenia” i “przybliżony” kryją w sobie niepewność. “Założenia” sugerują iż zarówno klient jak i analityk poruszają się w tym samym kontekście. Problem w tym, że kontekst w obecnym e-świecie zmienia się z sekundy na sekundę, a analityk rzadko ma na tyle czasu, aby poznać klienta i jego środowisko. Przypomina to gonienie króliczka. Co powiedziałby klient, gdyby programista zakomunikował mu iż dostarczony system “przy pewnych założeniach w przybliżeniu spełnia jego oczekiwania”?

Jestem też ogromnie ciekaw jak wygląda testowanie diagramów i modeli UML? Przyznaję, że w tym obszarze jestem kompletnym ignorantem i być może przespałem któreś spotkanie w firmie.

I już ostatni cytat:

“Podejrzewam, że autor po prostu miał tego pecha, że dostawał jakieś kiepskie analizy i projekty, bełkot, którego niestety jest masa”

Jestem ciekaw co stoi za masą “kiepskich analiz” i “bełkotu”? Moim zdaniem dwie proste przyczyny.Pierwsza to niejednoznaczność modeli do modelowania (czytaj meta-języków). Przy pomocy “przybliżonego opisu” opisujemy “przybliżony aspekt rzeczywistości”. Druga przyczyna to testowanie modelu. Ale tutaj oddaje się całkiem w ręce mego adwersarza i czekam na promyk nadziei. Skoro mój oponent potrzebuje kartki papieru i 1000zł na przetestowanie, to dlaczego dostaję taką ilość “bełkotu”?

A teraz czas na ostateczną konkluzję.

Moim zdaniem osoba, która zajmuje się poważnie analizą biznesową powinna wykazać się zrozumieniem tekstu czytanego na poziomie większym niż przeciętna “inteligentna maszyna do pisania”. W moim tekście z którym polemikę podjął autor “Czego moglibyśmy się nauczyć od naukowców?” zabrakło właśnie tego podstawowego zrozumienia.

Klucz do mojego tekstu jak w każdym porządnym dziele z gatunku “filozofii na własny użytek” kryje się na końcu. W zdaniu, które samotnie na końcu wpisu czeka na przeczytanie i zastanowienie się nad jego sensem. Żeby ułatwić życie czytelnika dokonam samobójstwa jako autor, czyli zacytuję sam siebie, jeśli chcecie możecie to nazwać “literackim narcyzmem”.

“Jesteśmy więc naukowcami? Myślę, że nie ma na to jednoznacznej odpowiedzi. Myślę, że tak jak socjo- i psychologowie opracowali profile osobowości, tak śmiało możemy założyć że istnieją określone profile programistów, mamy więc programistów-artystów, programistów-rzemieślników, programistów-ogrodników, teoretyków i naukowców (eksperymentatorów). Każdy z nich ma swoje cele, dla innych to piękny kod, dla drugi to zadowolony klient. … Ważne jest abyśmy my sami, nasi szefowie oraz pracodawcy mieli świadomość tych różnic, i możliwości jakie one nam dają. Abyśmy tworzyli zespoły dobierając programistów o różnych osobowościach, aby uzupełniali się nawzajem. Postarajmy się w zespole o chociaż jednego artystę i naukowca, niekoniecznie pracujących nad krytycznymi elementami systemu ale dbającego o piękno kodu czy też odkrywającego nowe horyzonty”

Uważam, że kluczem do sukcesu jest dobranie odpowiednich narzędzi i programistów do problemu i kontekstu w którym go przyszło nam rozwiązać. Nie jest moim celem zmiana produkcji oprogramowania w jedno wielkie laboratorium, w którym powstają groźne, genetycznie zmodyfikowane twory naszej wyobraźni. Oczekuję tylko, aby architekci i analitycy byli bardziej otwarci na współpracę i potrafili wykorzystać inne metody badania rzeczywistości niż pastwienie się nad kwadracikami, strzałkami i kółeczkami. Oczekuję tylko od nich bardziej krytycznego spojrzenia na swój warsztat, na wyjście poza ramy swoich kompetencji, tak jak w mojej firmie oczekuje się aby programiści zrozumieli biznes, tak jak oczekuję, aby architekci i analitycy zrozumieli poza-biznesowy kontekst aplikacji które projektują. Aby poznali technologiczne ograniczenia w których przyszło im pracować i modelować rzeczywistość. Wiem, że to brzmi brutalnie ale jesteśmy ograniczeni przez technologie, przez to że nie znamy tego czego nie znamy. I gdy testowany diagram sekwencji w kontekście ołówka i papieru nie wytrzymuje zderzenia z rzeczywistością tysięcy zapytań na sekundę, przy ograniczonej, skończonej, przepustowości sieci nie wińmy programistów. Bo łatwo jest umyć ręce od odpowiedzialności, jednak ja wierzę w tzw. “ownership” i jednakową odpowiedzialność za dostarczony produkt na każdym poziomie drabiny produkcji oprogramowania.