/ cargo cult

Cargo Cult

Niedługo po zakończeniu drugiej Wojny Światowej na wyspach Oceanu Spokojnego pewna grupka wieśniaków zaczęła budować lotnisko. Nie był to jednak cel żadnego z nich. W rzeczywistości był to dla nich rytuał religijny.

Od dłuższego czasu przyglądali się Amerykanom, którzy mieszkali niedaleko. Amerykanie byli bladzi i ubierali się dziwnie, ale mieli nadprzyrodzone moce, których wszyscy w plemieniu im zazdrościli. Mogli przyzywać metalowe ptaki, które dostarczały skrzynie z jedzeniem. Ich szamani leczyli nawet najstraszniejsze choroby. Zamykali ogień w szklanych kulach i nie bali się zwierząt z dżungli.

Mieli też Pas Lotniczy - miejsce święte, w którym to właśnie bogowie zsyłali im dary. A wszystkie te wspaniałości występowały pod symbolem krzyża. Czerwonego krzyża.

Teraz jednak sytuacja miała się zmienić, bowiem rdzenni mieszkańcy wyspy zebrali już patyki i kamienie. Ich pas lotniczy przyniesie im bogactwo i życie, którego dotąd mogli Amerykanom tylko pozazdrościć. Jeszcze tylko jeden posąg dla krzyża, jeszcze tylko kilka kamieni.

John Frum Cross, Tanna 1967 (from Wikipedia)

Steve McConnell

...napisał jako pierwszy o Cargo Cult Software Engineering. Termin ten zapożyczył z określenia Cargo Cult Science Richarda Feynmana, opublikowanego w książce Surely You’re Joking, Mr. Feynman! (1997).

Określenie te tyczy się organizacji, która próbuje udawać inną organizację, emulując jej metody bez zrozumienia zasad ich działania. Podobnie jak rdzenni mieszkańcy wysp Pacyfiku próbowali naśladować amerykańskie wojska żeby otrzymać zaopatrzenie.

Cargo Cult w świecie IT występuje nie tylko na poziomie organizacji, ale też projektu, a nawet jednostki. W środowisku, w którym ciągła nauka jest wpisana w opis pracy pójście na łatwiznę jest niesamowicie kuszące.

Używamy Angulara, Symfony2, Railsów, Django, a potem przepisujemy do Reacta, Laravela, Hanami i Flaska. Stawiamy infrastrukturę na maszynach wirtualnych i zmieniamy ją na Dockera. Ktoś pisze nowy framework JavaScript co tydzień.

This list is incomplete. Please don't expand it by creating a new JavaScript framework.

Mikrokult

W marcu zeszłego roku byłem prelegentem na lokalnych targach Kariera IT. Miałem okazję pomówić trochę o problemach z implementacją mikroserwisów na podstawie własnych doświadczeń. Wywiązało się z tego kilka ciekawych dyskusji, natomiast nikt nie zapytał dlaczego używamy mikroserwisów.

Miałem oczywiście na to gotową odpowiedź - zależało nam na niezależnych deploymentach i obsłudze downtime'u dla poszczególnych zależności. Po dwóch latach z tą architekturą stwierdzam, że ani jeden, ani drugi powód nie był wart narzutu komunikacyjnego związanego z tworzeniem niezależnych serwisów.

Dobrym powodem, dla którego na przykład Netflix używa mikroserwisów jest fakt, że łatwiej im w ten sposób podzielić pracę na grupy programistów. Powiniennem pomyśleć o tym, kiedy Adam Bien wspomniał, że podział serwisów w jego projektach odpowiadał strukturze organizacji, nie strukturze funkcji aplikacji.

W retrospekcji było to do przewidzenia

Kwestia skali

Jedną z rzeczy, które nauczyłem się o prowadzeniu firmy usługowej, jaką jest Software House jest kruchy balans między zatrudnianiem i przyjmowaniem projektów. Software House pośredniczy pomiędzy programistami i klientami, dodając swoją wartość dla obydwu stron. Bardzo ważne w tym jest, że rynek ten musi być obustronnie zrównoważony żeby funkcjonował. Jeśli nie masz projektu dla programisty, a musisz mu zapłacić - tracisz pieniądze. Jeśli masz klienta, ale nie masz ludzi - sprzedajesz towar, którego nie posiadasz.

Są w tym też ludzie, którzy musza utrzymać samą strukturę. Office Manager, Human Resources, Project Manager. Nie wszyscy z nich są opłacani przez klientów bezpośrednio. I to jest w porządku, wlicza się to w cenę programisty. Natomiast przy małej skali ci właśnie ludzie stanowią sporą część wydatków. W mikrofirmach CEO przejmuje rolę tych ludzi. Ale CEO nie jest ekspertem w tych dziedzinach, a przynajmniej nie we wszystkich jednocześnie.

Duzi gracze mają przewagę. Mogą nieco obrosnąć w tłuszcz organizacyjny, przeżyją też niedoskonałość dopasowania klientów do programistów. Mała firma z ambicjami chce być na tej pozycji. Widzi, że duży gracz ma łatwiej, więc prędzej czy później zatrudni więcej ludzi. Być może programistów, być może testerów. Może także ludzi, za których pracę klient płaci tylko pośrednio. Podniesie stawki dla klientów lub obniży swoją marżę.

Mała firma stanie się (na moment) dużą firmą. Przestanie za to być firmą rentowną.

Złoty projekt

Raz na jakiś czas trafi się projekt, z którego wszyscy są zadowoleni. Być może to kwestia przypadku, być może doboru ludzi. Przychodzi wtedy taka straszna chęć, żeby ten sukces powtórzyć.

Znam firmę, która zmieniła wiodący stack z uwagi na powodzenie projektu, który był dla nich obcy technologicznie. Dwa lata później ta sama firma robiąc bliźniaczy projekt dla zupełnie innego klienta straciła dużo pieniędzy. Projekt był w tej samej technologii, natomiast klient był nie dość, że z innego kraju, to jeszcze źródło finansowania miał inne.

Klonowany flow

Project manager projektu A jest zachwycony automatyzacją w projekcie B.

Projekt B "sam się prowadzi", bo każdy zamknięty pull request powoduje odhaczenie ticketu w JIRA, buduje nową wersję w Continuous Integration, wydaje aplikację iOS dla QA.

Projekt A też ma CI. Też jest w JIRA. Projekt A mógłby być równie zautomatyzowany, ponieważ też jest w JIRA, też ma CI. Ma też staging.

No właśnie - staging. Projekt A jest projektem aplikacji backendowej.

Project manager spędza swoje popołudnie na kopiowaniu ustawień projektu B do projektu A. W poczuciu dobrze wykonanego zadania wraca do domu i czeka na opinie swojego zespołu.

Developer projektu backendowego A przychodzi do pracy i nie do końca wie co ma zrobić. Wszystko wydepowane, ale QA nic nie testują. Pojawiła się nowa kolumna "Deploy to App Store". Tickety trafiają tam, ale nikt nie może ich z tego limbo wyciągnąć.

Problem oczywiście nie jest trudny do rozwiązania i wymaga tylko poprawy komunikacji w zespole. Pokazuje natomiast, że nawet prosty proces przeszczepiony z jednego miejsca w drugie nie musi działać.

Procesy, nawet te najpopularniejsze, nie zawsze są reużywalne.

Batman

Klient Software House'u dla którego kiedyś pracowałem napisał post na LinkedIn w którym opisywał ciekawą metodę delegowania developerów do pomocy obsłudze technicznej i project managerom. Każdego dnia jeden developer mial przy biurku figurkę Batmana. Ten developer (zwany tego dnia Batmanem) był jedyną osobą, której należało tego dnia przerwać pracę, jeśli zaszła jakaś wyższa konieczność.

Screen-Shot-2018-04-02-at-14.12.54

Proste i zabawne rozwiązanie problemu, który napotkał zapewne niejeden zespół.

Jakiś czas później będąc startupem, w którym nacisk na Customer Support jest zdecydowanie większy niż w dużej korporacji cierpieliśmy na notoryczny brak czasu.

Zadania tyczące się pojedyńczych użytkowników spływały stałym strumieniem, a Customer Support był niezadowolony z braku widoczności statusu tych zadań. Dodatkowym problemem był dla nich fakt, że siedzieli w biurze w Londynie, więc komunikacja siłą rzeczy musiała odbywać się asynchronicznie, poprzez Slacka.

Wspomniałem o systemie z Batmanem. Każdego dnia losowaliśmy jednego developera, który zajmował się tylko zadaniami Customer Support. System działał dobrze, chociaż czasami któryś z developerów zapomniał rano napisać, że jest odpowiedzialny tego dnia za pomoc w problemach użytkowników.

Pewnego dnia do Poznańskiego biura przyjchała paczka z Allegro. W środku znajdowało się opakowanie z logo Spider-Man. Wewnątrz był natomiast świecący na czerwono chińskiej produkcji Batman. Team Customer Support już pierwszego dnia odkrył, że pomimo wysiłku z ich biurek nie widać kto w biurze w innym kraju ma danego dnia Batmana na biurku.

Chinese Batman

Scrum

Pewien zespół dostarczał regularnie nowe funkcje. Release był co wtorek, nigdy wcześniej, nigdy później. Wszystko, co nadawało się na produkcję było testowane w poniedziałek, a wtorkowy release był zazwyczaj formalnością. Firma, która ten team zatrudniała miała do niego zaufanie, przetestowane sprawnymi rollbackami gdy coś nie działało.

Pewnego dnia team został podzielony na aplikację webową i aplikację mobilną. Jako świeżo zachłyśnięty Agilem i Scrumem developer zostałem poproszony o próbę stworzenia rozsądnej listy zadań dla aplikacji mobilnej. Przed oczami miałem backlog i sprinty. Zdecydowanie nie miałem tam natomiast Kanbana, chociaż niewiedziawszy o tym pracowałem w nim już ponad rok.

Więc stworzyłem backlog. Backlog, który nie uwzględniał następujących problemów:

  • backend dalej rozwijany jest w Kanbanie
  • wszyscy pracują zdalnie i asynchronicznie
  • sprint czy nie sprint - release jest we wtorek

Jeśli masz w ręku Scrum Mastera wszystko wygląda jak Scrum. Spodziewanej rewolucji jakościowej nie było, a niezadowoleni developerzy nie polubili nowej metodyki.

Aplikacja mobilna nie była na szczęście duża i po całym by-the-book Scrumie zostały jedynie User Stories jako nazwy ticketów na kanbanowej tablicy.

Instynkt

Nie wierzę, że jestem odosobniony w tych obserwacjach. Nie wierzę też, że swiadomość istnienia takiego zjawiska uchroni mnie przed nim w przyszłości.

Pokusa udawania tych, którym się udało jest zbyt duża. Zwierzęca część umysłu przejmuje tutaj stery i często myślimy uczuciami, lub strachem przed byciem pominiętym.

Jeżeli sąsiednia małpa weszła na drzewo i ma banana to ja też wejdę. Pal licho, że to wierzba.