Krzysztof:
To jest 313 odcinek Porozmawiajmy IT. Dzisiaj rozmawiamy o tym, że systemy IT się psują i o tym, czego nas to uczy.

Krzysztof:
Notatkę, linki i transkrypcję znajdziesz na porozmawiajmyoit.pl łamane na 313. A jeśli myślisz o zmianie pracy albo po prostu masz dość klikania dalej na ogłoszeniach bez widełek, to zajrzyj na Solid Jobs. Tam wszystko jest na tacy. Wynagrodzenia, technologie, projekty. Bez zgadywania. Nazywam się Krzysztof Kempiński. Tworzyłem ten podcast, napisałem też książkę Marka Osobista w branży IT. Jeśli lubisz ten podcast, udostępnij ten odcinek dalej albo zostaw ocenę w swojej apce. To jest dla mnie nieoceniona pomoc. A teraz odpalamy. Cześć, mój dzisiejszy gość to autor satyrycznego IT Dictionary. Od niemal dwóch dekad przechodzi przez kolejne szczeble technicznej drabiny, od programisty przez architekta po engineering menadżera. Po zebraniu, opisaniu branżowych absurdów tym razem bierze na warsztat znacznie poważniejszy temat błędy i katastrofy w IT. Analizuje momenty, w których systemy zawodzą i sprawdza, czego jako branża możemy się z tego nauczyć, by zamiast szukać winnych budować realną odporność systemów i zespołów. Moim waszym gościem po raz drugi jest Adam Korga. Cześć Adam, bardzo miło mi gościć cię w podcaście.

Adam:
Cześć, miło być znowu i mam nadzieję, że coś ciekawego z tego wyjdzie.

Krzysztof:
Ostatnio rozmawialiśmy pół roku temu o nieco lżejszym temacie, bo to był humor w IT, było troszkę żartów, troszkę śmiechu, ale też poważnej treści jak najbardziej, ponieważ z naszej rozmowy wyszło, że ten humor ma jednak jakieś określone znaczenie do tej rozmowy. Oczywiście również zapraszamy, będzie ona w datce do tego odcinka podlinkowana, a dzisiaj rozmawiamy o temacie już poważniejszym, będziemy mówić o tym, że system IT się psują i czy my jako branża coś z tego wyciągamy, czy się uczymy, czy coś nam w ogóle ta wiedza daje. Więc potrzebny temat jakby nie było, ale rozpoczniemy sobie standardowo i może dla tych, którzy tej naszej pierwszej rozmowy nie słyszeli, czyli od tego, czy słuchasz podcastów i może jakieś ciekawe audycje zasugerujesz.

Adam:
Tak jak ostatnio powiedziałem, nie słucham tak dużo podcastów, po części brak czasu, po części jak jakoś wolę, jestem wzrokowcem, więc jeśli chodzi o ciekawe informacje, to więcej zapamiętuję czytając. Czasami dla rozryski coś o grach, tu mogę polecić formą gadka z jakiegoś powodu i czasami też w ramach powiedzmy researchu trochę anglojęzycznych typu nie wiem, OneX Developer, Developer, nie mam pojęcia skąd się to wziął, nie wiem jak to wymagać, i parę innych, ale generalnie, tak jak mówię, jestem sztrokowcem, więc nie jest to moja główna metoda spędzenia czasu.

Krzysztof:
Tak, wiesz, jak sobie tak obserwujemy tą blogosferę i szeroko rozumianę social media, no to pewnie każdy, kto to robi, to zauważy, że raczej mówi się o sukcesach, o tym co się udało, o tym, jak bardzo to się przełożyło na jakieś realne rzeczy. Zapominamy trochę o tym, że mimo wszystko to nie jest komplet tego naszego życia, że wpadki, różne błędy, coś, co się nie udało, zdarza się pewnie zdecydowanie częściej. I tak samo też jest z tą naszą branżą. Robimy mówić o sukcesach, robimy mówić o tym, jak bardzo wpływamy na życie ludzi, ale rzadko kiedy wspominamy o tym, co tam się nie udało. No właśnie, czy według ciebie mimo wszystko jednak uczenie się na tym nie wyszło na błędach, na fuck-upach, na wpadkach? Jest wartościowsze niż, nie wiem, czytanie sobie o sukcesach?

Adam:
Uważam, że zdecydowanie bardziej wartościowe, bo sukces ma to do siebie, że jest w wypadku u bardzo wielu czynników, z których nie wszystkie da się zreplikować i nie wszystkie są nawet wymienione w sukces story. Na pewno w sukces story Netflixa, Facebooka czy innego Microsoftu nie zobaczymy stwierdzenia, a tak w sumie to mieliśmy szczęście, a nie oszukujmy się, ale to też jest istotny czynnik. Jeśli czytamy, nie wiem, o Nike, usłyszymy historię o tym, że tam chyba ośmiu czy dziewięciu gości się spotkało, stwierdziło just do it i wszystko poszło, ale już nie wspominają o realiach społecznych, tego, że w latach siedemdziesiątych w stanie, o ile dobrze pamiętam, Ohio albo Oklahoma, ale nie cytujcie mnie z tego powodu, Samo to, żeby ktoś miał biznesplan i był, przepraszam, ale jednak biały, oznaczało, że banki otwierały portfele z miejsca. Teraz o tym nie przeczytamy tak łatwo, a to są istotne kryteria. Z tej perspektywy powtórzenie sukcesu wcale nie jest takie proste, podczas gdy powtórzenie błędu jest, nieuniknione, jeżeli nie nauczymy się, co poszło nie tak. Co więcej, nawet psychologia sugeruje, że uczenie się na błędach jest jedną z najefektywniejszych metod uczenia się w ogóle. Możemy zrobić setki przykładów, nie wiem, z matematyki czy innej fizyki dobrze, ale analizując własne pomyłki zapamiętamy dużo więcej. Analizując cudze pomyłki troszkę mniej, ale jednak wciąż dużo. Bardzo fajnie o tym napisał chociażby Radek Kotarski w jego książce Włamcie do mózgu. I powiedzmy, że nauka na błędach cudzych po prostu jest tańsza, odrobinę mniej efektywna, ale wciąż bardzo wartościowa i stąd po części moje skrzywienie w tym kierunku.

Krzysztof:
Czyli wszystko łącznie z nauką mówi nam, że faktycznie jest to efektywniejsze, jest to tańsze, że jakoś bardziej, mam wrażenie, skupiamy się w momencie, kiedy faktycznie analizujemy jakieś błędy, no tym bardziej, jeśli to są nasze błędy, jesteśmy w stanie coś z tego wyciągnąć, niż właśnie spróbować powtórzyć czyjś sukces, bo tak jak powiedziałeś, za nie może stać jeszcze mnóstwo innych czynników, na które zwyczajnie nie mamy wpływu. Szczęście jest pewnie jednym z nich to, że ktoś się pojawił w odpowiednim momencie, w odpowiednim czasie historycznym i tak dalej, jest pewnie nie do powtórzenia, natomiast to wcale nie znaczy, że na tej swojej drodze nie było tam mnóstwo błędów, mnóstwo problemów, mnóstwo porażek, z którymi te osoby musiały sobie poradzić. To nam mówi nauka, to nam mówi historia, ale czy w tej naszej branży my jesteśmy świadomi tego, że faktycznie tak to działa, że błędy się zdarzają, że bugi w kodzie się zdarzają, że systemy się wysypują, że są zawodne, czy potrafimy się z tego w jakiś sposób czegoś nauczyć?

Adam:
I to jest ciekawe pytanie, bo chciałbym powiedzieć, że tak, bo jednak jednym z kluczowych elementów każdej organizacji są postmortem, analiza porażek. Wszyscy są świadomi, że trzeba to monitorować, reagować i tak dalej, więc tak, w pewnym sensie branża się uczy. Najlepsze firmy na świecie robią to publicznie i to również szanuję i celebruję, kiedy widzę chociażby kolejny fuck-up w wykonaniu Cloudflare czy Amazonu, AWS-u, jest ich trochę, za każdym razem publicznie przyznają, co poszło nie tak i robią publiczną analizę. To tak naprawdę buduje zaufanie, więc ogólnie branża powoli idzie do przodu. To, że czasami to dlaczego mam pewne obiekcje to może nie będę zagłębiał się od razu nie pytany, ale czasami mam wrażenie, że jednak. Podobnie jak w świecie mody są nawroty pewnych trendów, tak w IT pewne trendy również wracają i nagle doznajemy jako ogół branży zbiorowej amnezji. Prostym przykładem obecnym jest chociażby mierzenie efektywności produkcji oprogramowania. Z jakiegoś powodu zapomnieliśmy ostatnie dwie, dwie i pół dekady mówiące o tym, że linia kodu to nie jest najlepszy wyznacznik i wszyscy celebrują to, jak szybko możemy generować kod. Tak, uczymy się, ale też mamy tendencję do zapamiętania pewnych lekcji.

Krzysztof:
Tak, to są pewnie jakieś cykle, jakieś takie faktycznie powtarzalne rzeczy, być może kwestia też pokoleniowa, że musimy się pewnej rzeczy jednak na nowo uczyć, pomimo tego, że pewnie sporo literatury na ten temat jest, że coś tam nie działa, że mnóstwo prób w tym kierunku poszło nie tak, ale z jakichś tam względów jest to dla nas, nie wiem, atrakcyjne znów i musimy się sami na własnej skórze przekonać o tym, że to nie działa. Wiesz, ja nawet próbuję to odwołać gdzieś tam do, że tak powiem, naszego pokolenia, które też pewnie mnóstwo błędów powtarzało, tych błędów, które, nie wiem, z lat 60-tych, 70-tych na początku rozwoju informatyki były poczynione i my robiliśmy to samo, prawda?

Adam:
Ale tak naprawdę to możemy, to też jest jedna z lekcji, których ja się nauczyłem, że to wszystko jest to, co siedzi w naszej psychologii. Nie musimy patrzeć w historię informatyki, wystarczy popatrzeć na wymianę pokoleniową. Każde kolejne pokolenie ma tę tendencję do stwierdzenia, że my jesteśmy mądrzejsi niż nasi rodzice. Ja tak twierdziłem o moich rodzicach, to samo słyszę od swoich bratanic czy innych członków rodziny, których wiek jeszcze nie kwalifikuje ich do trzymania paracetamolu. Więc, Podobne rzeczy, niemal ten sam mechanizm widzimy w branży. Nowe pokolenie managementu, jak wspomniałeś. Tak są lekcje, ale po co czytać o historii mainframe’ów, skoro teraz siedzimy na cloudach, podczas gdy mechanizmy, które tam się zadziały, mają jak najbardziej zastosowanie. Nie jest to oczywiste, wymaga wysiłku, więc powtarzamy błąd.

Krzysztof:
No właśnie, na to wszystko nakłada się pewnie taka trochę skręcona perspektywa naszego patrzenia, które to lubi oceniać, lubi to brać pod uwagę projekty, technologie, które gdzieś tam się sprawdziły, które wybiły się, które weszły do takiego mainstreamu, natomiast zupełnie zapominamy o tym, że pewnie mnóstwo tam było różnych towarzyszących czy konkurujących podejść technologii, które z jakichś tam względów jednak się nie powiodły. O tym raczej nie czytamy, tym się nie interesujemy. Co byś powiedział właśnie o tego typu pajasie, o takim skrzywieniu myślenia?

Adam:
Wracamy w sumie do pytania o tym, dlaczego czytanie o sukcesach niekoniecznie jest fajne, wystarczające. W psychologii jest nawet termin na to, po polsku nazywa się to najczęściej błąd przeżywalności, chociaż widziałem też inne tłumaczenia, angielski termin survivorship bias, który mówi dokładnie to, że uczenie się na sukcesach z definicji ogranicza nasz punkt widzenia do tych przypadków, gdzie się udało, podczas gdy dane o tym, jak coś działa, są tam, gdzie coś się nie udało. To klasyczny przykład i w zasadzie origin story tego terminu. To jest historia bombowców w czasie II wojny światowej, gdzie… O ile dobrze pamiętam, Armia Stanów Zjednoczonych analizowała, gdzie na kadłubach bombowców wracających z misji były dziury po kulach. Uznawali, że tam trzeba wzmacniać pancerz i Heja wzmacniali pancerz. Dopiero matematyk, statystów, o ile dobrze pamiętam, węgierskiego pochodzenia, Abraham Volt, stwierdził, że hej, ale te samoloty wróciły, więc te postrzelenia wyraźnie nie były krytyczne. Trzeba wzmacniać to, gdzie dziur po kulach nie ma, bo jeżeli tam zostały trafione, no to samolot nie wrócił, czyli danych po prostu nie było i w efekcie wtedy się nauczono, że należy wzmacniać skrzydła i zbiorniki paliwa, kokpit i tym podobne. Tam nie było dziur, bo jeżeli tam został samolot trafiony, no to kaplica. Kolejny przykład, bardzo podobny, już nie origin story, to słynny mit Harvard Dropout, że najlepsi na świecie, najbogatsi na świecie nie skończyli studiów, odeszli z Harvardu i jakoś im się udało. Bardzo często podajemy tu przykład Billa Gatesa, trochę rzadziej, ale też wymieniamy Marka Zuckerberga, który też nie skończył Harvardu, że patrzcie, udało się. Ale jak popatrzymy na dane, to każdego roku Harvard to akurat całkiem niski współczynnik dropał, ten 3%, to ile dobrze pamiętam, czyli około 50 osób rocznie, ale nawet licząc te 3% i 50 osób rocznie, to w ciągu ostatnich dwóch dekad było tysiąc osób, które odeszły z Harvardu i oni wszyscy nie są milionerami. Mamy dwa przypadki, którym się udało, a i tysiąc osób, które nie wylądowały na czołówkach gazet, nie są miliarderami, nie prowadzą tech-toków i tak dalej, więc… Skupienie się na sukcesie z automatu nam wycina zdecydowaną większość historii, która być może bardziej ciekawa, bardziej atrakcyjna i łatwiejsza, tak jak powiedziałem wcześniej, łatwiejsza do może nie zreplikowania, bo nie chcielibyśmy replikować porażek, ale przynajmniej uniknięcia.

Krzysztof:
Właśnie, bo to jest pewnie też coś takiego, że tym osobom udało się nie dzięki temu, że odeszły z Helwardu, ale być może i pomimo. To też jest pewnie inna perspektywa. Wspomniałeś tutaj o postmortem jako takiej wartościowej praktyce, którą według ciebie powinna być nawet pewnie częściej gdzieś tam faktycznie używana przez firmy, może być kluczowa, a która po prostu polega na przeanalizowaniu, co tam się pod spodem nie udało i wyciągnięciu z tego jakichś względów, jakichś wniosków, które możemy później zaaplikować do naszej organizacji, do naszych procesów, procesów po to, żeby ulepszyć, po to, żeby ta sytuacja nie miała miejsca ponownie. Natomiast chciałbym cię zapytać o to podejście do postmortem, mianowicie chodzi mi o to, że możemy tutaj łatwo przejść w taki tryb oceniania, łatwo przejść w tryb zrzucania odpowiedzialności na kogoś, co może być miażdżące wręcz dla całego zespołu, a pewnie też i położyć firmę, jeśli jest praktykowany w jakimś tam ekstremum. Jak ty patrzysz na właśnie takie blameless podejście do postmortem?

Adam:
Ja jestem wielkim zwolennikiem blameless. Z jednej strony jest taka powiedzmy żartobliwa anegdota, że jeżeli ktoś wywalił produkcyjną bazę danych przez głupią komendę, to możesz być w stu procentach pewny, że drugi raz tego nie zrobi, więc w karanie nie ma wielkiego sensu. ale nie chodzi o anegdotę, chodzi o, psychologiczny, powiedzmy, aspekt tego, co się dzieje, kiedy zaczynamy obwiniać. Kiedy obwiniamy, kiedy wiemy, że kiedy boimy się odpowiedzialności za popełnienie wpadki, a jesteśmy tylko ludźmi, to to nie znaczy, że przestaniemy popełniać błędy, po prostu zaczniemy je lepiej ukrywać i tak ten błąd się wydarzy i tak trzeba będzie coś naprawić. Tyle tylko, że zostanie wykryty być może na znacznie późniejszym etapie, a szukanie przyczyny potrwa więcej i będzie kosztować więcej. Ale jest jeszcze jeden aspekt. Tak, mamy tendencję do znalezienia winnego ukarania i stwierdzenia, że wszystko w porządku, ale jeżeli przyjmiemy założenie, moim zdaniem bardzo słuszne, że wszyscy pracujemy do wspólnej bramki, są czasami złe intencje, ale to jest ekstremum, systemowo tak trzeba się zabezpieczyć, ale nie uznałbym tego za większość. Więc jeżeli wszyscy chcemy pchnąć organizację, projekt do przodu, wszyscy chcą robić jak najlepiej, być może się nie rozumieją, być może trochę inaczej interpretują, ale jednak, to pytanie nie brzmi, dlaczego ten gość jest winny wywalenia produkcyjnej bazy danych, literówki, skasowania backupu czy czegokolwiek tego typu. Ważniejsze jest pytanie, dlaczego system zaprojektowany do bycia używanym przez ludzi, którzy z definicji są omylni, pozwolił na taki błąd. Czyli jeżeli tylko przesuniemy z szukania winnego na szukanie przyczyny, możemy się na to zabezpieczyć. Jasne, możemy powiedzieć, że Krzysiek czy Tomek czy inny Adam skasował bazę danych. Nie ukrywajmy tego, to jeszcze nie jest obwinianie, to jest stwierdzenie faktu, ale zamiast skupiać się jak należy Adama ukarać za to, że skasował bazę danych i tak zdarzyło mi się to w karierze.

Adam:
Lepiej zapytać, Co w systemie pozwoliło jednemu człowiekowi na doprowadzenie do takiej katastrofy przez głupią literówkę czy pomieniań, czy tak jak w moim przypadku, co opisuję w książce, nie będę się tego wstydził, pomylenie terminalu, gdzie odpalona została komenda Drop Database.

Krzysztof:
Zdarza się nawet najlepszym. Myślę sobie, że to też nie można popadać w żadną skrajność. Oczywiście karanie to nie ma żadnego sensu, bo tak jak powiedziałeś, jeśli coś faktycznie poszło źle to ta osoba pewnie czuje się wewnątrz już na tyle samoukarana, że nie powtórzy tego ponownie, tak jak wskazałeś z drugiej strony udawanie, że nic się nie stało, że faktycznie pomijanie niejako tego aspektu, że ktoś to fizycznie gdzieś tam klepnął enter w tym terminalu też jest złe, no myślę, że taka zdrowa zdrowy balans jest potrzebny.

Adam:
Tak, tylko, że znowu dlatego powiedziałem nie ukrywajmy, że hej Bołw czy inny Adam usunął bazę dań. To jest fakt, który należy przeanalizować, ale to nie jest przyczyna. System po prostu generalnie musimy przyjąć do wiadomości i być może to jest dla kogoś zaskakujące, nie sądzę, że ludzie są omylni, że pracujemy pod presją czasu, że czasami jesteśmy zmęczeni, myślimy o nie wiem, kłótni z partnerem życiowym poprzedniego wieczoru, czy o tym, że że w popołudniu będzie fajna misja w Baldur’s Gate. Nieważne. Każdy człowiek to ma i to musimy przyjąć za pewnik. Czasami to jest też kwestia po prostu braku wiedzy. Tylko, że jeżeli zatrzymamy się na tym etapie, to tak naprawdę nie naprawimy problemu. Pytanie, drążenie głębiej do znalezienia, co mogło być zaprojektowane w procesie, systemie, cokolwiek lepiej, Tak, żeby następnym razem, jak ktoś po prostu dotrze do pracy nie pijąc porannej kawę, żeby nie popełnił tego samego błędu drugi raz. Prosty przykład, to akurat jest dosyć świeże, opisuję w drugim tomie. Kilka lat temu trafiła się sytuacja, kiedy ktoś przez pomyłkę wywołał na Hawajach alarm. Zamiast próbnego alarmu kliknął przycisk wywołania bombowego alarmu i przez 40 minut całe Hawaje chowały się w schronach przeciwpoatomowych. I tak, to był błąd. Ale kiedy przeanalizowano, co się wydarzyło, okazało się, że interfejs to był prosty HTML z linkami jeden po drugim. Linki w żaden sposób nie zhierarchizowane, w żaden sposób nieróżniące się od siebie. Co więcej, komunikat potwierdzenia, czy chcesz wywołać ten komunikat. Brzmiał, czy na pewno chcesz wywołać ten komunikat, bez nawet potwierdzenia, co kliknąłeś. Więc miałeś jeden po drugim, wywołaj próbny alarm, wywołaj prawdziwy alarm, no i… Człowiekowi się kliknęło źle. Brzmi absurdalnie, ale naprawdę się wydarzyło.

Krzysztof:
No tak, trudno tutaj pewnie obwiniać tego biednego człowieka, bo o pomyłkę niezwykle łatwo. Zacząłeś mówić o tym szukaniu przyczyny źródłowej, tak, root cause analizy, która jest niezwykle istotna. To jest, nie wiem czy się ze mną zgodzisz, według mnie taki trochę brakujący element w tej analizie, którą właśnie widzimy ze strony jakichś tam startupów, dużych big techów i tak dalej, kiedy podają nam, że coś tam się złego nie wydarzyło, tam często są takie techniczne aspekty tylko danego problemu. Brakuje takiego zejścia głębiej albo wyjścia poza technologię. Czym według ciebie charakteryzuje się taki dobry właśnie root cause analysis?

Adam:
Może zacznę od obrony tych startupów czy firm, które skupiają się na technologii. Zwróćmy uwagę, że błędy w procesach to nie jest coś, co powinno być publiczne. Ja jestem w stu procentach przekonany, że przynajmniej te najlepsze firmy w branży. Mają oddzielne raporty publiczne, być może mają też oddzielne takie pół publiczne dla swoich głównych klientów i to, co wewnętrznie, gdzie można powiedzieć, że hej, Bob, kliknął zły przycisk i jak temu zapobiec, to już się przekłada na konkretny backlog, plany biznesowe i tak dalej, to nie będzie publiczna, więc nie przeskakiwałbym do wniosku, że tylko dlatego, że w tych publicznych raportach tego nie ma, te firmy tego nie robią. Ale wracając do Twojego pytania, Rutko z analizy moim zdaniem powinno się skupić właśnie na znalezieniu przyczyny systemowej, nie technicznym aspekcie, jak zapomnieliśmy o testach, tylko właśnie drążyć dalej, dlaczego pozwoliliśmy zapomnieć o tych testach, co w procesie nie zadziałało. Czyli jedna z poszczególnych technik, tak zwane 5Y, czyli zabawa, taka dorosła wersja zabawa w dziecko, czyli a dlaczego? Tylko z głową. I tutaj nazwa techniki mówi o 5Y i widziałem wielokrotnie sytuację, kiedy ktoś się za bardzo zafiksował na liczbie 5, zamiast na tym, jaki jest faktyczny cel procesu, czyli pytamy tak długo, aż znajdziemy faktyczne action album, nie jestem pewny, jak będzie po polsku w tym momencie. Powód, co poszło nie tak. Bardzo prosty przykład, który lubię przytaczać, to jest, nie wiem, spóźniłeś się na spotkanie. Dlaczego? No bo utknąłem w korku. A dlaczego utknąłeś w korku zamiast wyjechać wcześniej? No bo zaspałem. A dlaczego zaspałem? Dlaczego zaspałeś? No bo wczoraj wieczorem oglądałem serial na Netflixie i poszedłem za późno spać. W tym momencie powód, który pozornie jest, że spóźniłem się, bo otknąłem w korku, tak, to jest techniczna przyczyna, ale faktyczne źródło problemu to nie jest kwestia tego, że są korki, no bo tak są korki, hello, XXI wiek. Przyczyną jest kiepska dyscyplina i zarządzanie własnym czasem dzień wcześniej. Tak moglibyśmy ciągnąć dalej, jeżeli doszliśmy do wyników w trzech pytaniach, moglibyśmy dążyć dalej. A dlaczego oglądali za długo? Bo serial był świetny, a dlaczego był świetny? No bo scenarżysta jest dobry. Tylko, że znowu, tak możemy drążyć, tylko dojdziemy do tego, że aha, ktoś gdzieś w San Francisco czy innym Los Angeles napisał świetny scenariusz. Co możemy z tym zrobić? No w sumie nikt. Więc musimy znaleźć też taki zdrowy rozsąd, pamiętać o zdrowym rozsądku i z jednej strony drążyć do momentu znalezienia przyczyny, z drugiej strony nie drążyć za długo, żeby przypadkiem nie rozmyć odpowiedzialności do absurdu.

Krzysztof:
Rozmawiamy dzisiaj o błędach, wpadkach, różnych problemach w IT i tak sobie myślę, że być może jednym z powodów, dlaczego tak się dzieje, jest to, że tworzymy systemy nadmiernie skomplikowane, nadmiernie złożone, które niekoniecznie musiałyby takie być. Ale za tym idzie pytanie, czy aby nie jest tak, że tworzenie tych prostych rozwiązań jest trudne, dlatego tego nie robimy?

Adam:
Oczywiście, że jest trudne. To może brzmieć w pierwszej chwili abstrakcyjnie, ale tak, tworzenie prostych rozwiązań jest nieporównywalnie trudniejsze niż skomplikowanych, dlatego że. I to jest wiele poziomów tak naprawdę. Przede wszystkim i żeby zaprojektować prosty system, proste rozwiązanie jakiegoś problemu, musimy ten problem zrozumieć od początku do końca, co wcale nie jest proste w współczesnych realiach. Dużo prościej jest zacząć z POC, potem MVP, a potem dobudowywać obsługę warunków brzegowych i coś z tego wyjdzie. Ja lubię to porównywać do projektu Taj Mahal. Wyobraźmy sobie, co by się stało, gdyby Ustad Lahori, to był projektant Taj Mahal, stwierdził, dobra, najpierw postawmy schowek na miotły, a później dobudowujmy w miarę potrzeby. Zamiast cudu świata dostalibyśmy jakieś monstrum z różnych materiałów, w różnych stylach itd., raczej niekoniecznie to, co byśmy chcieli. Dopiero kiedy projektant podszedł do problemu kompleksowo, zrozumiał jaki jest cel i ogólny przewidywany rozmiar, możliwe było zaprojektowanie czegoś tak prosto, jak się dało. To jest jeden raz. Drugi jest taki, że też nie oszukujmy się, nie możemy wszystkiego projektować od A do Z. W obecnych czasach zmieniających się dosłownie z godziny na godzinę nie jest to takie proste, delikatnie mówiąc, ale też brakuje nam swoistej odwagi do usuwania czegoś, co już zrobiliśmy, czyli. Łatwiej jest dobudować, trudniej jest zrobić krok wstecz i stwierdzić, ok, tego już nie potrzebujemy. Czyli gdybyśmy to porównali znowu do architektury. Zaczynamy od zbudowania jednopokojowej chałupy, dobudujemy później salon, w miarę jak budżet pozwoli, dobudujemy kuchnię, schowek, sypialni itd., Ale czasami, żeby projekt pozostał spójny, konieczne jest stwierdzenie, aha, dobra, to pomieszczenie już nie pasuje, musimy je wyburzyć i zbudować w jego miejsce coś większego, tak żeby ominąć pustą przestrzeń, która by powstała. To usunięcie czegoś, co już nie pasuje, jest dużo trudniejsze niż stwierdzenie, aha, ale to działa i kontynuuje. I w zasadzie dostajemy coś, co nawet nie ewoluuje, tylko pączkuje w sposób niemal kancerogenny.

Krzysztof:
Tak, rośnie przez bąbelkowanie. No właśnie, przywiązujemy też się do tych naszych rozwiązań, które tworzymy. Zaczynamy je traktować bardzo osobiście, dlatego pewnie z trudnością pozwalamy sobie na usuwanie czegoś, no bo to jest jakbyś sobie odcinał część ciała wręcz niemalże. Znam takie osoby, które tak bardzo się utożsamiają z tym swoim kodem, że trudno im przysłowiowo zaorać wcześniejsze rozwiązanie. Tak, tworzenie tych rozwiązań to jest jak gdyby jedno, ale najczęściej my, albo prawie zawsze, oprócz samego budowania, musimy również technologię wyjaśniać, tłumaczyć. Chociażby użytkownikom końcowym, chociażby jakimś innym osobom nietechnicznym wewnątrz organizacji, które to osoby również są zaangażowane wytwarzanie na przykład kolejnych feature’ów i tutaj również pojawia się takie pole trochę do popełniania błędów, do jakichś fuck-upów, do naszej takiej nieumiejętności prostej, prostego wytłumaczenia technologii. Jak myślisz, dlaczego tak się dzieje, że jako osoby, które wydawało mi się, że powinniśmy rozumieć tą technologię, to głębnie, jednak mamy trudność i problem z jej łatwym wytłumaczeniem.

Adam:
Dlatego, że znowu, tłumaczenie łatwe jest trudne. Z jednej strony to wymaga pewnej dozy, powiedzmy, empatii, żeby pamiętać, że nie każdy rozmówca wie to, co my. Ludzie, typowo inżynierowie oprogramowania, mogą być świetni, jeśli chodzi o wzorce projektowe, architektury, być może cloud computing itd., ale niekoniecznie rozumieją biznesowe realia i w drugą stronę. Ktoś może rozumieć biznesowe realia problemu, ale pogubi się w terminologii. To jest jeden aflo. Ale drugi, znacznie ciekawszy moim zdaniem, jest to, że używanie, tłumaczenie w sposób skomplikowany z jednej strony daje nam obronę albo iluzję tego, że brzmimy mądrzej, więc lepiej tak to powiedzieć, ale z drugiej tak naprawdę rozmywa odpowiedzialność za komunikat. Bo zwróćmy uwagę, ja bardzo lubię ten przykład, jeżeli byśmy powiedzieli, nie wiem, co to jest Kubernetes, można by powiedzieć, że to jest orkiestrator, który skeduluje pody w klastrze komputerów, bla, bla, bla. Jasne, to wszystko się zgadza i wiem, że to zaprzymało dziwnie, dużo łatwiej byłoby mi powiedzieć po angielsku. Tylko, że zwróćmy uwagę, że tak naprawdę tylko to, że ja to powiem, nie znaczy, że ja wiem, co to jest orkiestrator. Tak naprawdę przekazuję odpowiedzialność za zrozumienie terminologii na odbiorcę komunikatu, a nie biorę na siebie odpowiedzialności za wyjaśnienie, co ja mam na myśli. Czyli tak naprawdę do końca nie wiadomo, czy w momencie, kiedy rzuciłem jakieś tego typu zdanie, czy ja rozumiem, o czym mówię, czy tylko się wynauczyłem formułki z Wikipedii czy innej dokumentacji. W momencie, kiedy połączymy empatię i wzięcie odpowiedzialności za jasność komunikatu, okazuje się, że nie mamy gdzie się schować i musimy wyjaśnić, co mamy na myśli, tak żeby rozmówca to zrozumiał. To jest dużo trudniejsze, zarówno koncepcyjnie, jak i, To pewnego stopnia psychologicznie wzięcie większej odpowiedzialności na siebie nie jest proste. Z tego powodu ja na przykład bardzo lubię na rozmowach rekrutacyjnych w platformę engineeringu czy na DevOpsa czy coś tego typu zadać pytanie, wyjaśnij mi, ale tak jakbym był pięciolatkiem, jaka jest różnica między kontenerem a maszyną wirtualną. Jestem i gwarantuję, 9 na 10 jak mniej więcej kandydatów jest w stanie to wyjaśnić w sposób techniczny, używając żargonu, terminologii i tak dalej. Ale kiedy narzucę limit, ale wyjaśnij mi to tak, jakbym był pięciolatkiem i nie rozumiem, o czym do mnie mówisz, to nagle to się okazuje dużo trudniejsze, bo nagle zaczynają pojawiać się, szczeliny w samym zrozumieniu przez osobę, która mi to miała to wytłumaczyć.

Krzysztof:
To wzięcie odpowiedzialności na siebie za komunikat to jest myślę tutaj klucz niepoleganie na tym, że wydaje nam się, że inni też wiedzą to, co my wiemy. No tak, cała pewnie tutaj teoria lepszej komunikacji się kłania. Ja natomiast chciałbym zapytać cię w kontekście automatyzacji, która dosyć mocno nam wkroczyła na salony w przeróżnych aspektach IT. Czy według ciebie to jest dobry trend w takim rozumieniu, że potencjalnie pozwoli uniknąć jakichś błędów i problemów, czy też może wręcz przeciwnie spowoduje, że zamkniemy się w tych naszych swoich bańkach i nie będziemy w stanie robić więcej niż dana automatyzacja pozwala, niż te założenia, które służyły do jej stworzenia pozwalają.

Adam:
Uch, to jest bardzo ciekawe i wielopoziomowe pytanie, ponieważ z jednej strony, czy automatyzacja jest dobra? Tak, oczywiście, że jest dobra. Z drugiej, czy pozwoli uniknąć błędów? Wielu na pewno No tak, ale nie wszystkich, a wręcz przeciwnie, stworzy nowe błędy. Nawet to jest… Co się nazywa paradoks automatyzacji, gdzie tak naprawdę im więcej, im lepszy system zbudujemy do automatyzacji, tym mniej dajemy możliwości użytkownikom tego systemu ćwiczenia w regularnych sytuacjach, więc zabieramy możliwość treningu, a później oczekujemy, że jeżeli ta automatyzacja się wyspie, to natychmiast będą wiedzieć, co robić. No nie, tak to nie działa, więc z tej perspektywy tworzy się cały nowy obszar problemów i wyzwań, jak temu zaradzić. To jest jedna rzecz. Druga, nawet ciekawsza, jest taka, i to jest powiązane z jeszcze innym paradoksem, można zauważyć, że lubię patrzeć w historię, żeby tłumaczyć co się dzieje obecnie. Nazywa się to paradoksem produktywności, termin okroty w latach 80., ale mechanizm jest starszy, że tak naprawdę nowa technologia nie powoduje wzrostu produktywności od razu. W latach 80. Nie pamiętam teraz kto to stwierdził, ale stwierdził coś w rodzaju, że komputeryzację widać wszędzie z wyjątkiem wyników produktywności i faktycznie jak się popatrzy na statystyki z lat 80. i 90. To prawda, ale wynikało z tego, że wprowadzono nową technologię, oczekiwano nowej jakości, ale nie zmieniono procesów, które by wspierały tę technologię. To samo było z elektryfikacją, opóźnienie pomiędzy wynalezieniem silnika elektrycznego albo nawet próbą wprowadzenia go w przemyśle, a faktycznymi korzyściami wyniosło około 20-30 lat. Na przełomie XIX i XX wieku i wynikało z tego, że po prostu próbowano zastąpić jedną centralną maszynę parową ogromnym silnikiem elektrycznym w halach produkcyjnych i spodziewano się cudu. Potrzebne były dosłownie dwie, dwie i pół dekady na totalne przeprojektowanie hal produkcyjnych, zastąpienie jednej centralnej drogiej i nieefektywnej maszyny parowej, znacznie mniejszymi, tańszymi silnikami przy stanowiskach produkcyjnych, które wymagało przeprojektowania całej hali produkcyjnej. Dopiero kiedy to się wydarzyło, ten boost produktywności nastąpi. Dokładnie to teraz obserwujemy moim zdaniem z IT, gdzie z jednej strony wprowadzamy automatyzację procesu wytwarzania kodu, czyli tych linii kodu, ale z drugiej strony zakładamy, że wszystko wokół będzie działać tak samo. W praktyce tak, wytwarzanie kodu stało się dużo prostsze, dużo szybsze, ale sam proces projektowania rozwiązania wcale nie zrobił się proporcjonalnie mniejszy. Etap weryfikacji testowania tego rozwiązania nie tylko nie stał się mniejszy, ale stał się dużo trudniejszy, dużo bardziej skomplikowany i dużo istotniejszy niż był jeszcze nie wiem, pięć lat temu. Czyli tak, wprowadzenie automatyzacji, spowoduje wzrost produktywności, ale zanim to naprawdę nastąpi w sposób mierzalny, musimy zmienić całą fabrykę, całą linię produkcyjną procesu wytwarzania oprogramowania i zrozumieć, że to, co było naszą operacją dominującą, jeśli mówimy takim żargonem IT, czyli wytwarzanie kodu, przestało być operacją dominującą, nową jest być może weryfikacja, walidacja rozwiązania i przez ten pryzmat powinniśmy oceniać. To wywraca do góry nogami wszystkie procesy, jakie istnieją w organizacjach być może, ale musi nastąpić zanim ta produktywność wzrośnie.

Krzysztof:
Wiem już, że nie da się zupełnie wyeliminować wszystkich błędów, problemów. One są gdzieś tam imanentne, wpisane po prostu w technologie, w systemy, które mogą być wadliwe, mogą po prostu mieć jakieś swoje problemy, problemy, co potem przekłada się na pozostałe. To wcale nie znaczy, że jednak nie powinniśmy dążyć do jakiegoś zminimalizowania albo wykluczenia problemów, tych błędów, które po prostu da się w jakiś sposób gdzieś tam usunąć. I czy według ciebie, aby w ogóle mówić, aby w ogóle myśleć o takim minimalizowaniu tych błędów, to trzeba przede wszystkim mieć bardzo dogłębną, wynikliwą wiedzę na temat technikaliów na przykład danej technologii, aby wiedzieć, gdzie tam potencjalne problemy mogą wystąpić. Być może wiedzę na temat ograniczeń danej technologii, gdzie ona się nie sprawdza, jakie problemy mogą nastąpić na jakichś skrajach działania tej technologii a wręcz może kompletnie nie w technologii jest problem, a raczej wiedza o tym jak ludzie działają, ludzie się komunikują i gdzie mają te swoje ułemności jest niezbędna, żeby w ogóle o tym eliminowaniu błędów mówić co jest według ciebie najistotniejsze

Adam:
I to by była w zasadzie cała odpowiedź, ale głębiej no nie oszukujmy się rozumienie technologii, technikaliów, ograniczeń technologii jest ważne. To nie ulega wątpliwości i być może gdybyś mnie spytał jeszcze kilka miesięcy albo rok temu, to może bym nawet był w stanie stwierdzić, że to jest najważniejsze. Obecnie jednak skłaniam się ku stwierdzeniu, że może jednak rozumienie ludzkiej natury jest co najmniej równie ważne, jeśli nie ważniejsze. Dlatego, że tak jak powiedziałem, technologia się zmienia szybciej niż jesteśmy w stanie nadążyć tak naprawdę, tylko w czasie mojej kariery paradygmat. Oprogramowania został przewrócony co najmniej trzykrotnie do góry nogami, a błędy i koncepcje pozostają. Tak naprawdę nawet ostatnio napisałem całkiem głębszą analizę o technocentryzmie, czyli roli AI w prawach autorskich, dostępna na moim blogu, ale nie będę się tu reklamował. I co zauważyłem, to to, że praktycznie wszystkie techniki związane z ochroną praw autorskich są, naprawdę bardzo stare i sięgają nawet czasów starożytnej Grecji albo i lepiej. Tak, technologia stojąca za tym oczywiście się zmieniła, ekonomia samego procesu jak najbardziej, ale koncepcje są te same. Więc. Jakkolwiek techniczne rozumienie koncepcji technologii, ograniczeń tych technologii jest ważne, tak jeśli chodzi o długofalowe rozumienie natury błędów i tego jak ich unikać, raczej skłaniałbym się już teraz bardziej ku stwierdzeniu, że to zrozumienie ludzkiej psychiki i naszych własnych ograniczeń jest może nie ważniejsze, ale co najmniej równie ważne.

Krzysztof:
Czy AI tutaj wywraca stolik, a może jeszcze bardziej dokłada się do tego, że powinniśmy lepiej rozumieć człowieka? Oczywiście w kontekście, tutaj mówimy, błędów, fuck-upów tych naszych rozwiązań IT, czy dzięki temu, że stosujemy tego typu rozwiązania, to możemy uniknąć więcej potencjalnych błędów, czy też może wręcz przeciwnie, dokładamy sobie kolejnych jeszcze na nasz talerz?

Adam:
Jakkolwiek cenię technologię AI, tak raczej byłbym w stanie skłonny do stwierdzenia, że nie unikniemy błędów. Te modele AI wciąż są tworzone przez ludzi, więc nabierają tych samych problemów i ograniczeń, które my mamy. Nawet też dosyć mocno o tym w drugim tomie Faklopalmanak pisze. Więc nie jest tak, że są projektowane przez socjopatów, którzy nie mają ludzkich ograniczeń. To jest jedna rzecz. Automatyzujemy, czyli jeszcze dokładamy czynnik skali, dokładamy element paradoksu automatyzacji, o którym trącimy, wspomniałem, i jeszcze na dokładkę dodajemy skalę, z którą ludzie nie są w stanie już sobie poradzić, więc jakkolwiek wiele błędów, które się trafiały, być może zostanie wyeliminowanych, te najbardziej. Krytyczne, pozostają, zostaną zautomatyzowane i jeszcze tworzymy nową kategorię. To jest moim zdaniem, ale tak jak mówię, cenię AI, nie chcę tutaj brzmieć jak defetysta i zaorajmy wszystko, zaraz będzie Skynet. Po prostu zdawajmy sobie sprawę z tego, jak to działa i jakie są ryzyka ograniczenia koszta. I znowu historia nam to bardzo fajnie pokazuje, że wynalezienie silnika spalinowego i zastąpienie koni wcale nie wyeliminowało wszystkich problemów, część pozostała, ale stworzyła też zupełnie nowe, co wcale nie oznacza, że technologia wcale nie była wyeliminowana. Na koniec dnia wartościowa dla rozwoju ekonomii, społeczeństw i tak dalej. Podobnie będzie z AI. Część problemów przestanie istnieć, część pozostanie, bo po prostu to jest w naszej naturze, a nowe już zaczynamy odkrywać powiedzmy.

Krzysztof:
Dokładnie i pewnie wiele z nich będzie z nami jeszcze szło, niezależnie od tego, jak bardzo te technologie będą się zmieniać, się rozwijać, przechodzić w coś zupełnie innego, o czym nawet ciężko teraz pomyśleć, bo chociażby dlatego, że są tworzone przez ludzi, tak jak powiedziałeś, niejako cementują tą naszą naturę. Zdecydowałeś się napisać o tym serię książek. Może krótko opowiedz proszę, o czym jest ta seria? Dlaczego w ogóle taka decyzja, żeby ten temat poruszyć?

Adam:
Bez zagłębiania się w zbyt wiele detali, żeby nie zanudzić tutaj słuchaczy, ale początkowo nawet nie myślałem o pisaniu książki, chciałem zrobić cały krótki przegląd, ciekawych historii jako promocji mojej poprzedniej książki. Tyle tylko, jako powiedzmy tak, wykorzystać tendencję albo do tego, że wszyscy lubimy, mamy tendencję do Schadenfreunde i do tego, że to jest chwytliwe i tak dalej, tylko, że bardzo szybko zrozumiałem, że temat jest zbyt głęboki i zbyt bogaty, żeby nie zagłębić się jeszcze bardziej. Uznałem, że to zasługuje na książkę. Tylko, że jak zrozumiałem, że tego będzie więcej niż kilkadziesiąt stron, początkowo myślałem, że wyjdzie może z 400-500 stron książka, to zrozumiałem, że sam przegląd historii, ha ha, patrzcie, zepsuło się, nie uzasadnia z jednej strony mojego czasu, a z drugiej, może nawet co ważniejsze, czytelnika czasu, żeby poświęcić czas, energię i pieniądze na przeczytanie pięciuset katastrof, więc zacząłem szukać skąd to się bierze, analizować i chciałem to zrobić bardziej przystępnym dla jak najszedszego grona odbiorców. W związku z czym zamiast tłumaczyć, popatrzcie, nie wiem, cały szwedzki internet zniknął z internetu na dwa dni, tak stało się, musiałem wyjaśnić dlaczego, a żeby to wyjaśnić, musiałem wyjaśnić po pierwsze, co to jest DNS i co to jest DNS-C. I znowu mógłbym tutaj syknąć dokumentacją, ale jeżeli to ma być krótkie wprowadzenie do technologii, no to albo bym zrobił to zbyt nudne i wciąż na tyle powierzchowne, że specjalista i tak by stwierdził, że przeczyta RFC i będzie wiedział więcej. Albo zrobię to na tyle pełne żargonu i technikaliów że ktoś kto nie ma o tym pojęcia i tak nie będzie miał o tym pojęcia bo albo nie zrozumie, albo uzna, że to nudne więc musiałem znaleźć zupełnie inne podejście jak to zrobić ciekawe więc jest całkiem sporo właśnie takich wyjaśnień, tak żeby i to nawet sprawdziłem na 14-letnim siostrzeńcu że tak przeczytał i zrozumiał więc z drugiej strony sprawdziłem na wykładowcy jednej z uczelni publicznych technicznych w Polsce. Też przeczytał, oczywiście celem tutaj nie było, żeby zrozumiał, to by było trochę obraźliwe. Celem było, żeby uznał, że to jest wystarczająco dokładne i. Że odzwierciedlało realia i tak ten cel się udało osiągnąć. Dopiero mając taką bazę byłem w stanie opisać parę historii, które jeszcze lepiej obrazują, jak dany aspekt technologii działa, tylko że w miarę jak zacząłem się zastanawiać, co jeszcze wypadałoby wyjaśnić, no to z 400 stron zrobiło się sporo więcej, no i tak jak wspomniałeś, wychodzi z tego planowany cykl czterech tomów, więcej nie będzie na razie, bo wystarczy tego scope creepu, ale każdy z nich będzie miał około 400-500 stron, więc jest dużo materiału, dużo ciekawego materiału. Mam nadzieję, że ciekawego nie tylko na mnie. Najpierwsze opinie sugerują, że chyba się udało.

Krzysztof:
Super, to już oczywiście gratuluję i na tyle, na ile Cię znam, to jestem przekonany, że to nie jest Twoje ostatnie słowo. Za dzisiejszą rozmowę bardzo Ci dziękuję. powiedz jeszcze proszę, gdzie Cię możemy znaleźć w internecie, gdzie możemy też książki, które już się ukazały i które jeszcze dopełnią ten cykl znaleźć.

Adam:
Więc najprostszym miejscem, że tak powiem pierwszym kontaktu jest moja strona internetowa www.adam.com, tam są informacje i o książkach i moje inne przemyślenie, powiedzmy jeżeli można to tak nazwać, przemyślenia i rozkminy w postaci bloga, możliwości zapisu do newslettera, linku do Linkedin, gdzie piszę jeszcze więcej, gdzie leję jeszcze więcej wody i tam też są linki do, gdzie można kupić, ale najprostsza odpowiedź na ten moment to jest Amazon, to jest Selfpub, więc na razie jest, więc to jest główny kanał, Jest dostępny w pewnych księgarniach internetowych, ale nie mam na to wielkiego wpływu, więc Amazon to jest najlepsza ścieżka w tym momencie.

Krzysztof:
Świetnie. Oczywiście wszystkie linki w notaci do tego odcinka się znajdą, a ja Tobie jeszcze raz dziękuję za tę rozmowę. Do usłyszenia.

Adam:
Dzięki wielkie.

Krzysztof:
To już wszystko na dzisiaj. Jeśli chcesz więcej takich rozmów, Archiwum czeka. Tam też dzieją się ciekawe rzeczy. Masz pytania? Przemyślenia? Możesz się ze mną skontaktować na social mediach lub mailowo na krzysztof@porozmawiajmyoit.pl Nazywam się Krzysztof Kempiński, a to był odcinek Porozmawiajmy.IT o tym, że systemy IT się psują i czego nas douczy. Do usłyszenia w kolejnym odcinku. Cześć!