Zapewne widzieliście już prezentację Erika Meijera z Reaktor Dev Day 2014. Prelegent postanowił rozprawić się z całą tą ściemą, jaką jest Agile, a jako jej alternatywę zaprezentował podejście „One Hacker Way” – nieskomplikowane, bo sprowadzającą się prostu do … pisania kodu. Ilu z Was łyknęło tę nowinkę niczym młody pelikan swoją pierwszą sardynkę (rym niezamierzony)? Jeśli to kupiliście, to muszę Was zmartwić – zostaliście zhakowani.

Do rzeczonej prezentacji podszedłem z otwartym umysłem, ponieważ z doświadczenia wiem, jak wiele twarzy ma Agile i jak wiele z nich to de facto maszkarony. Pomyślałem, że przyjemnie będzie poznać doświadczenia kogoś, kto miał styczność z Agile i zna jego mankamenty. Krótko mówiąc – liczyłem na praktyczne studium Agile okraszone merytoryczną krytyką.

Pierwszy dysonans odczułem w momencie, kiedy Erik podjął temat Stand Up-ów, czyli właściwie w pierwszych minutach prezentacji. Przedstawiona na slajdach scenka rodzajowa była dość tendencyjna, równie dobrze można byłoby tych stojących w kręgu ludzi przedstawić za ich komputerami z tymi samymi myślami. I tu i tam nic by nie robili – tak samo marnowaliby czas, choć przed komputerami może nawet i bardziej, bo nie wiedzielibyśmy czym się zajmują – na Stand Up-ie muszą to wyartykułować. Jednak wg Erika to właśnie „gadanie o kodzie” jest stratą czasu, bo przecież ci ludzie powinni pisać w tym czasie kod i umieszczać go regularnie w repozytorium.

Na tej aktywności zresztą Erik oparł całą swoją prelekcję i – nie boję się użyć tutaj tego słowa – manipulację widownią. Zaczął bowiem od pytania: „kto z was umieścił kod w repozytorium w przeciągu ostatniego tygodnia”. Tu mogły być tylko dwie opcje. Albo ktoś się zgłosił, albo nie. To dokonało naturalnej polaryzacji widowni, co było zgodne z zamierzeniem prowadzącego, czyli użyciem starej sprawdzonej metody: rządź i dziel. Ci którzy wrzucili kod do repozytorium zostali skomplementowani i uznani za programistów, pozostali nie byli godni tego miana. Pierwsi stali się z miejsca sojusznikami prelegenta, drudzy za punkt honoru wzięli sobie udowodnienie, że są programistami i przez całą prelekcję starali się utwierdzić w tym przekonaniu, nieświadomie przyswajając przekaz prelegenta.

Skoro już prawda objawiona została … objawiona, pozostało tylko pozostałą część prelekcji oprzeć na niej – nie podlega ona bowiem dyskusji i wszystko co jest z nią zgodne – ma sens i jest właściwym rozwiązaniem.

Wracając do Stand Up-u. Padło oskarżenie, że każdy z programistów ma do dyspozycji 10 minut, czyli dla 6 osób na takie spotkanie zejdzie godzina. Padło też pytanie dlaczego nie 7 albo 5 minut? Skąd tak arbitralny czas, gdzie dowód, że jest to optymalne? Bo – co istotne – każda metoda (w tym i te z rodziny Agile) powinna być weryfikowalna, tak jak teoria naukowa. Nie ma dowodów – teoria naukowa idzie do kosza. Rzecz w tym, że Stand Up może trwać krócej, każda wypowiedź może zająć max minutę, więc po 6 minutach wrócimy do upragnionego programowania. Owe „mityczne” 10 minut to po prostu wskazówka, aby nie dopuszczać do gadulstwa. Tu nie są potrzebne dowody, Stand Up służy jedynie do zorientowania zespołu w programistycznej czasoprzestrzeni. Udrażnia (wśród introwertyków – jak określa programistów także Meijer) kanał komunikacji. Dzięki temu nikt nie odpłynie na rozległe wody programistycznego rozpasania pisząc mnóstwo czadowego, solidnego, nikomu niepotrzebnego kodu. Jednakże dla Erika rozmawianie o kodzie jest złe, kod powinien być wyłącznie pisany (czy intuicja nie mówi Wam, że to zbyt duże uproszczenie).

Od Erika dostało się też Planing pokerowi, zestawił go on złośliwie z postacią Jamesa Bonda. Niestety w całej prezentacji nie pada żadna alternatywa, jeśli chodzi o oszacowanie kosztów produkcji programowania.

Następnie prelegent porusza kwestię samo organizujących się zespołów w Agile. Wg niego i tak te zespoły są pod „subtelną” kontrolą kadry zarządzającej. Nie bardzo widzę w czym owa kontrola miałaby przeszkadzać w samoorganizacji zespołu, bo i tak zazwyczaj w takim zespole jest jakiś lider lub kilku liderów, którzy wyłaniają się w zależności od zagadnienia, jakim się ten zespół zajmuje i na ten czas „przejmują władzę”. Tu dobrym wyjściem byłby jakiś konkretny przykład, co też prelegent ma na myśli.

W tym kontekście Erik zadaje pytanie „dlaczego Agile działa?”. Odpowiedzią okazuje się być – struktura zarządzania zbudowana na kształt piramidy. Zapamiętajcie ten argument, za jakiś czas się on przyda.

Na tym etapie prelekcji przychodzi czas na wzmocnienie przekazu. A nic tak nie przekonuje ludzi jak autorytet. I Erik po taki autorytet sięga. Jest nim Bertrand Meyer, nie byle kto w programistycznym świecie. Otóż napisał on książkę „Agile! – The Good, the Hype and the Ugly”. Proszę – on też uważa, że Agile to zło. Rzecz w tym, iż już po tytule widać, że książka widzi też dobre strony Agile. Podejrzewam osobiście, że jest dość merytorycznym studium Agile (co z kolei trudno powiedzieć o prezentacji) i warto będzie ją przeczytać.
Ponieważ jeden autorytet to za mało, poza tym do młodych ludzi bardziej przemawia autorytet w ich wieku (i pomimo tego młodego wieku już z wielkim sukcesem), więc Erik podrzuca jeszcze Marka Zuckerberga. Ten autorytet z kolei ma nie tyle świadczyć na niekorzyść Agile, co na korzyść jego alternatywy – podejścia Hacker Way.

W tym momencie dowiadujemy się czym to podejście jest. Oczywiście najlepiej gdyby udało nam się zawitać do Silicon Valey do siedziby FaceBooka i zobaczyć jak oni tam wszyscy są przesiąknięci hakerskim duchem, wtedy od razu zrozumielibyśmy, że to podejście jest podejściem jedynym, słusznym i doskonałym. A na czym ono polega? Otóż hakerzy zawsze uważają, że coś można zrobić lepiej i że nic nigdy nie jest skończone (zrobione do końca), hołdują zasadzie „zrób to lepiej niż perfekcyjnie”. W tym podejściu istotny jest też tzw. duch hakerstwa, który mówi, że to kod zawsze wygrywa. Bo tylko najlepsza idea i implementacja powinna zawsze wygrywać, decyzji nie należy natomiast podejmować, bo ktoś ma dar przekonywania albo osoba decyzyjna wydała takie polecenie.

Ciekawe, że po przestawieniu na czym polega podejście Hacker Way, Erik twierdzi, że to o czym zapomina Agile, to po co piszemy programy. A piszemy je żeby robić biznes, żeby zarobić. Dostrzegacie tu sprzeczność? Skoro wg Hacker Way, oprogramowanie nie jest nigdy skończone, to nie istnieje moment, w którym można na nim zarobić. Przecież nie sprzedamy nieskończonego oprogramowania.

Teraz przychodzi moment na najbardziej odjechaną część prelekcji. Jest o matematyce, układach sterowania ze sprzężeniem zwrotnym, o sieciach neuronowych, podawane są przykłady mające być jakimiś analogiami (np. system przewozów osobowych Uber). Konkluzją jest stwierdzenie, że oprogramowanie jest wszędzie (możesz sobie np. wydrukować nerkę na drukarce 3D), a Office był kiedyś dobrym produktem, dopóki był brany pod uwagę odzew od odbiorców. Wstęga pojawiła się w nim w momencie, kiedy przestano słuchać klientów. To samo dotyczy kafelków w Windows 8. Wygląda na to, że Erik chce pokazać tutaj, że Agile nie bierze pod uwagę, tego co mówią klienci, co jest dziwne, bo jest to jeden z punktów jego manifestu. Oczywiście – jak wspomniałem na wstępie – Agile jest często wypaczane, więc może taką wersję ma Erik na myśli.

Po tych dywagacjach trafiamy na prawdziwą perełkę, Erik stwierdza, że oprogramowanie nigdy się nie psuje (naprawdę nikomu nie zapala się tu czerwona lampka zdziwienia?), w przeciwieństwie do sprzętu. Dlatego podejście TDD jest bez sensu (sic!). Bo przecież nie jesteśmy w stanie przewidzieć błędów, prawdziwe błędy pojawiają się na produkcji, dlatego należy dawać kod od razu na produkcję i jeśli coś się zepsuje, to przywrócić wcześniejszą wersję i poprawić napotkanie błędy. Nie wiem jak Wam, ale mnie w umyśle świeci się (i mruga alarmująco) rząd czerwonych lampek. Już pomijam fakt, że przekazana na produkcję wersją może być wersją pierwszą, więc nie mamy wersji wcześniejszej. Wyobrażacie sobie Microsoft, który wypuszcza tak swoje produkty (o nie działa Windows 10? proszę na powrót zainstalować Win 8).

Oddzielnym tematem jest kwestia potraktowania przez Erika podejścia TDD. Ono nie polega na pisaniu kodu, który ma udawać błędy. Ono polega na pisaniu kodu, który określa prawidłowy scenariusz wykonania, aby każdorazowo można było sprawdzić, czy zmieniany kod (nawet w myśl Hacker Way – nic nigdy nie jest skończone i można to zrobić lepiej) nadal działa zgodnie z oczekiwaniami (a nie zamiast „lepiej”, działa „gorzej”). Wg Erika pisanie testów to strata czasu – jeśli traktuje je tak, jak opisuje – to ja się z nim zgadzam, wówczas rzeczywiście TDD jest dla cipek i po prostu trzeba napierać z tym jebanym kodem.

Po tych gotujących krew w żyłach rewelacjach przychodzi czas na uporządkowanie świata. A porządkuje je OSI – czyli architektura wielowarstwowa, gdzie każda warstwa komunikuje się jedynie z tą poniżej i nic więcej. Bo warstwy są dobre. Przyznaje, że czekałem teraz na stwierdzenie, że warstwy ma przecież cebula i ogry – czyż potrzeba więcej argumentów? Któż nie uwielbia Shreka?
Na szczęście na poparcie dobrostanu warstw są lepsze argumenty. Ot chociażby architekturę warstwową ma instytucja z dwutysięczną tradycją – Kościół. Za mało? Jeszcze starsza instytucja – wojsko (i tu na slajdzie widzimy Gerarda Butlera w roli Leonidasa w filmie „300”). Co ważne – obie te instytucje mają hierarchię. Papież lub generał na górze. Potem kolejne stopnie hierarchii lub dowodzenia. Pamiętacie jak powyżej kazałem wam zachować w pamięci, jak skonstruowane jest Agile. Tę piramidę. A co my tu właściwie rozpatrujemy, jak nie piramidę? To w końcu to jest zła architektura czy dobra?

Ale porzućmy banalne wątpliwości, bo oto czeka na nas kolejna odkrywcza myśl – wojsko, a co za tym idzie – walka, to domena ludzi młodych. Tak samo z programowaniem – powinno być tak, że programiści pomiędzy 22 a 32 rokiem życia tylko naparzają kod (analogicznie jak piłkarze, którzy w tym wieku grają). Powinni o nim śnić, jeść go, pić. Zawsze i wszędzie ma ich zajmować wyłącznie kod. A to oznacza, że powinni zarabiać tyle co piłkarze (jedzie to populizmem na milę). Szczególnie, że programiści są przecież o wiele inteligentniejsi niż taki Messi i bardziej utalentowani, a zarabiają tak drastycznie mało. Przez 10 lat powinni zarobić tyle ile trzeba i przejść na emeryturę (populizm, populizm i jeszcze raz populizm).

Tu dowiadujemy się kolejnej ciekawostki na temat sztuki programowania. Otóż jest ono jak jazz, trzeba jedynie zdefiniować kontekst, tak jak podaje się motyw w jazzie i wszystko staje się jasne. Menadżerowie nie mają ustalać, jak ma być pisane oprogramowanie, mają wyznaczyć cel. Jak dowódca w wojsku. To praktycznie sprowadza się (tak mniemam) do powiedzenia „macie napisać takie oprogramowanie jak Twitter” albo „macie napisać komunikator” (dokładnie tak samo jak wydaje się rozkaz „macie zdobyć ten budynek”). Nieważne jak (tak jak nieważne czy wybijecie wszystkich do nogi w celu zdobycia budynku). I to jest tajemnica samoorganizującego się zespołu. Menadżerowie nie są mu potrzebni.

Prawda, że proste? To teraz wyobraźcie sobie oddział, który dostaje taki rozkaz i rusza do ataku bez żadnej koordynacji działań poszczególnych żołnierzy. Kto uważa, że atak się uda?

Jak zatem Erik widzi realizację One Hacker Way? Otóż potrzebna jest mała struktura hierarchiczna – 3 poziomy, na dole programiści, którzy dostają kupę kasy, więc są szczęśliwi, więc kodują. Potem kilku menadżerów, po jednym na zespół, którzy tylko wyznaczają cel temu zespołowi (jak podałem wyżej). Na górze jest Strateg, który określa, co firma będzie pisała, ponieważ wie co się pisać opłaca. Oto cała filozofia. Hm, czy Erik nie opisał właśnie zwinnych zespołów (pierwsze dwie warstwy)?

Na koniec Erik ma kilka ważkich rad dla programistów. I tak jak przez całą prezentację niespecjalnie się z nim zgadzałem, tak tutaj zgadzam się w całej rozciągłości. Otóż programiści powinni pracować nad swoimi umiejętnościami społecznościowymi, nie powinni być tak introwertyczni, muszą się otworzyć na otoczenie, bo inaczej nikt nie będzie chciał mieć z nimi nic do czynienia – ergo nie znajdą chętnych na swoje usługi. Implikuje to też takie umiejętności, jak ładne ubieranie się i przede wszystkim (o tak, podpisuję się pod tym wszystkimi kończynami) dbanie o higienę osobistą. Tu Erik ponownie przywołuje przykład piłkarzy, którzy bardzo umiejętnie dbają o przychylność swoich kibiców (w końcu to pieniądze z ich biletów wchodzą w część ich wynagrodzenia).
Kolejną dobrą radą Erika jest, aby programiści nie walczyli ze sobą, nie torpedowali cudzych pomysłów w imię zasady, co ty wiesz o programowaniu, ale by oceniali pomysł merytorycznie (zgodnie z hakerskim duchem).
Erik twierdzi także, że jesteśmy za tani. I że chcemy softu za darmo. A to jest samobójstwo i kanibalizm. Jak mamy zarabiać kapustę, skoro mówimy, że nasza robota jest nic nie warta, bo jest za darmo. Ma to jakiś sens, ale trochę pachnie mi korporacjami branżowymi, tylko czekać aż powstaną i zaczną weryfikować, czy absolwenci uczelni nadają się na programistów.

Kiedy zakończyłem oglądanie wystąpienia Erika Meijera zacząłem się zastanawiać co miała ona na celu? Czy Erik odreagowywał lata spędzone w Microsoft, gdzie poszczególne działy walczyły ze sobą? Czy to skrzywiłoby tak bardzo jego perspektywę? A może po prostu zakpił sobie z widowni, chciał jej pokazać jak potrafią być bezrefleksyjni. Po prostu ich zhakował. Bo przecież w swojej prezentacji serwował oczywiste bzdury i używał tych samych argumentów raz za, a raz przeciw.

A może – tak jak sugeruje Robert C. Martin to wszystko było żartem, prelekcją dla tzw. „beki”? Nie wiem, ale z pewnością ta prelekcja uczy jednego – nie wyłączajcie myślenia, niezależnie od osoby prelegenta. Musicie być czujni, bo zostaniecie zhakowani.