Szymon Warda: Zaczynamy? Zaczynamy. Zaczynamy. Zaczynamy. Dobra, dobra. To dzień dobry, dzień dobry.

Łukasz Kałużny: Cześć Szymonie.

Szymon Warda: Cześć Łukaszu. Co tam u Ciebie? Co się działo?

Łukasz Kałużny: Jesteśmy po warsztatach Kubernetesowych.

Szymon Warda: Słyszałem.

Łukasz Kałużny: Tak, dla 50 osób, więc wyszło. Kolejne 600 w kolejce, które chciałoby na nie przyjść, to będzie dla nas problemem. Zobaczymy co z tego rozwiniemy.

Szymon Warda: Rozumiem, że kolejkę obsługujecie batchowo?

Łukasz Kałużny: Tak?, batchowo. Pierwsze nie, nie batchowo, było losowo. Było kto pierwszy ten lepszy w części, potem batchowo wylosowani i batchowo wylosowani, którzy wypełnili ankiety.

Szymon Warda: O, to nieźle faktycznie. Czyli kolejka z filtracją.

Łukasz Kałużny: Tak, kolejka z filtracją, bądź fifą w niektórych przypadkach.

Szymon Warda: No to ładnie faktycznie. Coś jeszcze tam się działo u Ciebie ciekawego?

Łukasz Kałużny: Wiesz co, bawię się teraz Raspberry Pi, ponieważ wreszcie do mnie doszła po czterech tygodniach od zamówienia około.

Szymon Warda: Długo.

Łukasz Kałużny: Długo. Nowy model i ten, który mi się podobał, czyli też większości, bo Raspberry Pi dostało wreszcie 4 GB RAM-u. Czyli nie jest już aż taką zabawką. Pomyślany jest pod parę innych rzeczy, np. ma 2 wyjścia HDMI teraz.

Szymon Warda: To dużo. Nieźle.

Łukasz Kałużny: Tak, 2 wyjścia HDMI, więc pomyśleli troszeczkę o innych zastosowaniach jego. A ja odpalam na tym w domu Kubernetesa w wersji mini, o dziwo. Jest sobie taki projekt od Ranchera, nazywa się K3S i wycięli tam większość problemów Kubernetesa, kiedy chcieliśmy mieć coś małego. Bo jest to po prostu Kubernetes w postaci jednej binarki z SQL Lightem i nie trzeba się bawić w cały deployment. Czyli zamiast 4, 5 binarek, całej zabawy z configiem mamy jeden skrypt: zainstaluj mnie tutaj, Kubernetesa i go odpal i tyle. I został przewidziany właśnie do takich zabaw, profesjonalne zastosowanie z ARM-ami, z prockami ARM-owymi, czy z drugiej strony właśnie IoT Edge, zabawy z IoT Edge czy CI/CD, żeby na przykład zrobić testy aplikacji bez wywalania jej na klockach, czyli testy integracyjne zamknięte na agencie build’owym, bez dotykania nawet reszty.

Szymon Warda: Czyli w skrócie będziesz za pomocą Kubernetesa migał diodą.

Łukasz Kałużny: I mierzył temperaturę i migał odświeżaczami powietrza w domu.

Szymon Warda: Tak, to ok, dobra, ciekawie, ciekawie, ciekawie.

Łukasz Kałużny: A u Ciebie?

Szymon Warda: U mnie, jeżeli mówimy o zabawkach, ja zdecydowałem się w końcu na zakupienie konsoli i kupiłem Nintendo Switcha. I mimo, że kupiłem go dwa dni przed ogłoszeniem nowej wersji, to jestem happy z tym zakupem. Super zabawa z dzieciakami. Jeszcze do tego kupiliśmy zestaw Nintendo Labo, czyli Nintendo sprzedające zestaw kartonu za kilka stówek i do montażu. Mimo, że jest od wieku 7 lat, 4,5 letnia córka poradziła sobie z montowaniem. Zabawa fenomenalna. Super! Polecam naprawdę bardzo mocno. A tak to ubiłem laptopa kolejnego, ThinkPada. Kolejny też to będzie Thinkpad. Więc do przodu. A co tam w ogóle czytałeś?

Łukasz Kałużny: Wiesz co? I teraz zamiast linków książka, którą dorwałem ostatnio. Jest sobie nowa, fajna. Nazywa się “Człowiek vs komputer” od Gojko Adzic. Chyba dobrze czytam. I opowiada historię fackupów w IT. Z takiej perspektywy, takim prostym językiem tłumacząc co się stało. Więc możemy przeczytać na jednej stronie o fuckupach Azura z certyfikatami z 2013 roku.

Szymon Warda: Pamiętamy.

Łukasz Kałużny: Pamiętamy i parę innych. I wychodzi na to, że co dwie strony to nowy fuckup. Więc przy gdzieś, bo mam ją teraz w ręku, jest dość krótka, więc ma jakieś 240 stron, czyli daje to jakieś około 400, 500 różnych zabawnych fuckupów. Takich jak na przykład gościu w Stanach kupił sobie w Kaliforni samochód i zarejestrował go z customową tablicą, no plate. Okazuje się, że w kalifornijskim prawie była luka, że można było przez kilka miesięcy jeździć bez tablic.

Szymon Warda: Chyba wiem do czego to zmierza.

Łukasz Kałużny: I w systemie nie było checkboxu “no plate”, więc policjanci wpisywali za każdym razem no plate przy mandatach, jak były bez tablic. I gościu dostawał mandaty za parkowanie, przekroczenia prędkości i inne takie rzeczy. I teraz ciekawostka. Steve Jobs właśnie korzystał, żeby być anonimowy, co parę miesięcy zmieniał samochód.

Szymon Warda: Taki sam problem był jak Polacy zaczęli wyjeżdżać do Wielkiej Brytanii.

Łukasz Kałużny: Irlandii.

Szymon Warda: Irlandii. Tak. I dostając mandaty policja wpisywała dowód osobisty.

Łukasz Kałużny: I prawo jazdy.

Szymon Warda: I prawo jazdy. Tak, dokładnie. Więc no takie fuckupy się zdarzają dość nieźle.

Łukasz Kałużny: Tak, jest to ciekawe. Druga rzecz, która miała jakąś chwilową burzę ostatnio w internecie, jest 10x engineering. Zaczęło się od tweeta.

Szymon Warda: Tak, od serii tweetów.

Łukasz Kałużny: Serii tweetów, tak. Widzę też czytałeś. No i gościu wychwalał w niebo takie podejście, kiedy gościu jest takim 10-krotnym inżynierem i wszystko bierze na klatę, zapominając o tym, że mamy też bazę jednego inżyniera, który też powinien być poprawny i dobry.

Szymon Warda: Tak, on jeszcze nawet takie strasznie archaiczne rzeczy wyciągał typu stworzył obraz człowieka, który się nie komunikuje z nikim innym, klepie w klawiaturę, ma słuchawki i komunikacja z nim jest zerowa niemalże.

Łukasz Kałużny: Tak, budowanie. No i też było to ciekawe, że to jest idealna rzecz na początku w startupie rzekomo jeżeli masz nowy projekt, startup. Gdzieś po części może bym się zgodził, bo to na pewno przyspieszy zbudowanie MVP i innych rzeczy, tylko potem z mojej perspektywy jest to nie utrzymywalne.

Szymon Warda: To jak nie utrzymywalne, to jest w ogóle ryzyko dla całej firmy.

Łukasz Kałużny: Ryzyko, tak, bo gościu wpadnie przysłowiowo pod tramwaj, czy w firmie, gdzie kiedyś razem pracowaliśmy, admin kiedyś nie wrócił z łódek.

Szymon Warda: Tak, zdarzyło się, smutne wydarzenie, ale tak.

Łukasz Kałużny: Ale takie rzeczy się dzieją.

Szymon Warda: Dzieją się. Ale z bardziej życiowych, to jest człowiek, który generalnie w pewnym momencie sobie uświadomi swoją wartość i powie dajcie mi pensję razy dziesięć. Takie sytuacje widziałem. No i część firm potem mówi: nie mam innego wyjścia.

Łukasz Kałużny: Albo drugie wyjście: ja chcę klepać teraz coś innego i cała firma ma to robić. W szczególności przy mniejszych projektach.

Szymon Warda: I widziałem jeszcze jedną sytuację, gdzie po prostu taki właśnie pojedynczy programista powiedział: mnie teraz interesuje coś innego, więc ja się zajmę tym. A że to nie jest naszym biznesem? Trudno się mówi, radźcie sobie. On dalej pracował w tej firmie, ale zupełnie co innego zaczął robić.

Łukasz Kałużny: Czyli tak, zdarza się. Więc dość ciekawe dyskusje, polecam sobie poczytać komentarze jeszcze bardziej, bo pojawiły się One Engineer Manifesto, który jest odzwierciedleniem osób, które gdzieś się komunikują i pracują zespołowo. A Ty co czytałeś ciekawego?

Szymon Warda: Ja czytałem ostatni news, który mi wleciał, który jakbym na niego spojrzał parę lat temu, to pomyślałbym: a śmieszne, ale teraz mnie przeraziło. Wyszedł raport niedawno, że 1/3 firm używa jeszcze Windowsów XP. I czemu mnie to przeraziło? Bo jak patrzymy na wycieki danych, to patrząc na ten problem naiwnie, to jest: a firmy używają starych Windowsów. Ale każdy z tych komputerów to jest po prostu otwarta furtka do naszych danych osobowych, ogromnych zbiorów naszych danych osobowych. A patrząc na fuckupy swoją drogą, o których mówiłeś, to te dane osobowe są przerażające i to, co się będzie działo z naszą prywatnością, naszymi danymi, to jest przerażające wręcz tak naprawdę.

Łukasz Kałużny: I pomyśl, że siódemka za parę miesięcy wychodzi ze wsparcia, w styczniu.

Szymon Warda: Dziesiątka wyszła, pierwsza wersja, z pierwszej linii wsparcia.

Łukasz Kałużny: Tak, tylko to jest krótkie, ale z długich już dziesiątka wychodzi, z takiego normalnego, siódemka wychodzi z normalnego mainstreamu.

Szymon Warda: Tak, ale co jest ciekawsze, to, że sam Microsoft przeszedł na ten tryb generalnie, że ten czas wsparcia jest dużo krótszy, że firmy muszą się upgrade’ować. Tak patrząc na problemy, które mamy obecnie, dalecy jesteśmy od tego, żeby upgrade’ować, a musimy patrzeć na korporacje i na te wszystkie wielkie firmy, które dane trzymają jako wejście. Przerażające. Mnie to naprawdę przeraziło. Po raz pierwszy w ten sposób zareagowałem na takie niby trochę zabawne wieści. Tak że to. Z drugich bardzo fajny wpis o a propos Chaos Engineering in Production, o tym jak zacząć samemu się wywalać, jak zacząć samemu aplikację niszczyć, żeby potem nas nie złożyło. Oczywiście cały Chaos Engineering zaczął się od Netflixa. Ale bardzo fajny wpis, który mówi właśnie o tym, jak to robić, niekoniecznie przy skali Netflixa, przy nieco mniejszej, dalej potężnej skali, ale mimo wszystko dobry wpis dla kogokolwiek, kto myśli nad tym, jak zacząć może w firmie i gdzie jest wartość i jak to w ogóle sprzedać biznesowi, bo od tego trzeba w ogóle zacząć. Jaki będzie nasz temat dzisiejszej rozmowy?

Łukasz Kałużny: Dzisiaj? Agile. Nie da się robić dobrej architektury.

Szymon Warda: No oczywiście, że się nie da. I chyba taki tekst, że się nie da, często słyszeliśmy tak naprawdę w niejednym projekcie, prawda?

Łukasz Kałużny: Tak, spotykamy się z tym. W sumie ja się spotykam z tym dość często, albo widzę tego efekty, że się nie da, bo ktoś nie dowiózł tej architektury.

Szymon Warda: Tak, czyli nie da się przez jeden przykład, że komuś się nie udało i wyciąganie wniosków, że się nie da. Też to widzę. Też nawet częściowo braliśmy udział w dużym projekcie, gdzie właśnie przeszliśmy przecież z waterfalla ogromnego na zwinną i jakoś dało się tą architekturę robić. Bo ja będę twierdził i się chyba w tym trochę zgodzimy, że architekturę da się zrobić, tylko trzeba robić inaczej.

Łukasz Kałużny: Tak, trzeba robić inaczej i w większości podejść… Często nie wypala.

Szymon Warda: Tak, często, ale często nie wypala. Głównie, moja diagnoza jest taka, że nie wypala z racji tego, że stosujemy podejścia bardzo archaiczne, podejścia sprzed 10 lat do architektury. Stosujemy je do sytuacji zwinnych, czy to będzie Agile czy kanban, nazwijmy to szeroko zwinną architekturą. A te wzorce się nie aplikują kompletnie tak naprawdę. I tu często leży problem. Tu często leży problem czemu właśnie nie działa.

Łukasz Kałużny: Czyli dzisiaj zrobimy sobie troszeczkę, zabrakło mi słowa, jak się mówi na, sekcję zwłok zrobimy, tudzież wiwisekcję.

Szymon Warda: Wiwisekcję, może retrospektywę.

Łukasz Kałużny: Retrospektywę, tak, ładniej. Czyli patrząc się na nasze doświadczenia, ja widzę na co dzień pewnie, w roku widzę, pomagam w 10, od 10 do 20 projektów, gdzie pojawiam się jako osoba z zewnątrz, która konsultuje, robi review albo przychodzi już zgasić pożar. A Ty?

Szymon Warda: Tak, moje życie jest trochę inne. Ja przez 6, 5, 6 lat prowadziłem wielki projekt, gdzie było czterdziestu pięciu developerów, który właśnie ewoluował od procesu takiego typowego waterfallu do zwinnego. A obecnie trochę mniejsze zespoły, ale za to mam przyjemność patrzenia na szkoleniach i na audytach firmy, jak się zachowują. Więc też często obserwuję to w krótszym okresie czasowym, ale dokładnie ten sam problem właśnie, że często słyszymy, że się nie da. A da się, tylko trzeba inaczej.

Łukasz Kałużny: Czyli co? Możemy sobie założyć, że nie da się, bo ludzie stosują troszeczkę inne podejście i wywinęli do góry nogami podejście.

Szymon Warda: Tak, podejście do góry nogami, trochę takie leniwe, że jak to kiedyś tak działało, to teraz też tak róbmy. I jest takich parę przypadków, które ja widzę. To jest przede wszystkim tworzenie rzeczy upfront, skupianie się na rzeczy technicznej tylko, a nie na rzeczach miękkich. Ten temat za chwilę sobie rozwiniemy. Ale przede wszystkim to koncentrowanie się na projektowaniu upfront, które często jest tak naprawdę. Jeżeli mieliśmy fixy, to z reguły robimy architekturę i teraz cały system, a w Agile to jest inaczej tak naprawdę, w zwinnej podejściu.

Łukasz Kałużny: Tak, w zwinnym, dobra, bo w fixach było to faktycznie może koncentrowanie się, tylko tam był czas na to, było i nikt z nim nie dyskutował.

Szymon Warda: Tak. Problem, jaki często był, to ten czas był tylko na starcie, a potem było róbcie jak już zrobiliście i nie było czasu na zmianę zdań albo ewoluowanie tego pomysłu. Tak, zgadza się, przy fixach nie widzieliśmy tego kosztu, ale też często przez te fixy częściej były zamykane, bo pół roku robią, jeszcze nic nie ma.

Łukasz Kałużny: Tak, to jest w tym prawda.

Szymon Warda: Tak, ale najważniejsze pozostaje pytanie, jak robić to inaczej? Jak podejść do architektury w takim razie? Jest takie fajne podejście, które ja widzę, które nazywa się architekturą ewolucyjną, czyli nie nastawianie się na budowanie rzeczy, tylko nastawianie się na budowanie czegoś, co będzie łatwe do zmiany, co będzie łatwe w ewoluowaniu naszej architektury. I to działa. To działa fajnie, ale jest bardzo, bardzo trudne.

Łukasz Kałużny: Czy wiesz co z ewolucyjną, ludzie, to tak jak sobie porównam fixa trochę do Agile, że niektórym ta zmienność pewnych rzeczy przeszkadza.

Szymon Warda: Oczywiście i ta zmienność też jest bardzo kosztowna. Ona kosztuje.

Łukasz Kałużny: Tak. Czyli jeżeli byśmy sobie popatrzyli, od czego byś zaczął patrząc się, to z Twojej perspektywy, jak tworzysz nowy software, podchodzisz do tego, zaczniesz, załóżmy podchodzimy sobie do tego zwinnie, od czego byś zaczął z perspektywy Twojej, developera architekta, jak byś zaczął to klepać i myśleć o tym?

Szymon Warda: Teraz będzie wielkie bum. Od monolitu. Tak. I to jest ten moment, kiedy nagle połowa naszych słuchaczy powie: nie no, w ogóle tutaj nie warto. Ja pamiętam parę lat temu na Build Stuffie usłyszałem właśnie zdanie od Fowlera, który jest dość polaryzacyjną figurą, można się nie zgadzać, nie zgadzać, ale to zdanie mi utkwiło bardzo mocno, który powiedział, że widział wiele zespołów, które zaczynały od monolitu, a migrowały się, potem migrowały się do mikroserwisów i im się udawało. Nie widział żadnego zespołu, który zaczynały od mikroserwisu i im się udawało. Czemu? Nie znamy na starcie domeny.

Łukasz Kałużny: Tak, jest to prawda i widzę to. Z mikroserwisami mamy tak, monolity potrafimy budować, nie do końca poprawnie, ale są one chyba jakoś w miarę stabilne. Bo rzucając się na mikroserwisy, to tak dużo osób myśli jak myśli. Agile myśli zwinnie, od razu się pojawiają mikroserwisy, a potem pojawia się cały duży stos technologiczny i się okazuje, że developer go nie ogarnia, trzeba DevOps inżyniera albo dwóch, jeszcze Opsa, architekta i innych rzeczy.

Szymon Warda: I nagle palimy 30% czasu na stawianie infrastruktury, co jest kłopotliwe. Albo jeszcze druga opcja, którą ja też widuję, to jest, że: nie, to olejmy tą infrastrukturę całą, to po prostu zróbmy mikroserwisy bez logowania, trace’owania, monitorowania automatycznego, bez niczego. Po prostu będziemy mieli mikroserwisy.

Łukasz Kałużny: To jest…

Szymon Warda: Widziałeś chyba jak to się kończy.

Łukasz Kałużny: Gasiłem, gasiłem w jednej instytucji finansowej, w której miałem dość szybkie wdrożenie i bardzo fajne właśnie orkiestracji pod względem Kubernetesa, tylko taki zrobiony w On premie z open source’u, który zachowywał się jak cloudowy zupełnie. Jaka była potrzeba biznesowa, że ja się tam pojawiłem i wtedy i się pojawialiśmy jako firma? U klienta poszli w mikroserwisy właśnie bez tego, o czym mówisz, czyli mieli chyba już 14 mikroserwisów. Przemnóż przez instancje, release raz w tygodniu ręcznie robiony ze zgłoszeniem w Jira starym change managementem, wysyłamy nową wersję, skrypty i Opsi lecą z release’ami w piątek wieczorem.

Szymon Warda: Jak powiedziałeś, tygodniowy release management, to moja pierwsza myśl była: to im się udało przynajmniej. Ale miałem nadzieję, że nie będziesz kontynuował tą dalszą częścią opowieści. Tak, to jest przerażające generalnie, że jedna droga ominięcia i druga droga stawiania tego wszystkiego jest wręcz przerażająco kosztowna. Jedna krótka, druga długofalowa. Przerażające. A ja powiem tak, że raz widziałem fenomenalne zachowanie, najbardziej zwinne podejście do wytwarzania, jakie widziałem. To było to! Faktycznie fenomenalna relacja z biznesem. To było to, że developerzy hackowali coś inicjalnie, dosłownie hackowali, to rzucało wyjątki, nie było idealne. Wdrażali to na produkcję, dbali, żeby to nie psuło danych. Wtedy biznes oceniał, czy to w ogóle działa. Jak działa, to dostawali od biznesu czas, gwarancję na ustabilizowanie tego, a jak nie, to oni nawet byli szczęśliwi, że to mogli usunąć, bo ten kod był crappy, nie oszukujmy się.

Łukasz Kałużny: Czyli robili prawidłowo MVP.

Szymon Warda: Ty, to tak się nazywa. Faktycznie. Tak, ale to widziałem takie zachowanie raz. Bardzo unikalne, fenomenalne prowadzenie ze strony PO, z biznesu. Niesamowita wartość.

Łukasz Kałużny: Czy wiesz co, tak, tylko że ludzie, nie wiem, teraz patrząc się z zewnątrz na projekty, przy których miałem okazję konsultować i gdzieś widząc jakieś problemy inne, ludzie chyba też nie rozumieją pojęcia MVP, które przy tej architekturze ewolucyjnej ma dużą rację bytu. Czyli wpierw coś pokaż od strony funkcjonalności, a potem to dopracuj albo wyrzuć, że nie ma tego poczucia. I też chyba nie wszyscy przekazują to biznesowi, że robimy crappy, żeby pokazać Wam jak działa, a potem doszlifujemy.

Szymon Warda: Znaczy wydaje mi się, że ludzie często robią tak, że oni pokazują biznesowi na przykład na jakiejś prezentacji, oni klikają. Nie oszukujmy się, ludzie są tacy, że póki to nie wejdzie na produkcję, nikt na to realnie nie rzuci okiem, nikt nie weźmie do siebie generalnie. Dopiero kiedy użytkownicy mają z tego korzystać, wtedy dopiero jest rewaluacja, czy to działa prawidłowo? Czy jest tam wartość? Co z tym zrobić? Póki nie ma na produkcji, to tego nie ma w ogóle, z mojej perspektywy.

Łukasz Kałużny: I trafiamy na mój problem, który widzę, Agile’owy. Widziałem kupę projektów, w których pierwszy produkt…

Szymon Warda: Kupa mówisz?

Łukasz Kałużny: Kupa, tak, kupa projektów, w którym pierwszy release był na przykład po ośmiu, dziesięciu sprintach. I czasami jeżeli… Dlaczego mówię release? Bo wszystkie wcześniejsze kończyły się tylko na środowisku często i nie dochodziły nawet do UAT-a.

Szymon Warda: Tak, dobrze jakby były w ogóle gdziekolwiek deployowane poza laptopem developera. No tak, to się, nawet ma swoją nazwę wspaniałą generalnie u nas - releasy zerowe. Ja widziałem raz releasy ujemne, że było odliczanie od minusów do zera i dopiero wtedy był start.

Łukasz Kałużny: Release ujemny?

Szymon Warda: Tak, ujemny, że zaczęliśmy od minus 2, to było przygotowanie, minus jeden i zero potem, takie pomysły. No bo to jest rozwiązanie problemu, że powinniśmy od zerowego release’u zacząć wydawać. No to jak problem rozwiązujemy? Numer zaczynamy wcześniej Łukasz.

Łukasz Kałużny: Okej.

Szymon Warda: Czy problem został rozwiązany? Został.

Łukasz Kałużny: Rozumiem. To zawsze mnie tam przy, jak są historyjki, zawsze mnie to fascynowało, że zrobiliśmy kawałek, ale brakuje jeszcze iluś rzeczy do tej historyjki i ona nie ma całej historii bądź epika, zawsze nienawidzę tego akurat, grupowań. Ale dostarczyliśmy, ale nie możemy włączyć tej funkcjonalności po tym sprincie, bo brakuje X, Y, Z.

Szymon Warda: Tak, albo nie możemy, bo ona popsuje inne rzeczy. I ludzie w tym momencie zapominają kompletnie o feature switching, zapominają o tym co wszystko wiąże się ze zwinnym generalnie. To ma wylądować finalnie i w krótkim czasie na produkcji i ma działać i ma być używane. Możliwe, że będzie tylko działało na zasadzie takiego canary deployment, czyli że tylko część ruchu puszczamy w to, w tą gałąź i weryfikujemy czy faktycznie wyniki są takie jak oczekiwaliśmy. To też jest używanie. Ale póki ten kod, przez ten kod nie będzie przechodził jakikolwiek ruch, nie będziemy mieli klucza, liczb, jak jest używane, co jest używane, kiedy jest używane, jaki jest procent wartości i tak dalej.

Łukasz Kałużny: No jak popatrzymy na liczby, to ja widzę ze swojej perspektywy jeden wielki problem, ponieważ zaczynając bardzo często nie znamy liczb. To jest taki najczęstszy przypadek, kiedy przychodzę i zadaję pytanie. Rzadko kiedy dostaję odpowiedź o liczby i patrząc się od strony biznesowej.

Szymon Warda: A jak dostajesz odpowiedź, to wierzysz tym liczbom?

Łukasz Kałużny: To zależy.

Szymon Warda: Ok, dobrze.

Łukasz Kałużny: Powiem to, to zależy. Ale patrząc się, to tak z mojej perspektywy jest tak, że często nie ma liczb i zaczynamy stosować skalę. Developerzy, architekci, zespół, czasami PM Manager, Scrum Master, u nas to jest Product Owner, bardzo różne są strony nacisku.

Szymon Warda: Tych ludzi jest dużo.

Łukasz Kałużny: Tak, w szczególności, że u nas te zespoły chyba nie są samowystarczalne. Ale ostatnio rozmawiając, ten nasz polski Agile jest, tak samo wygląda jako irlandzki, wielkobrytyjski, niemiecki. Wszędzie on jest podobny. Wszędzie jest ten waterfall w sercu, ale Agile jest na sztandarach.

Szymon Warda: No oczywiście, że tak. Jakbyś nie miał Agile’a na sztandarach albo mikroserwisów też na sztandarach, to ludzi nie zatrudnisz tak naprawdę.

Łukasz Kałużny: Tak. I przez ten brak liczb, środki nacisku, często zaczyna się budowanie Google Scale.

Szymon Warda: Zawsze budujemy Google Scale. To jest niesamowite, jaka jest takie, jak chcemy… Budując Google Scale sami wrzucamy się w problemy skali Google’a, czyli zarządzania tym wszystkim i tak dalej. To jest przerażające, jak ludzie chcą dużo na swoje barki wziąć.

Łukasz Kałużny: Tak to jest troszeczkę, że chcą… Jest robienie takiego over engineeringu po to, żeby to było skalowalne, zapominając o takich bardzo podstawowych wzorcach, zapominając… Chyba dla mnie takie dwa najcięższe, które są, to jest skalowanie horyzontalne, ale zrobione też na warstwie danych. Czyli nie tylko load balancing aplikacji, ale też danych, pomyśleniu czasami o shardingu tych danych od dnia zerowego. I ludzie tam się, brzydko powiem, spuszczają, jako że możemy sobie pozwolić po tytule na parę takich rzeczy, żeby zrobić to nie wiadomo co, a nie biorą podstawowych rzeczy. I Monolit, jak wspomniałeś, jak weźmiemy właśnie distributed cache, sharding danych i horyzontem skalowanie samych instancji, on w większości przypadków będzie działał.

Szymon Warda: Będzie działał fenomenalnie. Jest bardzo dużo firm skali kalifornijskiej, Etsy, gdzie mają Monolit i się czują z tym bardzo dobrze. Tak, zgadza się, jak najbardziej. A ja powiem tak, sharding, pchanie się od razu w sharding pokazuje, że ludzie nie myślą o tym jak te dane zamodelować wpierw. Jak dane dobrze zamodelujesz, to dodanie shardingu jest po prostu dodaniem kolejnego connection stringa i przełączania się między nimi. Trywialne.

Łukasz Kałużny: Tak. Ja zawsze mówię, że sharding może być zrobiony brutalniej konfiguracyjnie i ludzie się patrzą jak na wariata. Ale jak zamalujesz dobrze…

Szymon Warda: Nie ma problemu żadnego.

Łukasz Kałużny: Ale to jest to. I miałem też troszeczkę, jak powiedziałeś o Monolicie, takie doświadczenie właśnie skalowania. Miałem warsztaty z pewnym klientem i dość fajnie wyszło, że z modelowania nam wyszedł Monolit.

Szymon Warda: Jak często wyjdzie.

Łukasz Kałużny: Tak, zrobiliśmy. No kurde panowie, to macie Monolit i takie z trzy moduły na zewnątrz, które faktycznie one nie pasują i mogą być one akurat zupełnie oddzielnie rozwijane. I było, ale jak to oni mikroserwisy nie Kubernetes? Ale po co?

Szymon Warda: Słyszałem taką sytuację parę razy. Tak, ale: nie, to znaczy, że coś robimy źle, tu miały wyjść mikroserwisy. Przerażające jest, kiedy firma mówi: ok, to zróbmy modelowanie jeszcze raz z kierunkiem, że mają wyjść mikroserwisy. Ja nie raz byłem już na szkoleniu, nie raz robiłem szkolenie z mikroserwisów, gdzie po trzech dniach szkolenia grupa mówiła: to my musimy się zastanowić, czy my w ogóle chcemy te mikroserwisy. A wychodzi od tego, że tylko uporządkowanie wiedzy. Ja wtedy się czuję, że ok, to szkolenie poszło dobrze, bo zobaczyli ile ryzyk, ile problemów ich czeka tak naprawdę. Tak, ale dotknąłeś elementu tego, że tak naprawdę problem z mikroserwisami jest to, że pierw infrastruktura musi być, a IT się skupia na tym, że: to zróbmy infrastrukturę. Nie myślą o tym, że biznes patrzy im cały czas na ręce. Musimy jakąś wartość dostarczać, żebyśmy byli widoczni.

Łukasz Kałużny: Tak, jest to fajne. Czasami tak jak mówisz o infrze, jeżeli masz dobrze znany scope projektu, to z mojej perspektywy czasem, jeżeli robimy to zwinnie, warto poświęcić ten początek na bardzo dobre setupowanie infry. Kiedy wiesz, znasz na przykład skalę, kiedy przepisujesz system, bo często jest takie robione przepisanie, bo pozbywamy się z takiego powodu, że są problemy, to w takim często jak znasz liczby wiesz, że to się nie zmieni, albo jest już usługa, która jest na rynku, jest używana, więc znasz liczby, pi razy znasz wzrost, więc można poświęcić ten początek na infra.

Szymon Warda: Jest jeden element infrastruktury, na który ja zawsze poświęcam czas - to jest automatyczny deployment, bo to się zwraca najszybciej ze wszystkich inwestycji tak naprawdę. To, że od pierwszego wdrożenia mogę robić automatycznie, może być kulawe, może być niepełne, może być po prostu wgranie plików bezczelne, ale robię to, to są PowerShell jakiegoś albo czegokolwiek zautomatyzowane. To się zwraca w ciągu pierwszych trzech sprintów, tygodni, czegokolwiek.

Łukasz Kałużny: Tak, CI/CD na początku tak, uważam, że warto w to poświęcić, trzeba. Ale broń Boże nie robić z tego kurde sztuki dla sztuki.

Szymon Warda: Nie, nie ma sensu, żadnego canary deployment i tak dalej. Nie ma wartości.

Łukasz Kałużny: Widziałem stawianie po kilku sprintach. Fajnie jak na przykład zrobisz sobie emferyczne środowiska i inne zabawki.

Szymon Warda: Oczywiście.

Łukasz Kałużny: Robiąc w trakcie, żeby rozbudowując to. Tylko pytanie, ile będzie trwał projekt, bo czasami na 3 miesięczny projekt ktoś robi to tyle, ile można byłoby z tego postawić kilka produkcji.

Szymon Warda: Tak, niestety problem jest taki, że… Ale jest też problem z innymi liczbami, bo często ja to, co widzę, załóżmy jak nawet pytamy się o liczby i otrzymujemy te liczby, liczby od biznesu, to są liczby, które biznes ma nadzieję, że się wydarzą, jeżeli projekt się uda za 5 lat. A czemu tak biznes mówi? Bo wie, że nam to, z doświadczenia wynika, że my tak długo budujemy rzeczy, że oni muszą powiedzieć, że te rzeczy będą się działy za 5 lat, żebyśmy dogonili. A jak zbudujemy to zaufanie z ludźmi, że my dostarczamy szybko, to nagle te liczby będą coraz bardziej realne. A problem jest taki, że biznes też może się oszukiwać tak naprawdę, że ten projekt nie wypali i nagle zamiast 2 mln użytkowników będzie 200 tysięcy albo 20 tysięcy. To dalej jest ok, żeby projekt żył, ale to już nie jest skala Google’a, to nie te problemy tak naprawdę. Więc ten overhead nawet kosztowy na utrzymanie tego wszystkiego i wszystkich maszyn ten projekt zabije. My jako IT zabijemy projekt.

Łukasz Kałużny: No widziałem takie toczące się projekty, to ostatnio widziałem, tak, gdzie chyba na development jest 100 serwerów czy coś takiego w sumie. To dość spory projekt, a produkcja działa na dwudziestu, trzydziestu.

Szymon Warda: To jest problem, że ten projekt, on się za chwilę skończy z tego powodu, że ktoś spojrzy na Excela, bo to z reguły jest Excel, na jakimś spotkaniu rady nadzorczej czy czegokolwiek i powie: ta pozycja za dużo kosztuje i po prostu zrobi przekreślenie. Tak to wygląda. Na tak wysokim poziomie zarządczym nikt nie patrzy, co to za projekt, po prostu za duże liczby są. Koniec kropka.

Łukasz Kałużny: Z tym co było estymowane. Ale wiesz co? I to co mówisz, to co mówimy w sumie, to gdzieś też prowadzi do tendencji budowy tych opus magnum.

Szymon Warda: Tak, mamy tendencję jako wszyscy, że generalnie chcemy się pochwalić, co my umiemy zbudować i nagle to jest takie: a to ja tu dowalę wszystko, najnowsze frameworki, w ogóle to co ja tu potrafię pojąć i tylko ja to ogarnę jak to będzie działało. I to jest taka wielka katedra, która po prostu jest potem pusta i tam nic nie ma. To jest katedra, która czeka tylko na jakieś moduły biznesowe, a są dwa.

Łukasz Kałużny: Tak. A z drugiej strony masz ownera biznesowego, też często widzę: to będzie bardzo ważna aplikacja.

Szymon Warda: Oczywiście, przecież nikt nie chce tworzyć mało ważnej aplikacji.

Łukasz Kałużny: Tak, a czasami jest ona tworzona i to też jest fajne, bo bardzo rzadko, ale zdarza mi się zobaczyć takie właśnie zespoły 3, 5 osób i one tworzą takiego, ja to zawsze się śmieję, to taki corporate shit apps.

Szymon Warda: Które są konieczne, ale…

Łukasz Kałużny: Tak, zapis może być różny, zapis tego, ale taki smart app i on będzie bardzo istotny. I wiesz co, było tak od strony, miałem takiego Product Ownera jak bardzo istotny. I co się pokazuje? Aplikacja faktycznie spory zasięg, bo w ciągu miesiąca 20 tysięcy użytkowników, to jest spory. Tak, tam nieduża funkcjonalność, ale 20 tysięcy użytkowników.

Szymon Warda: To jest duża widoczność.

Łukasz Kałużny: Tak, duża widoczność. Tylko co się okazało? Ona może na przykład 3 dni nie działać. I jeżeli nie działa 1 dzień aplikacja, nikt się nie obrazi, bo proces jest zupełnie poboczny.

Szymon Warda: Niezłe.

Łukasz Kałużny: I to było na początku przekombinowane parę rzeczy. Okazuje się, że mogło być to naprawdę budowa cepa.

Szymon Warda: No tak samo jak większość systemów księgowych jest nieużywana przez większość miesiąca, jest używana na zamknięciu, na zamknięcie miesiąca, kiedy księgowi siadają do faktur, rozliczają wszystko, robią przelewy.

Łukasz Kałużny: Albo te najbardziej krytyczne moduły, kiedy zamykanie miesiąca.

Szymon Warda: Tak, dokładnie generalnie, to jest zamykanie miesiąca, księgowi pracują tak, że oni przez dużo czasu po prostu nie mają co robić, albo nie robią zbyt wiele, a potem siedzą po 12 i więcej godzin w pracy.

Łukasz Kałużny: Bo wszyscy, takie osoby jak ja nawet, czy Ty pewni, tak, w firmie rozliczenia i inne rzeczy na koniec miesiąca, bo już trzeba.

Szymon Warda: Tak, to mniej więcej wygląda tak, nie oszukujmy się. Ale trzeba brać taką właśnie specyfikę pracy pod uwagę przy projektowaniu systemu generalnie. Mówimy: o, system w korporacji, nie ma peaków. Są peaki. Każdy z tym księgowym ma takie peaki, że robi to wrażenie.

Łukasz Kałużny: Wiesz co, jedna rzecz, która, jak mówimy o opus magnum, fajna, to sam wiem, że popełniłeś kiedyś podobną, zaczynanie od własnego…

Szymon Warda: Wiem o czym mówisz.

Łukasz Kałużny: Tak, zaczynanie od własnego frameworka. Bo dużo osób buduje, od dnia zero próbuje zbudować sobie kawałek frameworka firmowego albo pod projekt, pod projekcik.

Szymon Warda: Tak, tak, tak, tak popełniłem. Z perspektywy czasu uważam, że to miało sens, było bardzo, bardzo ryzykowne. I to jest zawsze odpowiedź, że zależy jak daleko się pójdzie. Bo nie oszukujmy się, pewna standaryzacja jest potrzebna, żeby tych developerów ogarnąć, żeby… Frameworki są budowane ogólnie, a my będziemy dostosowywali je w kontekście naszego użycia. I dobrze jest zawęzić ten scope, na jakim możemy operować. Z drugiej strony, jak budujemy opus magnum, to nie, do tej wartości nie dostarczymy po prostu, jej nie będzie. To jest bardzo trudne z punktu widzenia ego, wartości. Nie ma chyba odpowiedzi dobrej, ale tak, ryzyko jest ogromne.

Łukasz Kałużny: Tak, bo ja widziałem taki projekt, gdzie znowu kilka miesięcy nie było release’u, ale za to tyle funkcjonalności nowych doszło do frameworka, tam akurat to był na bazie Javy i Owner był taki techniczny i było rozbudowywane jego dziecko, jego framework był rozbudowany o funkcjonalności.

Szymon Warda: Tak często jest.

Łukasz Kałużny: Które robiliśmy, to też cloudowo projekt, więc pewne rzeczy były out of the box jako funkcjonalności w bibliotekach. Tam były akurat azure’owe, były gotowe po prostu w SDK. No ale trzeba było to przykryć swoją wystandaryzowaną warstwą.

Szymon Warda: Bo może zmienimy kiedyś Azure na AWS albo bazę relacyjną na bazę key-value, więc to wszystko musi być abstrakcją. Tak, ale to jest ten moment zarządzania ryzyka tak naprawdę. Gdzie pójść? Czy przykrywamy abstrakcją? Czy godzimy się z naszym vendor lockiem? To jest naprawdę, naprawdę trudne.

Łukasz Kałużny: I wiesz co, tak jak z vendor lockiem, to mi się, rzucając jeszcze przy własnych frameworkach, troszeczkę dwa kulty, które się pojawiły i one są dla mnie ok i nie ok. Mamy coś, co się zaczyna robić, znaczy jest starą rzeczą, bo mamy commodity, które na rynku, stawanie się rzeczami, towarem. I dla mnie to jest bardzo fajne, ponieważ standaryzuje dużo rzeczy w IT.

Szymon Warda: Tak, i buduje oczekiwania, co możemy od tego produktu wymagać.

Łukasz Kałużny: Tak, tak jak teraz o cloudach mówi się, że zaczną być serverlessy, code as a service, raczej function as a service, wszystkie wywołania, że ma się taki docelowo, powinno być kompatybilne. Są próby typu ten framework serverless na bazie nodeJS-a i inne rzeczy, żeby stało się commodity. I to jest niby fajne, ale ludzie też próbują to przemycać, podejście Commodity i co bardziej jeszcze - cargo, czyli dowożenia tego. Próbują to przemycać do projektów.

Szymon Warda: I to jest takie, potem zlepiamy ten cały system i łączymy elementy, które ze sobą do końca nie powinny być połączone. Śmieliśmy się z tego, że to jest tak jak masz, jak budujesz dom, to łączysz cegłę ytongową z cegłą białą, z cegłą czerwoną i coś z tego wyjdzie. Tylko pytanie czy to powinno wyjść to co wyjdzie? Czy to wygląda dobrze w ogóle?

Łukasz Kałużny: Budowa domu metodą gospodarską czy jakoś tak.

Szymon Warda: Tak, co było to zbieramy.

Łukasz Kałużny: Tak, jakoś fachowo.

Szymon Warda: Mnie w tym commodity i w całym ruchu martwi trochę spojrzenie na, a szczególnie w chmurze, na to czy ta usługa, o którą się opieramy, jak długo ona będzie żyła też. Bo nie oszukujmy się, w chmurze też te usługi są niektóre discarded. I to jest ten problem opus magnum, wracamy, że: ja tu użyję najnowszych rzeczy. Te najnowsze, niektóre rzeczy nie wychodzą z preview i na to też trzeba uważać. Więc z drugiej strony znowu pchanie się w rzeczy stare nie jest zbyt fajne, bo nowe dają nam nowe możliwości rozwoju. Jest trudno.

Łukasz Kałużny: Wiesz co, jeszcze tak do cargo dorzucę. To mi się troszeczkę kojarzy, że ludzie teraz biorą dużo wzorców projektowych, design patterns, biorą i wrzucają, bo one się gdzieś sprawdziły, to jest troszeczkę bez popatrzenia, czy ja ich potrzebuję. Chyba tu pasuje. To jest takie, że chyba tak wezmę, poślinię rękę, poślinię ten znaczek, karteczkę, o tutaj ten case pasuje i będę tego używał.

Szymon Warda: Ja częściej, bardziej widzę odwrotną sytuację, że mam taki pattern, to gdzie by go przylepić, bo ja bym chciał go użyć.

Łukasz Kałużny: Ale to jest, wiesz co, to może źle sens przekazałem swojego, ale tak, właśnie to jest pattern i chyba tu pasuje, bo mam tutaj kilka, ostatnio przeczytałem i tu chyba któryś będzie pasował.

Szymon Warda: Bo on rozwiązuje problem, który my możemy mieć za circa 5 lat.

Łukasz Kałużny: Albo w ogóle.

Szymon Warda: Albo w ogóle.

Łukasz Kałużny: Ale jest CV-driven development.

Szymon Warda: Albo LinkedIn development, jak to niektórzy teraz zaczęli na blogu promować.

Łukasz Kałużny: Tak, tak, będzie następny o tym wpis.

Szymon Warda: Liczę na to, bo przeczytałem poprzedni i był dobry.

Łukasz Kałużny: Dobra, jak jesteśmy przy zwinności, to jeszcze mówiliśmy trochę o ewolucyjnym wyrzucaniu, wkładaniu. I teraz duże zmiany i zmiany w projektach. Czasami mam wrażenie, że w starych fiksowych, w ogóle w projektach fiksowych nazwijmy to, było łatwiej przemycić pewne zmiany, jak się waliło, jak było widać, że będzie się w projekcie źle działo, bo zaczyna się bug fixing, za dużo i inne rzeczy, że łatwiej się to troszeczkę w porównaniu do agileowych, bo tam byliśmy w Agile nastawieni też, no nie oszukujmy się, nastawieni na dostarczenie tego produktu.

Szymon Warda: Tak.

Łukasz Kałużny: Tak. I stąd czasami było zbyt duże sfokusowanie, polaryzacja na te dostarczenie, a czasami nie zrobienie porządku z pewnymi rzeczami, kiedy trzeba.

Szymon Warda: Mnie bardzo cieszy, że użyłeś słowa łatwej, bo słowo łatwiej powoduje, że jak pójdziemy na skróty to będzie łatwiej, ale jak się wysilimy to dalej da radę zrobić. Problemem dla mnie, który widziałem, który dalej widzę przy tych waterfallowych jest to, że to my zrobimy wielkiego rewrite, za 3 miesiące będzie. I my często nie myślimy o tym, jak to jest odbierane przez biznes, który mówi: ej, ale jak to w 3 miesiące? W ogóle jak to? Czyli nowych feature’rów nie będzie przez 3 miesiące? To jest nierealne. A Agile mówi: nie, nie, wydajemy co tydzień, więc rozbij tą zmianę na mniejsze części, to dalej da radę zrobić, jest na pewno trudniejsze, wymaga dużo więcej koordynacji, ale to dalej jest rabialne.

Łukasz Kałużny: Czy wiesz co, ale czasem masz moduły, których nie rozbijasz. To taka moja perspektywa.

Szymon Warda: Zgadzam się. Jak najbardziej się zgadzam.

Łukasz Kałużny: Że często przy troszkę większych już systemach, załóżmy, że team developerski ma 20, 30 osób, to czasem powstają funkcjonalności, której tak łatwo nie przerobisz.

Szymon Warda: Bez dwóch zdań tak, jak najbardziej. Są obejścia. Można to przepchać przez parę sprintów, można jakąś funkcjonalność przykisić, ważne, żeby nie zamrozić developmentu. Część zamrozimy, potem są problemy z nadganianiem feature’ów i tak dalej. Jest to, to, co powiedziałaś, to dużo trudniejsze. Będę twierdził, że jest rabialne. A czego Ci nie żal w przejściu z fixów na Agile? Czego pozbycia się Ci nie żal?

Łukasz Kałużny: Dokumentacji w takim starym IBM-owskim stylu to nazwijmy. Bo to jest taki dla mnie…

Szymon Warda: Dokumenty Worda piękne, które się otwiera.

Łukasz Kałużny: Tak, 300 stron dokumentu nie wiadomo po co. To fakt. W dokumentacji czy dokumentacji w starej formie nie żal, bo uważam, że przepalaliśmy na to… Jakość tego, która była dostarczana czy w przedwdrożeniowej dokumentacji analitycznej czy powdrożeniowej, nie oszukujmy się, piszą ją juniorzy.

Szymon Warda: Tak, często rozwiązują problemy, które… Papier wszystko przyjmie, to chyba obydwaj wiemy.

Łukasz Kałużny: Tak.

Szymon Warda: I problem jest taki, że często tam ci ludzie piszący dokumentację rozwiązują problemy, które właśnie zauważyli, a nie problemy, które powinni rozwiązywać. I to jest płynięcie, tam nie ma limitów.

Łukasz Kałużny: Wiesz co, jedna rzecz, że te dokumenty, w szczególności jak ktoś, bo dokument jest drogi, więc powinien być pisany tekstem, nie bulletami i często jest lanie wody.

Szymon Warda: Tak, to jest często po prostu powieść, to jest nowelka. Przerażająca, bardzo długa nowelka, której nikt później nie czyta. Ja zawsze jak taki dokument biorę, to moje pytanie jest: jak bardzo to jest nieaktualne? To jest mój punkt wyjścia, bo to na pewno jest nieaktualne, szczególnie w obecnych systemach, to nie ma. Ok, ale w takim razie czym zastępujemy dokumentację taką?

Łukasz Kałużny: Czy wiesz, co są, ja widzę kilka podejść do tego. Po pierwsze, pojawia się teraz bardzo dużo tooli, żeby razem przy release’ach i innych rzeczach po prostu ściągać historię z naszych systemów do trackowania. Jeżeli mamy dobrze opisane user stories przykładowo, back jest w miarę zatytułowany i opisany, to są pluginy tak jak do Azure DevOps, do innych, do generowania release node i innych rzeczy dumpowania tego. Więc możemy przykładowo cały release z backfixami ze wszystkim, zrobić do tego release node’y, co się zmieniło i masz odnośniki do bugów i innych rzeczy. To tak patrząc się rzeczy.

Szymon Warda: Release nodey są bardzo ważne jeśli chodzi o deployment i dostarczanie do biznesu, żeby wiedzieli co się zmieniło, ta widoczność pracy.

Łukasz Kałużny: Albo co jest sfiksowane co nie, bo mamy otwarte bugi i one nie były dostarczone. Więc to od tej strony fajnie wygląda.

Szymon Warda: Ale to nie załatwia wszystkiego. Zostają nam obszary…

Łukasz Kałużny: Tak.

Szymon Warda: Techniczne.

Łukasz Kałużny: Od strony technicznej. Teraz jestem fanem markdown w repo w kodzie.

Szymon Warda: Stosujemy, fenomenalna opcja.

Łukasz Kałużny: Tak. Po prostu masz repo, masz kawałek czy folder na swój projekt, jak ktoś ma mono repo, robisz do tego katalog docs, wrzucasz markdowny i we wszystkim, czy to GitHub, GitLab, znowu DevOps, czy inne, czy bitbucket, po prostu Ci wyświetli strukturę. Żaden confluence i inne rzeczy, po prostu czysty, chamski markdown, bo developer będzie to uzupełniał co trzeba.

Szymon Warda: I co jest fajne w tym? Możesz robić pull requesty, czyli jest review, ale też jest mega fajny feature w Azure DevOps, że możesz to robić edycje in portal.

Łukasz Kałużny: Tak i robi commit.

Szymon Warda: I robi commit. Więc w tym momencie to nie tylko muszą być ludzie techniczni, którzy to uzupełniają.

Łukasz Kałużny: Akurat teraz powiem Ci jedną rzecz, bo miałem już z tego feature’a, w ogóle szkolenie robiłem wyobraź sobie, z używania wiki. Jest jedna rzecz licencyjna, użytkownik musi mieć licencję basic w Azure DevOps, to taka ciekawostka, żeby móc scommitować do repo, bo masz dwie wersje wiki tam. Jak ta fajniejsza, to musi mieć licencję, nie wystarczy state holder. To taka ciekawostka dla Ciebie.

Szymon Warda: Tak, z state holder jest bardzo ograniczony. Bardzo, bardzo.

Łukasz Kałużny: Mimo, że Wiki może edytować to nie tą, która jest trzymana w normalnym repo, mimo że git tam też jest pod spodem i jest do niego dostęp.

Szymon Warda: Ciekawe czy to się zmieni, bo takie rzeczy… Microsoft ma tendencję do prostowania takich ułomności, bym powiedział.

Łukasz Kałużny: Zobaczymy. Jak jesteśmy przy dokumentacji, to jest jedna rzecz, co z architektoniczną? I rzucając jest sobie coś, co się nazywa bardzo ładnie, architecture decision record, ADR i mówi o tym, że produkowanie, oryginalnie brzmiało strasznie, bo powinien być dokument, który mówi nam o analizie czemu wybraliśmy taki produkt, a nie inny. Ale też powstał bardzo fajny trend, który staram się pokazywać, żeby ludzie sie tym zainteresowali, spróbowali to wdrożyć przy projektach, który ma trochę potrwać, jest sobie wersja tego light, lightweight. Czyli polega to na tym, że robimy bardzo prosty markdown w repo, może być to oddzielne repo, w którym robimy sobie normalny markdown z paroma bulletami, który mówi jaki mieliśmy problem, co zobaczyliśmy i z jakiego powodu wybraliśmy akurat to rozwiązanie. Nie wiem czemu, bo nasza dyskusja wcześniejsza Rabbit vs Kafka.

Szymon Warda: Tak, dokładnie.

Łukasz Kałużny: Gdzie dosłownie w ogóle nie piszemy jakiejś tam noweli, o której powiedziałeś, tylko piszemy zwykłe, brzydkie bullety, tak żeby wejść, zobaczyć i potem jest bardzo fajne. Bo masz mechanizm pull requestów, czyli ktoś może ci to zreviewować za nie, czyli można zrobić review, komentarze po prostu w ramach normalnej pracy z tym. Dostajemy historię, można zakładać, jeżeli macie, nie wiem jak jest z rugowaniem, jeżeli coś jest zintegrowane, tak jak niektórzy korzystają płatnie z GitHuba, z korporacyjnego GitHuba, można założyć sobie do tego w ogóle issue’sy i inne rzeczy i można zbudować całą historię. I to bardzo fajnie chroni przed syndromem takim jak jest z panem od remontów, czyli: kto panu to spierdolił?

Szymon Warda: Tak, ja często widzę taką opcję, że nie patrzymy na rozwiązanie i myślimy: o Jezu, to jest źle. W IT jest zawsze i w ogóle w życiu jest zawsze. To zależy. Jeżeli nie poznamy, czemu decyzja była podjęta i jaki problem rozwiązywała, sorry, ale to w tym momencie nie możemy oceniać. Jeszcze jednego elementu, co do dokumentacji brakuje mi, to takiego wysokopoziomowego spojrzenia na architekturę. I nie chodzi mi tu broń Panie Boże o wielką dokumentację, prosta dokumentacja 4C, podejście 4C. Zejście na te pierwsze 3C, pierwsze 2C.

Łukasz Kałużny: Czym jest C?

Szymon Warda: W zależności, może być kontekstem, kontenerem, klasą, komponentem, czyli spojrzeniem jak… To jest fajne porównanie jak mapy są zbudowane. Jak się patrzy na mapę świata, to nie chce widzieć się dróg w Polsce, bo to nie ma sensu, więc takie spojrzenie: ok, jak cały system wygląda? Wygląda tak, z takimi serwerami w ogóle gada. Potem schodzimy niżej. A ten proces biznesowy z czym rozmawia? Z tym, z tym, z tym, z tym, przez to płynie. I nagle mamy takie ogólne pojęcie z lotu ptaka albo z lotu trochę niższego i to daje momentalne wdrożenie: okej, to w miarę tak to wygląda, to już wiem co z czego wynika, co z czym gada. Bo często dogadanie tego obszaru jest naprawdę trudne i jak dorzucimy 4C do tego, co powiedzieliśmy, ja jestem wesołym człowiekiem, to naprawdę wystarcza, w zupełności. Jest jeszcze jeden fajny temat, który trochę ominęliśmy przy naszym wielkim opus magnum, to jest to, że czas życia systemu się skraca. Obecnie to jest około 5 lat.

Łukasz Kałużny: Nawet troszeczkę krócej bym powiedział, w niektórych przypadkach, już widziałem. Tak, to jest fajne. Miałem bardzo dobry dowcip ze spotkania, kiedy ja i parę innych osób. Było takie spotkanie, chyba trzech czy czterech architektów i osoba techniczna od klienta rzuciła, że musi być ta architektura, przeżyć najbliższe 10 lat.

Szymon Warda: Nierealne.

Łukasz Kałużny: W Cloudzie.

Szymon Warda: To w ogóle nierealne.

Łukasz Kałużny: Powiedzieliśmy, że trzy lata damy gwarancję.

Szymon Warda: Trzy lata to jest rozsądna wartość, tak.

Łukasz Kałużny: Tak, że trzy lata damy. Tak, teraz chyba też trzeba sobie uświadomić, że sposób, w jaki żyjemy ogólnie, szybciej, więcej, lepiej, zmiana, zmiana, zmiana, zmiana, dobra zmiana, powoduje, że ta architektura zaraz nie będzie aktualna.

Szymon Warda: Jest fajne podejście Google’a. Kiedy Google przepisuje nowy system, to projektuje system na ruch obecny razy 10 czy do 30 generalnie. Czemu? Bo oni wiedzą, że do momentu jak oni będą mieli ruch razy 40, to będą inne systemy i inne rozwiązania i inne rzeczy będą jako commodity, co powiedzieliśmy, czyli że pewne rzeczy są łatwiejsze, więc nie ma sensu robić teraz, planować na ruch razy 100, bo będziemy żyli w innym świecie. A może ten system w ogóle nie dożyje? Zobaczmy jak dużo firm jak feniks powstaje i nagle ich nie ma tak naprawdę.

Łukasz Kałużny: A procesy biznesowe też ostatnio tak giną.

Szymon Warda: Tak giną. Ale to nawet dobrze, bo ten zbiór procesów biznesowych to jest ciężar dla firmy. To jest to, czemu się często przepisuje system. Po to, żeby przeorganizować procesy biznesowe, żeby go odchudzić, żeby zastanowić się: a czemu w ogóle to robimy? Czemu tego maila wysyłamy? On kosztuje nas pół godziny każdej obsługi. Nie ma sensu. Wywalamy. To jest duża wartość. To co podsumowujemy?

Łukasz Kałużny: Tak. To co zaczniesz?

Szymon Warda: Tak. Dla mnie takim kluczem, który chcę, żeby ludzie zrozumieli i przyjęli, to jest: nastawmy się na zmianę. W Agile da się, tylko są inne KPI, inne realia. Zmiana to jest coś, co musimy przyjąć jako normalne. To dla mnie jest bardzo ważne. Kolejne niejako implikuje zmianę, żebyśmy mogli w ogóle ją zrobić. To jest to, że budowanie relacji z biznesem, żeby on nam zaufał, żeby nam wierzył, żebyśmy mieli poparcie od biznesu, jest tak samo ważne jak budowanie rzeczy technicznych. Nie da się Agile robić, jeżeli mamy dwie strony barykady. To musi być jeden team, musi być zaufanie, bo czasami coś popsujemy, czasami musimy coś przepisać. Potrzebujemy tego zaufania i musimy sobie pomagać. Co u Ciebie?

Łukasz Kałużny: Jak Ty mówisz miękko, to ja będę twardo.

Szymon Warda: Dajesz.

Łukasz Kałużny: Czyli pierwsze, od początku jak powstaje te MVP, deploy, release, nawet nie automatyczny, ale zakończ sprint czymś, co można pokazać.

Szymon Warda: Podpisuję się rękami, nogami, czym mogę.

Łukasz Kałużny: Tak. I drugą rzeczą, ADR-y, o których wspomniałem. Czyli to, jeżeli masz nie robić dokumentacji, bo często też tak bywa w agileowych rzeczach.

Szymon Warda: Bywa.

Łukasz Kałużny: To dokumentuj tylko decyzje.

Szymon Warda: Tak, bardzo, bardzo ważne. Ja się w zupełności zgodzę. To są proste triki, o których mówimy. Tu nie ma nic skomplikowanego. I jak to będzie, to projekty będą dużo lepsze.

Łukasz Kałużny: Relacja z biznesem nie jest taka łatwa.

Szymon Warda: Nie jest, zgodzę się. Ale to nie nie jest coś, co wymaga ogromnych. To wymaga ogromnych nakładów pracy. To wymaga systematycznego rozmawiania z ludźmi po prostu.

Łukasz Kałużny: Czyli zmiana, zaufanie, częste wydawanie i dokumentowanie decyzji.

Szymon Warda: Tak. Tyle.

Łukasz Kałużny: Tyle.

Szymon Warda: To kończymy. Dziękujemy.

Łukasz Kałużny: Dzięki.

Szymon Warda: Na razie, Łukaszu.

Łukasz Kałużny: Hej, Szymonie.