Patoarchitekci Short #33: Po wakacyjnej przerwie startujemy z nowym sezonem Patoarchitektów. Będzie się działo. Na początek kilka dram min. zmiana licencji w HashiCorp czy sponsor link w Moq. Omówimy też Stack Overflow i spadek wejść o 35% (sic!), a na deser zostawiiliśmy sobie hejt na raporcie McKinsey o absurdalnych metodach mierzenia wydajności developerów. Startujemy!
Słuchasz Patoarchitektów dzięki Protopii. Sprawdź, jak Patoarchitekci i Protopia mogą Ci pomóc ➡️ protopia.tech
Linki i ciekawe znaleziska:
Szymon Warda: Cześć, słuchacie Patoarchitektów!
Łukasz Kałużny: Prowadzą Szymon Warda i Łukasz Kałużny. Wszystkie linki do tego odcinka znajdziecie na patoarchitekci.io albo gdzieś tu na dole w playerze, z którego słuchacie. To co, zaczynamy po wakacjach, Szymonie?
Szymon Warda: Zaczynamy. I skoro to jest nowy sezon, bo tak, sezonujemy teraz nasze wydania.
Łukasz Kałużny: Tak, trzy albo trzy i pół po twojemu.
Szymon Warda: Tak, dokładnie, były różne przejścia w historii, ale mamy pewne cele. A jakie cele to są? To są takie, że chcielibyśmy, aby nasza społeczność, nazwijmy to tak chyba, rosła. Więc. Pato to the moon, więc dajcie lajka, suba, cokolwiek generalnie powiedzcie znajomym, wyślijcie babci, mamie, ktokolwiek tak naprawdę, through the world. Tyle. Lecimy z tematami, bo się tego trochę pozbierało.
Łukasz Kałużny: Czyli co? Dramy w open source na start?
Szymon Warda: Zdecydowanie tak, bo są dwie dramy równoległe i całkiem ciekawie się tam dzieje tak naprawdę.
Łukasz Kałużny: Wiesz co? To zacznijmy od HashiCorpu, bo to jest ciekawy temat. HashiCorp zorientował się, że za bardzo jest dymany na pieniądze, bo chyba tak można to określić.
Szymon Warda: Tak, tak trzeba.
Łukasz Kałużny: Czyli jest grupa firm, która zaczęła budować rozwiązania SaaS-owe wokół Terraforma, bo to głównie Terraforma i o to się opiera teraz cała drama. Właśnie rozwiązania SaaS-owe, które konkurują między innymi z Terraformem Cloudem, jeżeli chodzi o sposób użycia samego Terraforma.
Szymon Warda: Wtrąćmy czym jest Terraform Cloud? To jest Offering Terraforma, czyli Corpo właściwie, do przechowywania i zarządzania dostępem do pliku stanu Terraforma i który wcale nie jest taki tani. Tam wychodziło chyba $7-9 za usera.
Łukasz Kałużny: Tak, albo za resource godzino-resource. Oczywiście jeszcze tam jest też możliwe CI/CD i inne takie elementy. Więc cała platforma i to co zrobił HashiCorp to we wszystkich swoich produktach, zgodnie z tradycją z ostatnich lat, zmienił licencję na klasycznego, pięknego BSL-a i de facto z całej tej dramy i się teraz parę firm oburzyło oczywiście, które zarabiały na tym i podniesiono, że zbudują Open Terraforma, który będzie oddany do CNC, bo takie wielkie tutaj założenia. Kurde i dla mnie to Szymon jest bullshit.
Szymon Warda: A ja… no mieliśmy o tym rozmowę wcześniej, wczoraj. Dla mnie - rozwińmy HashiCorpa jak najbardziej, bo licencja BSL mówi, że możesz korzystać z Terraforma, ale nie możesz tego produkcyjnie wykorzystywać, budować produktu i potem korzystać z niego produkcyjnie.
Łukasz Kałużny: Tak, licencja jest częściowo niejasna. Zgodzę się do jednego, że firmy muszą wyjaśnić bardziej licencję, kto jest integratorem, a kto jest konkurencją.
Szymon Warda: Tak, i kto korzysta z tego, na bazie czego buduje. Czyli załóżmy, ja dając jakiś dowolny produkt, korzystając z Terraforma, mogę z tego korzystać, bo to jest nawet w FAQ-u, w którym opublikowali. Taki nie do końca.
Łukasz Kałużny: Tak, że jesteś system integratorem, więc możesz tego używać.
Szymon Warda: Rozumiemy ich potrzebę, bo nie oszukujmy się, z HashiCorpowych narzędzi sporo ludzi korzysta, mało kto korzysta z płatnych narzędzi.
Łukasz Kałużny: Tak, i druga sprawa, nikt nie chce być kolejnym Dockerem.
Szymon Warda: Tak, tylko z Dockerem jest taka opcja, że ludzie już z niego korzystają, nie wyjdą z tego, więc płacą bo: no dobra, płaćmy.
Łukasz Kałużny: Ale tylko na desktopie. Nikt nie płaci na serwerach.
Szymon Warda: Zgadza się jak najbardziej, rozumiemy. I teraz bullshit, że będzie Open Terraform. W tej całej układance CNC-fowej, rozumiem tak naprawdę to. Czy uda im się zbudować to? Nie wiem, ale pasowałoby to i wydaje mi się, że gdyby ten projekt się rozhulał, to HashiCorp będzie sam w rogu de facto, wprowadzi takiego szach mata właświcie.
Łukasz Kałużny: Pytanie, bo nikt duży się pod tym nie podpisał, żaden dostawca cloudowy się pod tym, poza jakimiś tam popierdółkami, które się nie liczą, nie podpisał.
Szymon Warda: Ale ustalmy, nawet pod Terraformem CNC-cloudowym się podpisują na zasadzie jako powiedzmy sobie.
Łukasz Kałużny: Ale coraz częściej wspierają. Cała zabawa, tak patrząc na całość, bo mówimy, że kolejna drama, zobacz, że zmiany licencji Redisa, Elastica, Mongo, wszyscy się odgrażali z tymi forkami. Jedyny fork, który się udał, to był od MySQL-a. To jest jedyny taki w przestrzeni ostatnich lat, to jest jedyny duży fork, który się udał po zmianie licencji, całych tych przejściach.
Szymon Warda: Bo siedział na tym cały Facebook.
Łukasz Kałużny: Tak, bo raczej siedziała moc sprawcza za tym, taka realna moc sprawcza, żeby pociągnąć to w nową rzecz.
Szymon Warda: Ale wydaje mi się, że jest różnica, bo zrobić forka do bazy danych, itd., to to jest skomplikowane. Terraform jako taki, ta binarka ma tam 80-100 MB? To nie jest duże.
Łukasz Kałużny: To nie jest duże. Tylko jest teraz pytanie, to co rozmawialiśmy wcześniej, więc przepraszamy, że tak wtrącamy, ale co będzie z… Bo Terraform jako narzędzie, walić to, jego siła polega w providerach.
Szymon Warda: Ekosystemie, dokładnie tak, bo jest prosty.
Łukasz Kałużny: Jestem teraz ciekaw co będzie z ekosystemem, bo zobacz, że jest tak, część np. dużych firm, patrzę na to, że będę korzystać z open source, ale powinienem mieć możliwość wykupienia płatnego wsparcia. I z drugiej strony co będzie z tymi głównymi dostawcami, którzy… Co będzie poza Kubernetesem? Bo to będzie pewnie wspierane bez problemów, ale co będzie z innymi głównymi elementami, takimi jak GCP, AWS, czy Microsoft. Zobacz, że GCP np. tylko pisze Terraform, Terraform, Terraform w swoich przykładach.
Szymon Warda: Wiadomo, że ci duzi dostawcy będą mieli wywalone. Oni powiedzą, że Terraform, bo nie będzie im się chciało i oni będą czekali na sam koniec, co się stanie wokół społeczności. Jeżeli Open Terraform, jeśli okaże się, że jest więcej providerów, więcej zabawek, więcej ludzi się kręci wokół Terraforma, to oni stwierdzą, że ok, to będziemy wspierali. Jeżeli nie, to po prostu oleją ten temat, więc oni będą na samym końcu adopcji. Ale to co rozmawialiśmy, to było to, bo teraz są propozycje licencyjne, więc teraz czym może Terraform wygrać takim? To jest to, że wprowadzi rzeczy niezgodne wstecznie, zmieni coś, jakieś ficzery, itd. Ale może się znowu zapędzić w kozi róg, bo będzie to samo co Open Terraformie, że providery będą niezgodne, to obetnie swój ekosystem. A wydaje mi się, że ich wszystkie pozostałe providery będą bardziej w kierunku opensource’owym utrzymywać społeczność. Będą bardziej wokół OpenTF-a się kręciły mimo wszystko.
Łukasz Kałużny: No więc zobaczymy jak to będzie wyglądało. Jeżeli całość, wrócimy za pół roku i sprawdzimy jak to się czuje. Ja w kościach mam, że straci to momentum.
Szymon Warda: Możliwe. Wydaje mi się, że to się nawet w ciągu pierwszych trzech miesięcy ogarnie tak naprawdę, co się będzie wokół tego działo.
Łukasz Kałużny: Raczej tak, powiedzmy, że nóż na gardle mają ci od Terragrunta, nóż na gardle, Spacelift i parę jeszcze innych takich produkcików.
Szymon Warda: Będzie się działo. Druga drama - Moq.
Łukasz Kałużny: [Śmiech] To jest drama Dotnetowa w sumie.
Szymon Warda: Ja bym powiedział, że to jest drama finansowa. Jest Dotnetowa, ale to podeszło dość szerzej. O co chodziło? O to chodziło, że Moq zaczął wykorzystywać Sponsor Linka, który zamieszcza jakieś tam materiały reklamowe i który został wykorzystany do tego, żeby wstrzyknąć do Moq kawałek kodu, który skanował repa i wyciągał maile i wysyłał te maile.
Łukasz Kałużny: Maile, może repa brał twojego, podsyłał, to jest bardzo ważne, twojego githubowego maila, że wykorzystujesz czy sponsorujesz. Bo to też jest, że wyciąga maile, to było takie nadużycie powiedzmy, że tej osoby, która z tego korzysta i ma podpiętego i sprawdza twój githubowy login.
Szymon Warda: Dla mnie to nie jest problem, cała ta drama, nie jest problem Moq, bo Moq robi dobrze. Chce mieć kasę na utrzymanie sporego projektu opensource’owego. Z całym szacunkiem, ale utrzymanie i godziny kosztują. Powiedziałbym, że OK, jak to się robiło jak się było nastolatkiem albo na studiach to miało się czas, a wraz z wiekiem tego czasu jest trochę mniej. Ludzie po prostu chcą mieć życie de facto i chcą mieć uzasadnienie - czemu to w ogóle robić? A jakoś nowi wchodzący nie przyjmują tych projektów tak łatwo. Więc ja to w pełni rozumiem. To, że usługa, która pozwala nadzorować na opensource nie zwalidowała, nie sprawdziła i ona dała ciała de facto, no sorry, początki po prostu.
Łukasz Kałużny: Znaczy wiesz co, raczej patrząc, całość jest taka, że dramcia jest z tego, że to wpadło niezapowiedziane.
Szymon Warda: Tak brak komunikacji tu nawalił, to się z tym zgodzę.
Łukasz Kałużny: To jest wiesz, komunikacji… Można było to zrobić kulturalnie i powiedzieć, że od tego realese’u koniec darmowego jedzonka, tak jak było to np. z Identity Serverem.
Szymon Warda: Wydaje mi się, że Identity Server to naprawdę ładnie ogarnął.
Łukasz Kałużny: Ogłosił, że od tego realese’u koniec, chłopaki macie czas albo wykupić się albo zastanowić co z tym zrobić, starego już nie utrzymujemy.
Szymon Warda: Bardzo taki clean cut. Też mi się to podobało. Ale co mnie rozwaliło, czytając szczególnie komentarze wokół issues’a na Githubie, to była ilość ludzi, którzy zachowywali się jak, sorry, nastolatki na Twitterze, które protestują jakąś wojnę albo przewrót w Afryce: a będziemy bojkotować. Ilość ludzi, która opisywała: okej, to jest straszne i będziemy teraz przerabiali całe nasze testy na inny framework do testowania. Rozumiem, tak, to nie było ładne, ale nie róbmy z tego dramy jak nastolatki, naprawdę. To się rozwiąże. A przepisanie całego engine’u do testowania, całego frameworka do testowania, to też jest sporo roboty, to jest spory nakład. Osobiście wolę zrobić coś biznesowego bardziej i zobaczyć jak to się rozwiąże. Podnoszenie temperatury wokół tego naprawdę nie ma żadnego sensu.
Łukasz Kałużny: Wiesz co? Tak, dlatego ja się zgadzam z tym podejściem, że jesteś duży, to powinno być w licencji zapisane, że jako duży musisz wykupić licencję i koniec. I to jest w ogóle moim zdaniem przy open source bardzo uczciwe rozwiązanie.
Szymon Warda: I to jest ten model licencyjny do Docker Desktopa de facto. Powyżej pewnego przychodu firmy, co można sprawdzić w dokumentach, płacisz.
Łukasz Kałużny: Tak, Microsoft miał to w Visual Studio tym Community np., że jak twoja firma przekracza X, no to sorry, musisz kupować. Dużo było takich rozwiązań, które to zawierało. Pojawiły się w Apatchu też takie zmiany licencyjne commercial use, że jak jesteś duży i zarabiasz to sorry płać za to i tyle. Więc dla mnie patrząc się na ten wątek open source’u, jest trochę tak, że ludzie bardzo mylą OSS z FOS-em, gdzie FOS faktycznie to była całość, wolne i otwarte oprogramowanie. A open source to jest tylko dostęp do źródeł. I to jest taka duża różnica, którą ludzie w całości tej układanki przenoszą na komercyjne produkty, filozofię, która jest w ogóle, no, sobie istnieje i osób, które ją wyznawały, pozostawmy w milczeniu może.
Szymon Warda: To jest przede wszystkim to, że z open source problem jest taki, że niestety patrzymy na sam kod, ale nie widzimy ile godzin idzie w pracę nad tym. Ci ludzie po prostu zniknęli. Patrzymy tylko na produkty wyjściowe i oczekujemy, że one będą tak samo dobre albo nawet czasami lepsze niż produkty, za które byśmy płacili normalnie dużo. I to się zatarło.
Łukasz Kałużny: Ale zobaczmy np. CNC. Tam deweloperzy, którzy nie są, nie mają za to płacone, to jest ułamek pewnie, jak sprawdzimy.
Szymon Warda: Tak, ale dlatego właśnie jak się wejdzie na stronę sponsorów, to ten suwak do przewijania scrolla jest bardzo, bardzo, bardzo, bardzo mały i poszerzy platinium, a ich jest też dużo. Wydaje mi się, że CNC naprawdę jest dobrym rozwiązaniem pod bardzo wieloma względami, ale nie pokryje wszystkiego absolutnie.
Łukasz Kałużny: Nie, więcwiesz, jak na całość sobie popatrzymy, na tą układankę, czy na open source można zarabiać? Tak, tylko trzeba uważać. Sebastian na swoim blogu też jedną rzecz napisał fajną, tylko z drugiej strony, że został złamany kontrakt społeczny.
Szymon Warda: Tak, bo to jest coś, o co się to rozbija tak naprawdę, złą komunikację.
Łukasz Kałużny: Tak, że został złamany. Więc to jest taka ciekawa rzecz, że wiesz, że zmieniamy. To samo też było przy Elasticu. Bardzo mocno ludzie się wkurzali na to, tak to kulturalnie określimy, że się wkurzali na tą całą zmianę.
Szymon Warda: Ja bym powiedział bardziej podnosili dramę, bo tam sporo jest dramy, takiej naprawdę nastoletniej dramy.
Łukasz Kałużny: Nie, wiesz co, w Elastiku to były osoby, które np. kontrybuowały spory czas, były wkurzone, że na ich funkcjonalnościach ktoś będzie zarabiał, które naklepali.
Szymon Warda: Zgadza się, ale to była mniejszość. Dalej Elastica w dużej mierze czuło Elastic jako taki, płacił za developerów. To był czas, który był z czegoś wynikający. Dobra. Drugi temat, o którym chciałem pogadać, bo on jest dość ciekawy. Stack Overflow i spadek wejść. Stack nam się kojarzy, np. mi się kojarzy z tym, że to jest domyślna cena, z której są wyniki. Ja osobiście coraz częściej pierwsze ileś top wyników nie jest ze Stacka albo jak są to są pytania nieodpowiedziane. I Stack ma spadek wejść o 35%, to jest absurdalnie wielka ilość. Do tego dochodziły jeszcze dawne artykuły, od tego że jest coraz mniej odpowiedzi, jest coraz mniejsza społeczność, że jest coraz większa toksyczność tej społeczności itd., itp.
Łukasz Kałużny: Drugi Reddit zaczął się powoli tworzyć.
Szymon Warda: Trochę tak, tylko że właśnie, Reddit domyślnie jest takim śmietnikiem wszystkiego, a w Stacku jednak polegał - główna baza wiedzy. I oni trochę.. Problem był taki, np. Stack publikuje swój cały zbiór danych, kiedyś problemem wejścia było to, że ciężko było zbudować taki sam serwis i go tak samo wypromować, więc to była ta bariera do wejścia. A obecnie jak mamy całe modele de facto, to już staje się trywialnie proste. Stack próbuje ratować się z Overflow AI. Wydaje mi się, że trochę za późno.
Łukasz Kałużny: Wiesz co? Tylko, że problem był w ogóle w innym miejscu, bo jak popatrzymy w tym poście, który podrzuciłeś, popatrzymy na datę, problem, jak zobaczymy na ilość postów, nie mówię o wizytach, ale jak zobaczymy kiedy jest pierwsze załamanie, taki pierwszy kryzys w tych datach na vote’ach i na postach zobaczymy, że po covidowej górce zaczął się równy spadek w dół. Więc AI też nie jest tego przyczyną.
Szymon Warda: Znaczy to było tak, spadek zaczął się wcześniej, już w 2018 roku, ale potem covidowe rzeczy jeszcze trochę to podbiły do góry, a potem to już prosta linia w dół praktycznie leci. Ten kąt nachylenia spadku jest dużo, dużo, dużo większy. Ale wydaje mi się, że Stack trochę przysiadł produktowo, punktowo i też społecznościowo, nie zarządzili odpowiednio społecznością, żeby coś więcej z tego serwisu wykuć i żeby ta społeczność jeszcze się rozwijała. Więc wydaje mi się, że co, kolejna opcja, wracamy do blogów i oficjalnych dokumentacji? Na tym się może skończyć de facto.
Łukasz Kałużny: Wiesz, dokumentacja coraz lepiej wygląda.
Szymon Warda: Zdecydowanie tak. Wydaje mi się, że przez te 5-6 lat świadomość dokumentacji się znacząco zmieniła. Ale też zmieniła się inna rzecz de facto. Zmieniła się kasa, która idzie w dokumentację na produktach i w taką sensowna dokumentację na produktach. Także wydaje mi się, że to może być początek końca ery Stack Overflowa.
Łukasz Kałużny: Dobra, zobaczymy. Lecąc dalej, bardziej wesołe rzeczy. Przejdźmy do dwóch luźniejszych rzeczy. Fortran dostał update w tym roku. To w ramach takich wykopalisk i pewnie jeszcze znajdziemy gdzie jest używany. I co jest w ogóle takie rozwalające, to, że dostał http clienta.
Szymon Warda: To dalej jest używane. To dalej jest używane w systemach, w których nikt nie widzi sensu przepisywania.
Łukasz Kałużny: Tak, ale to jest takie… Inaczej, pamiętam jak mi ciocia tłumaczyła czym są karty perforowane, bo ona akurat była matematyczką na Polibudzie Gdańskiej i liczyła w latach 70-tych albo 80-tych wytrzymałość do kadłubów statków. Zajmowała się tymi obliczeniami, więc wtedy już to komputeryzowano, informatyzowano ten proces. I opowiadała mi właśnie, że Fortran to są karty perforowane, żeby zaprogramować komputer i inne takie rzeczy. Trzymała to na pamiątkę.
Szymon Warda: To tylko pokazuje jedną rzecz, jest grupa produktów poza takim hypem IT, które po prostu robi się i one są skończone de facto, albo rozwijamy je w małym stopniu. To będzie istniało.
Łukasz Kałużny: Dobra, i teraz słuchaj, jak jesteśmy przy takim temacie, to trochę cięższy temat, drugi, ale to jest zabawne jak na to patrzę. IBM szuka ciągle kasy w Cobolu i żeby utrzymać mainframe’y, co jest oczywiste. Tak, ta sama bajka. Więc tym razem wymyślili, że to AI będzie przepisywało kod z Cobola na Javę.
Szymon Warda: I to jest debilny pomysł, bo, ej, z całym szacunkiem, kto podejmie ryzyko, że: OK, przepisaliśmy, jest w porządku, lecimy. Ten kod dalej trzeba zrozumieć, dalej trzeba przetestować, dalej trzeba sprawdzić.
Łukasz Kałużny: Raczej inaczej: nie w tym momencie rozwoju tej technologii. Raczej czy jest to w skończonym czasie realne, że takie rzeczy się udadzą? Tak, ale nie w tym momencie.
Szymon Warda: Ja nie widzę, kto by tego użył, dla mnie osobiście. Poważnie, co z tego, że masz kod z Cobola skoro tam mogą być błędy.
Łukasz Kałużny: Wiem o jednym przypadku, ale nie AI-owym korzystania z konwerterów do innego języka i gdzieś to tam nawet działało. Tylko to był konwerter a nie AI i modele generative AI do tego.
Szymon Warda: I ja się z tym zgodzę. Jak konwerter jest, możesz upewnić się, że konwertuje jeden do jednego. W sensie logiki, która się tam dzieje. W AI-u nie masz tej gwarancji, dlatego sorry, obym się mylił.
Łukasz Kałużny: Masz gwarancję, że gdzieś haluny będą.
Szymon Warda: Dokładnie tak, idzie ten halun na mainframe’ie, gdzie ten błąd kosztuje cię niewyobrażalnie dużo, dlatego nie widzę sensu. Konwertery tak. Chociaż pamiętam takie konwertery, które chyba z Cobola konwertowały tak, że zamieniały wszystkie IF-y na FOR-y na C-Sharpa. To było też ciekawe.
Łukasz Kałużny: Dobra, to co Szymon? Kolejna dramcia. Domyślasz się o której myślę, więc zacznij.
Szymon Warda: Czyżbyś mówił o McKinseyu?
Łukasz Kałużny: Tak, McKinsey stwierdził, że pomoże biednym zarządom rozliczać CAO czy CTO w swoich organizacjach.
Szymon Warda: Zanim zaczniesz wyszydzać, bo ja tutaj mam trochę inne na to spojrzenie, przynajmniej jak żeśmy zatrzymali rozmowę, jak zwykle, żeby było ciekawiej, docinka. Co zrobił McKinsey? McKinsey napisał sobie artykuł, długawy faktycznie, w którym stwierdzili, że trzeba zacząć liczyć wydajność developerów. I artykuł jest miksem absurdalnych, bzdur i dobrych pomysłów. Ciekawe. Więc oni generalnie stwierdzili, że chcą mierzyć produktywność na trzech poziomach - systemowym, zespołowym i indywidualnym. Systemowym, czyli w całości organizacji, w zespole, i indywidualnym. I teraz jeżeli ktoś myśli, że to brzmi znajomo, to brzmi znajomo, bo to są dokładnie te same trzy poziomy, które są wyjęte z VOUW Employee Guidebook. VOUW opublikował swojego guidebooka dla nowych pracowników i tam dał jak oceniać produktywność na one on one’ach. To są dokładnie te metryki. Jak ktoś potrzebowałby pomysłu na one on one’y, świetne 21 stron, jest dużo obrazków i dużym tekstem, więc spoko. Można to wygooglać. Więc to są dokładnie te same wymiary. Lecimy dalej: z metryk. I teraz idziemy w takie rzeczy, które są trochę dziwne.
Szymon Warda: Jedną z metryk, kluczową, którą wymienili, to jest mierzenie częstotliwości deploymentu. Jeżeli ktoś słuchał naszego podcastu odnośnie DevOps reportu, to wiecie, że od tego się odeszło, bo sama częstotliwość nie ma wartości, a niektóre systemy nie czerpią wartości z tego, że są często deployowane.
Łukasz Kałużny: Jakby ktoś wziął Dore i nie przeczytał raportu.
Szymon Warda: Tak. Dalej idziemy. Dalej co zrobili? Zrobili generalnie wzięli Dore, zebrali różne pomysły na różne metryki z różnych miejsc i do jednego garnczka wrzucili trochę. Wzięli Dore, czyli Deployment Frequency, Lead Time of Changes, Mean Time to Recovery i Change Further Rate.I ok. Dora jak najbardziej swoje rzeczy ma. Przy okazji Dora jest oczywiście od googlowego zespołu DevOps Research and Assessment. Potem wzięli kolejne metryki, czyli wzięli space metryki, czyli satisfaction and well being, performance, activity, communication, collaboration and efficiency and flow. To są metryki, które mówią o tym, jak się ludzie dobrze czują i tak dalej, i tak dalej. To jest znowu wzięte od GitHuba i Microsoft Research i one są OK, mają sens. Mierzenie ich jest dużo dużo trudniejsze. I potem stwierdzili: to dodajmy też coś od siebie, nie tylko, że wrzuciliśmy kilka linków i skopiowaliśmy tekst. Jedną metrykę, którą dorzucili od siebie, która pokazuje ich trochę takie bardzo wąskie myślenie, to jest Inner Author Loop Time Spent. O co chodzi.
Szymon Warda: Stwierdzili, że Inner Loop to jest to, co developerzy będą robić najbardziej, czyli kodowanie, no nie? Kodowanie, testy, buildy. Wszystko zewnętrzne, typu narzędzia do CI/CD, monitorowanie, ogólne wsparcie, komunikacja, spotkania, itd. Wszystko poza tymi trzema rzeczami to są Author Loopy. Więc oni stwierdzili, że trzeba maksymalizować czas kodowania pisania kodu, a minimalizować ten czas pozostały.
Łukasz Kałużny: Ale wiesz co? I to jest najlepsze. Jeżeli porozmawiasz z kimkolwiek, kto ma doświadczenie, to powie Ci zupełnie odwrotną rzecz.
Szymon Warda: Nie Łukasz, ale teraz perełka na torcie, która spowodowała, że raport stracił trochę. I teraz z głupot. Jest artykuł, for example, podałem jako przykład słuszności zachowania. For example, one company found that its most talented developers were spending time on noncoding activities such as design sessions or managing interdependencies across teams. In response, the company changed its operating model and clarified roles and responsibilities to enable those high-value developers to do what they do the best: code. I to jest cytat z tego artykułu. Czyli ludzie, którzy myślą, którzy wiedzą jak projektować systemy, mają wrócić do pisania kodu.
Łukasz Kałużny: Raczej jesteś principalem i masz kleić firmę.
Szymon Warda: Dokładnie! Raczej to jest taki brak rozumienia. Oni myślą, że to jest jak.. nie wiem, no że.. że liczy się ilość. Ten artykuł jest bardzo mocno pod kątem: dużo, dużo kodu róbmy, nie ważne jakiego.
Łukasz Kałużny: Ale to jest wiesz… Dlatego ja się z tego zaśmiałem na początku, że to jest próba odpowiedzenia, że nie wiemy jak rozliczać. To jest na zasadzie: pojawia się często to pytanie, to wyplujmy coś z siebie.
Szymon Warda: Zbierzmy coś, co możemy zmierzyć.
Łukasz Kałużny: Tak, zmierzmy coś, bo całość, jak wiesz, z Dorą, Dora ma sens. Patrząc, gdybyśmy szukali złotego środka, to trzeba wrócić teraz i powiedzieć sobie, że wracamy do robienia porządnych analiz potrzeb biznesowych i wyrzucamy część analityczną ze scrumu, agile i innych rzeczy i projektujemy upfront, dużą część rzeczy albo zbieranie wymagań. Bo to jest też taka ciekawa rzecz, że druga strona barykady, powiedzmy: czy IT się opierdala? Tak, odpierdala się, bo to trzeba też powiedzieć, że to jest sorry, tak, bardzo często jest efektywność, jak w niektórych zespołach patrzę…
Szymon Warda: Poczekaj, nie koniecznie się opierdala. Często ja to widzę, że gonimy własny ogon, że skupiliśmy się na rzeczach technicznych, nowych zabawkach, a nie na wartości biznesowej.
Łukasz Kałużny: Raczej to jest też inna rzecz, że część domenę biznesową ma w poważaniu. Ona chce kodować. Jest dużo takich osób, a jeszcze większa ilość osób, które chce wziąć wypłatę i mieć pracę od 9 do 17. A najlepiej, żeby ta 9-17 była tylko umowna.
Szymon Warda: Tak, chociaż z drugiej strony też firmy zaczęły podchodzić do developerów jako takiej wymiennej masy. To też jest taka akcja-reakcja tak naprawdę.
Łukasz Kałużny: Tak i druga rzecz jest taka, że management często patrzy, żeby mieć resource’y. To oni mają kodować, a nie rozumieć domenę biznesową. Tylko z drugiej strony jest takie oczekiwanie, że jak popatrzymy na ogłoszenia o pracę i w ogóle jak wygląda rynek, analityk biznesowy, systemowy zniknął w ogóle z takiego z szeroko rozumianego landscape’u.
Szymon Warda: Jest product owner, de facto.
Łukasz Kałużny: Tak, product owner, który, przepraszam, w większości przypadków nie umie technicznie zająć się analizą wymagań i czy one są w ogóle logiczne.
Szymon Warda: Product owner z reguły patrzy na produkt w kierunku: mamy pudełko, jakie mamy ficzery i co jest na tym napisane, nie schodzi do tych detali.
Łukasz Kałużny: Nie, nie ma czegoś takiego. Dobra analiza biznesowa wiesz, że zakłada założenie, czy biznes nie mówi bullshitu i ciągnięcie go za język, proponowanie im zanim przekażesz tego do developerów.
Szymon Warda: Tak i zweryfikowanie: ej, ale jak bardzo tego potrzebujecie? To będzie kosztowało nas tyle-set godzin. Czy w ogóle tego potrzebujecie? Biznes będzie chciał, będzie chciał wszystko, bo wiadomo, dzięki temu będą kręcili szybciej, będzie im łatwiej. Czy naprawdę tego potrzebujecie w tym wydaniu?
Łukasz Kałużny: Więc całość, patrząc się, fajnie, tylko trzeba powiedzieć, żeby ten ekosystem był mierzalny, efektywny, to wszystkie strony muszą współpracować.
Szymon Warda: Tak, bez względu muszą wszystkie strony współpracować, ale z reguły nie chcą współpracować, nie mają czasu. Biznes, firmy nie umieją ułożyć często działów IT tak, żeby działy programistyczne nie były postrzegane tak samo jak administratorzy, którzy zajmują się dostarczaniem laptopów. Bo to jest z reguły ten widok. Jesteś w IT.
Łukasz Kałużny: Tak, widok tak, jesteś w IT i koniec. Więc nie, to jest właśnie ciekawa układanka z całości. I tak jak patrząc się na pozytywne strony tego wylało się tak, jak np. Orosz w swoim pragmatic engineering mailingu. Dużym plusem tego raportu jest to, że wylało się teraz multum wiedzy internetowej na temat prób mierzenia metryk, podejść i innych takich rzeczy. To jest największa zaleta tego raportu, że osoby, które lubią pisać, się wkurzyłu i się dzielą wiedzą.
Szymon Warda: I z dużych organizacji, gdzie to robione jest fajnie… Podsumowując co Orosz napisał, i do mnie to jest sensowniejsze, on powiedział jedno: trzeba mierzyć impact, trzeba mierzyć to, co dostarczyliśmy i jak. Bo dla większości firm działy IT to są działy wsparcia. Więc impact, czyli mierzymy generalnie jak pomogliśmy biznesowi się rozwinąć. Ale to wymaga kolaboracji.
Łukasz Kałużny: Ale każdej rzeczy jesteśmy w stanie powiedzieć… Inaczej, robiąc jakiś system internalowy, jakąś sheet smart apę, w zależności jak kto nazwie, jesteśmy w stanie powiedzieć jak my pomagamy, co ulepszyliśmy.
Szymon Warda: Przypominam, że generalnie na co Orosz fajnie odpowiedział. Teraz czemu jednak mimo, że tutaj trochę hejtujemy ten artykuł, mierzenie wydajności developerów jest konieczne? Bo jeżeli pójdziesz na jakikolwiek zarząd, na jakiekolwiek wysokie spotkanie i będzie rozliczanie poszczególnych działów, to marketing będzie się tłumaczył, czasami z dupynych metryk, ale będzie podawał liczbę, będzie podawał co zrobił i tak dalej. Sprzedaż jest totalnie kierowana liczbami i muszą się tłumaczyć ze wszystkiego. Mieli cele, co zrobili i tak dalej. I jeżeli czegoś nie dowieźli, to się tłumaczą. A potem wychodzi koleś od IT i mówi: no zrobiliśmy ficzer A, ficzer B, żeśmy wdrożyli Mongo i w ogóle tego i Azure albo coś tam kosztuje nas tyle i tyle. I tam jest zero konkretów, praktycznie zero liczb i jest bardzo mało przewidywania. I nie mówię tego, że to jest wina tego, jak prowadzimy IT testy. Tego wina jak są umiejscowione, jak przedstawiamy, jak mierzymy i tak dalej. Ale dla większości firm to IT to jest takie: dobra, przestań o tym mówić, bo i tak nic z tego nie wyniknie. Więc musimy coś zmienić.
Szymon Warda: Ja się zgodzę, że potrzeba jest jak najbardziej, ale McKinsey - kompletny brak zrozumienia.
Łukasz Kałużny: Raczej pokazują różne komentarze efektów ich pracy potem w praktyce i całości.
Szymon Warda: Ja bym powiedział jedną rzecz, żeby nie zostawić ludzi na zasadzie, że ok, nic się nie da zrobić i tak dalej, że tylko hejtujemy. Ja jestem wielkim fanem i to pokazuje najlepiej, jak to robi Google. Google niektóre rzeczy robi dobrze, niektóre rzeczy robi źle, ale jak to robi Google? Jeżeli jesteś menagerem w Google’u, najgorszym okresem jaki możesz mieć i wtedy siedzi się szalone dupo-godziny, to jest czas, kiedy masz podsumowania.
Łukasz Kałużny: Masz performance review.
Szymon Warda: I wtedy jak to się dzieje? Ty oceniasz ludzi w swoim zespole, potem porównujesz to z innymi zespołami, potem porównujesz to jeszcze wyżej i jeszcze wyżej, jeszcze wyżej. To nie jest tak. Wszyscy wiemy jak ktoś się opieprza. Wszyscy wiemy jak ktoś jest genialny, to widać, to ludzie wiedzą. I sprowadzanie tych ludzi do poszczególnych numerków tylko jest bez sensu. Więc ludzi trzeba ułożyć w kontekście relacji z innymi ludźmi, kto jest jak dobry i to jakąś drabinkę, cokolwiek, ale to porównanie jest relatywne.
Łukasz Kałużny: Trochę ranking szachowy jak popatrzymy. Ja upraszczam.
Szymon Warda: Taki Bubble Sort.
Łukasz Kałużny: Tak, Bubble Sort. Tak, jest w ogóle cały dział, ja to zostawię, bo jest “Software Engineering at Google”, jest taka książka, bardzo fajna. To nie jest bullshit tylko prawda. To jest ważna rzecz. I tam jest cały taki duży rozdział, który się nazywa “Measuring Engineering Productivity”.
Szymon Warda: Podam coś innego, ludzko, sorry, nie ubierzemy tego w numerki. Jeszcze z Google’a, jak o to mówimy, opublikowali stronę swego czasu, gdzie zrobili na bazie eksperymentów właśnie jak w ogóle zarządzać ludźmi do KPI, do bardzo, bardzo, bardzo wielu rzeczy, rozmów, indywidualne podejście. Też całkiem dobry zbiór poparty badaniami naukowymi, eksperymentami, które przeprowadzali. I wysłaliśmy go w którymś odcinku pamiętam, było to. Może uda nam się to odszukać.
Łukasz Kałużny: Więc z metryk polecam, bo to jest ładnie określone. Tak naprawdę Goale i Signale w tej książce, to jest istotny tam element i zobaczycie, że są porównywalne, a nie mierzymy jakichś suchych liczb, tylko porównujemy.
Szymon Warda: Tak, to będzie to, nie uciekniemy, To będzie trudny proces, który trzeba robić raz na jakiś czas, tyle. Nie uprościmy tej trudności.
Łukasz Kałużny: Tak, a punkciki ze Scruma nic nie dadzą. Żałujcie, że nie widzicie miny Szymona pod tym względem.
Szymon Warda: Bo przechodziłem przez takie różne próby i kończy się na jednym. Ja mam kilka rzeczy jeszcze, odnośnie – małe a cieszy. Wyszło RFC. Odnośnie, mała też pierdółka, odnośnie publikowania RFC, które proponuje jak publikować i jak ustandaryzować komunikaty błędów w requestach http.
Łukasz Kałużny: RFC na to będzie.
Szymon Warda: Jest RFC. Jest krótkie, jest zwięzłe, jest fajnie zrobione odnośnie pól z komunikatem błędu, jak jest wiele pól, jakich używać statusów http, jakich używać i jak je robić?
Łukasz Kałużny: Czyli nie ma 200 error.
Szymon Warda: Tak, nie ma 200 error, ale w ogóle jest fajne, bo opisują jak w JSON-ie to w ogóle zwracać i jak to ma ładnie wyglądać i jeszcze z przykładami. Naprawdę kawał prostej rzeczy.
Łukasz Kałużny: Zaproponowany standard. Ja ostatni taki link na dzisiaj z moich pierdół jeszcze. Jest fajne RCA, potem jest fajny snapshocik po awarii stanu, coś się zadziało. Tutaj fail wpisz social. Nie wiem co to jest. Bardziej mnie zainteresowało, że wyskoczyło mi w kubernetesowych katastrofach i tutaj ktoś zmienił katalogi w repo, bo używają podejścia gitopsowego, gdzieś na jakimś kubernetesie i zmienili katalogi nie przekonfigurowując argo. Więc co zrobio argo? Pokasowało! Między innymi bazy danych.
Szymon Warda: To że się ma gitowca to nie znaczy, że jest lepiej i bezpieczniej. Znaczy, że trzeba dalej myśleć, trzeba myśleć nawet jeszcze bardziej. Tak, ciekawe.
Łukasz Kałużny: Więc to taki ciekawy przypadek, krótki, wesoły opis, żeby zobaczyć w jaki sposób i co zrobili.
Szymon Warda: Dobra, to kończymy tak naprawdę chyba.
Łukasz Kałużny: Kończymy. Trzymajcie się i do usłyszenia przez najbliższy rok z przerwą świąteczną.
Szymon Warda: Na razie.
Łukasz Kałużny: Hej!