Real Madrid programming czy Real-life programming? Czyli: programista-pisarz a programista-konstruktor
Świat nie jest piłką futbolową, świat się podbija głową, głową, głową.
Antoni Słonimski, Kontr-marsz
Mała informacja dla niezainteresowanych piłką nożną: jest wiele drużyn futbolowych budowanych zgodnie z przemyślaną strategią. Wśród klubów, które tak działają na szczególną uwagę zasługuje Real Madryt- firma, w której tworzenie zespołu to efekt naprawdę wnikliwego planu strategicznego. Szkopuł w tym, że o ile plany, na podstawie których inne kluby budują swe drużyny mają charakter z grubsza merytoryczny, o tyle w Realu kimś ważniejszym niż kolejni trenerzy jest Pan Marketing. Dziś udowodnię, że takie podejście bliskie jest współczesnej inżynierii oprogramowania.
Zacznijmy jednak od tego, że w marketingu nie ma nic złego. Jest to postawa zorientowana na zaspokajanie potrzeb. Problem zaczyna się, gdy całej piramidzie potrzeb uwalamy podstawę, a zaczynamy zajmować się tym co najwygodniejsze do zaspokojenia: potrzebą akceptacji (wybieramy strategię Lepiej Akceptowany Niż Silny znaną pod wymownym skrótem LANS) i potrzebą bepieczeństwa, która sama w sobie jest sensowna i powiązana z instynktem samozachowawczym, ale dla idących na łatwiznę ma tę miłą cechę, że można ją "zagłaskać", o czym doskonale wiedzą politycy. Operując tymi potrzebami można lekceważyć sprawy ważniejsze np. zaspokojenie potrzeby akceptacji można sprzedać lepiej niż zaspokojenie potrzeby jedzenia poprzez eleganckie podawanie byle czego w luksusowo wyglądającej restauracji.
Jeśli nie ma się odpowiednich środków można postępować jak w skeczu Ani Mru Mru powtarzając "Naś klient Naś Pann". Tak na przykład może działać zwulgaryzowane podejście do agile. Szczytem tego podejścia były lekcje flirtu (sic!) dla pracowników IT (http://www.infoq.com/articles/flirting-with-customer) motywowane faktem, że relacja z klientem przypomina uwodzenie.
W tym momencie możemy wrócić do Realu Madryt- otóż w piłce nożnej każdy zawodnik ma swoje miejsce na boisku zależne od jego umiejętności. Jeśli jednak chce się sprzedawać koszulki trzeba wiedzieć, że niektóre pozycje są efektowniejsze od innych i to w nie inwestować. Tak oto dla powierzchownego podejścia do marketingu lekceważy się coś co można nazwać marketingiem realistycznym czyli sprzedawanie dobrego produktu.
Głowny nurt inżynierii oprogramowania nie działa jednak tak jak Real Madryt. On funkcjonuje dużo gorzej! Dlaczego? Profile umiejętności programistów (odpowiednik pozycji na boisku) nie są w ogóle tworzone.
Jak to?- zapyta ktoś. Przecież wymaga się np. doświadczenia w Springu, znajomości MySQLa itp. A i owszem- wymaga się, z tym, że taki wybór porównywalny jest z selekcją graczy do drużyny piłkarskiej na podstawie statystyk z meczów z jej najgroźniejszym przeciwnikiem. Gdzieś na drugim biegunie umieszczane są umiejętności "miękkie", które z kolei można zestawić ze znajomością przez piłkarza języków, którymi posługują się koledzy. Umyka najistotniejsze, czyli podejście do rozwiązywania problemów. Literatura na temat "Typy programistów" niemal nie istnieje oprócz... pewnej recenzji książki "Piękny Kod" (http://helion.pl/ksiazki/szppps.htm), w której napisano, iż... "Są dwa typy programistów: 1. tacy, którzy piszą program, aby działał 2. tacy, którzy piszą program, aby nie tylko działał - mają ku tworzeniu swoją filozofię.". Całkiem blisko, tego co chcę zaproponować, ale jednak dla mnie jest to pewne uproszczenie.
Najzabawniejsze jest to, ze najlepszego podziału koderów na typy dokonali chyba nieświadomie... prawnicy. Dotknął go były znakomity felietonista Software Developer's Journal Filip Dreger pisząc tekst "Jestem zwolennikiem patentów na oprogramowanie". Stwierdził on, że patenty można wprowadzić, ale zamiast ochrony oprogramowania przez analogię do dzieła literackiego.
Skoro są dwa sposoby ochrony, są też co najmniej dwa typy programistów- każdemu z nich można przypisać ulubiony sposób obrony praw.
Tu należy się pewna uwaga: większość programistów plasuje się gdzieś pomiędzy tymi modelami, ale zwykle z dominacją cech jednego z nich.
Paradoksalnie ochrona na zasadach podobnych do dzieła literackiego (od 1974) ukształtowała się, gdy odpowiadający jej rodzaj programisty raczkował. Ten rodzaj programisty narodził się w roku rewolucji seksualnej (1968), gdy Edsger Dijkstra napisał artykuł "A case against go to statement" (http://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD215.html), a następnie słynny list ACM "Go To Statement Considered Harmful". Tak powstała metoda strukturalna a z nim programista-pisarz- model który dziś rozwija się wręcz imponująco. Programista-pisarz wchodzi w bliską relację z językiem programowania, koncentruje się na komunikatywnym zapisie algorytmu. Zwykle jest "language-geekiem", gdyż zwraca uwagę, że często czyta kod, i, że jego kod jest czytany przez innych. Relacja między "pisarzem" a językami programowania przypomina podejście kierowcy wyścigowego lub rajdowego do samochodów- jest to dla niego narzędzie, ale i zabawka. To "pisarzom" zawdzięczamy refaktoring, language-oriented programming, domain-driven programming czy ideę clean code. "Pisarzami" są np. Guido van Rossum, Larry Wall oraz Eric Evans. Dużym, a mniej dostrzeganym atutem pisarzy jest lepsza umiejętność korzystania z bibliotek- występuje u nich czasem nawet przewaga inteligencji werbalnej nad algorytmiczną, co sprawia, że w kontakcie z dokumentacją i interfejsami szybciej wnioskują "co autor miał na myśli".
"Drugą stroną medalu" jest programista-konstruktor. Podobnie jak pisarz niekiedy "wchodzi w swiat" nowego języka ("pisarze" częściej są "kolekcjonerami języków"), ale trakuje go bardziej jako narzędzie czysto użytkowe. "Konstruktor" często szybciej orientuje się w modelowanym procesie, zazwyczaj jest po prostu lepszym algorytmikiem. Łatwiej mu zostać programistą graficznym, gdyż myśli bardziej obrazami niż słowami. Może mieć tendencję do przedwczesnej optymalizacji.Bywa sceptyczny w stosunku do nowych języków i metodologii- niektórzy "konstruktorzy" np. niechętnie przechodzą od C do C++. Reprezentantem tego typu koderów wydaje się Linus Torvalds, który np. stwierdził, że pisanie kernela w C++ byłoby "cholernie głupim pomysłem" czy Miguel de Icaza.
Jeśli zastanowić się nad tym podziałem można dojść do wniosku, że "real-life programming" w opozycji do "Real Madrid programming" oznaczałoby spostrzeżenie jeszcze paru podobnych różnic między koderami i taki dobór programistów do projektów i do poszczególnych zadań, który by takowe różnice uwzględniał. Przykładowo, z wyienionych już wcześniej przyczyn trochę brakuje "pisarzy" w gamedevie, choć ich większa obecność mogłaby się przełożyć na czytelniejsze nawet dla najbardziej typowych "konstruktorów" interfejsy.
Byłoby to jednak bardziej skomplikowane niż uczenie koderów jak uśmiechać się do analityczki.