Coffee Coffee #21
Dług technologiczny
O odcinku
Dług technologiczny! Postrach inżynierów. Niewygodna prawda ukrywana pod zawsze zbyt krótką kołdrą zasobów inżynierskich. Czy da się go ogarnąć? Czy da się nim zarządzić?
W tym odcinku Coffee rozmawiamy o długu technologicznym:
✅ Czym jest i jak go definiujemy?
✅ Skąd się bierze i kto na nim korzysta?
✅ Czy dług jest korzystny czy nie i kiedy?
✅ Zuo? Rzeczywistość? Ryzyko które akceptujemy?
✅ Jak podejść do zarządzenia długiem technologicznym
✅ Podejścia, techniki, pomysły.
Do rozmowy zaprosiliśmy Krzyśka Daniela (https://kda.zone), który dług technologiczny badał w różnych organizacjach.
Zapraszamy
=============================================
📢 Ten odcinek w formie podcastu możecie odsłuchać tutaj: https://share.transistor.fm/s/46bb81bf
CTO Morning Coffe tworzą:
👉 Sebastian Gębski:
🔵 Twitter: https://twitter.com/liveweird
🔵 Blog: https://no-kill-switch.ghost.io/
👉 Wojtek Ptak:
🔵 Twitter: https://twitter.com/wjptka
👉 Tomek Onyszko:
🔵 Twitter: https://twitter.com/tonyszko
🔵 Blog: https://www.onyszko.com/
🔵 Newsletter: https://signup.onyszko.com/
Live long and prosper 🖖
---
To nagranie jest zapisem spotkania na Twitter Spaces, tak jak zostało przeprowadzone, bez dodatkowej obróbki. Zapraszamy do dołączenia do przyszłych spotkań na https://www.ctomorning.coffee
Transkrypcja
Brak wyników.
Dzień dobry wszystkim. Cześć Tomku, dzień dobry. Cześć, cześć, dzień dobry. Wow, wygląda to, że wszystko działa. Niesamowite, miałem chwilę stresu, bo jak uruchamiałem, to przez chwilę się nic nie pojawiało, ale działało. Twitter jest jak dobra loteria. Ostatnio tak. A widziałeś najnowszy twitter? Ten zwiększenie i wyłącznie reklam, razy trzy? Nie, ten, że posty ona są na samym szczycie feedu, jak zawsze. I nie muszą być reklamowane. Niech każdy CEO, który nie zrobił czegoś takiego, rzuci kamieniem. Przyznaje, że nie jako CEO, ale to się podobno jak jej zrobiłem, ale na prośbę CEO, tak. To było dawno temu.
Dobrze, mamy Krzyśka. Krzysiek, słyszysz nas? Krzysiek na telewizji nawet ma niebieski znaczek. No, nawet mam. Chyba was słyszę, a gdybym nie, słyszycie? Tak, bardzo dobrze. Cześć, cześć, bardzo dobrze. To może chłopaki zacznijcie typowe wprowadzenie, ja jeszcze tylko ogłoszę nas na social mediach i lecimy. Sebastian, zaczynasz? Jasne, czemu nie. No więc tak, witamy wszystkich. Fajnie, że dołączycie po kolei. Słuchajcie, City of Morning Coffee, bardzo proste przypomnienie formuły. Spotykamy się raz na dwa tygodnie na tych spotkaniach. Trwają jedną godzinę, każde spotkanie jest tematyczne, jest moderowane, natomiast każdy może zabrać głos. Każdy może zabrać głos, wystarczy po prostu podnieść łapkę przez funkcjonalność wbudowaną aplikacji Twitter. Czyli jeżeli ktoś słucha nas przez weba, niestety głosu nie może zabrać, trzeba skorzystać z aplikacji mobilnej. My moderujemy, dbając o to, abyśmy wszyscy trzymali się tego założonego tematu.
Ważne jest, żebyśmy w tej dyskusji nie przekroczyli pewnych zdroworządkowych granic, czyli rozmawiamy ogólnie szanując siebie wzajemnie, bez jakichś indywidualnych wycieczek po firmach, nazwach, ludziach. Jeżeli krytykujemy, to krytykujemy postawy, zachowania, nie ludzi czy jakieś instytucje. To jest z takich rzeczy zupełnie najistotniejszych. Jeżeli ktoś chciałby przesłuchać sobie archiwum naszych odcinków, to na Twitterze są dostępne ostatnie z nich. Nie wszystkie, ale ostatnie są. Natomiast oprócz tego publikujemy stopniowo w postaci podcastu odcinki historyczne od takich najbardziej najdawniejszych dziejów. Więc wystarczy wejść na cityomorning.cofee, tam znajdziecie wszystkie linki, tam znajdziecie możliwość zapisania się na powiadomienia. To chyba najważniejsze punkty. Wojtku, zapomniałem o czymś. Mamy jeszcze stronę na Linkedinie, gdzie wrzucamy również update'y, tam można wejść.
Mamy również stronę internetową, którą też znajdziecie chociażby na Linkedinie. I z Twitterem mamy problem, ale myślę, że go rozwiążemy. Znaczy mało zło wróżknie. Albo Twitter rozwiąże nas. Dobrze. Albo Twitter rozwiąże nas. Dzisiaj bierzemy na tapetę dług technologiczny, więc każdy podlicza swoje długi w banku. Mamy gościa. Krzysiek, możesz chwilę się przedstawić, powiedz skąd się wziąłeś, oprócz tego, że Cię zaprosiliśmy i co robisz? Wiesz co, jak mnie tak zapytałeś skąd się wziąłem, to przyszło mi tyle odpowiedzi, których nie powinienem tu poruszać. Muszę potrenować nad pytaniami. Spadał. Ja mam dosyć, nie wiem, czy typowy, czy nietypowy zawód. Jestem researcherem we firmie DXE, do której trafiłem przez przypadek, bo tak naprawdę ileś lat temu zainteresowałem się mapami World Layout jako narzędziem do tworzenia strategii.
Później dołączyłem do samego Simona, do jego zespołu i od tego czasu zajmuję się różnymi ciekawymi tematami. Dług technologiczny to jest temat, który gdzieś wewnętrznie się wypłynął w 2017 roku, ale wtedy został uznany, że to jest w zasadzie nudne i nikt tym nigdy nie będzie się interesować i został zakopany. A teraz po pandemii, jeśli można tak powiedzieć, temat wrócił ze zdwojoną siłą i nagle wszyscy chcą wiedzieć jak sobie z nim poradzić, więc spędziłem ostatni, nie wiem, rok po przerwie, a wcześniej też trochę, studiując zagadnienie. Z wykształcenia jestem informatykiem, temat jest mi bliski. No, czuję, wydaje mi się, że czuję temat. Czuję, że stworzyłeś jakiś dług technologiczny. Do każdego. No dobra, no to zaczynamy. Sebastian, od czego? Myślę, że dobrze jest zacząć od pewnego rodzaju postaw, bo wprawdzie my nie będziemy tutaj rozmawiać z perspektywy zwykłego inżyniera, czyli nie będziemy rozmawiać o tym, jak aktualizować pakiet na NPM-ie albo co to znaczy clean code, jaki to ma wpływ na dług techniczny, tylko będziemy patrzeć jednak z perspektywy bardziej zarządczej.
Natomiast, mimo wszystko, chyba dobrze zacząć od definicji. Krzyś, jak ty byś zdefiniował dług technologiczny i czy to, tak jak już zdefiniujesz, to czy to jest dla ciebie pojęcie jednorodne, czy wyróżniłbyś w nim jakieś typy, grupy, pomiędzy którymi są poważne różnice? Wiesz co, Wikipedia ma, ja nie pamiętam słowa definicji tej wikipedycznej, ale ona jest dosyć dobra i tak w dużym uproszczeniu to jest po prostu, bierzemy krótkoterminowe benefity za długoterminową zdolność do adaptacji, czyli w przyszłości będzie nam trudniej coś zmienić, a teraz po prostu zrobimy coś taniej albo szybciej. I to jest dosyć dobra definicja, ja się z nią zgadzam. Jedno, co bym usunął z tej definicji, to jest ograniczenie do software'u, bo ten mechanizm długu technologicznego, on działa w zasadzie we wszystkich innych branżach, znaczy we wszystkich innych aspektach firmy, jeśli chodzi o procesy, maszyny, inwestycje, projekty. Wszędzie to działa w ten sam sposób i dotyczy po prostu innych grup ludzi.
Natomiast kluczowym elementem, znaczy kluczowym podziałem długu technologicznego z mojego punktu widzenia jest dług technologiczny, który jeszcze kontrolujesz, o którym jeszcze wiesz wystarczająco dużo, żeby go usunąć, i dług technologiczny, o którym już zapomniałeś, jak go usunąć jako, powiedzmy, osoba, która zarządza we firmie, czyli systemy 20-, 30-, 40-letnie, gdzie pracownicy wymienili się już z pięć razy i tak naprawdę nikt nie wie, co ten system robi, dlaczego działa i dlaczego tak został zaprojektowany. I w zasadzie tak, dwie główne kategorie, jedną można jeszcze usunąć, a druga to jest po prostu strasznie ciekawa zagwazdka dla ludzi, którzy są za to odpowiedzialni. I to, co powiedziałeś, to generalnie bardzo przystaje też do mojej definicji, natomiast to po prostu brzmi jak cena podejmowania pewnej decyzji. Każda decyzja jest trade-offem, nie powinniśmy być perfekcjonistami, to nie jest do końca zdrowe albo w ogóle nie jest zdrowe. I teraz w związku z tym, jeżeli to jest po prostu cena podejmowania decyzji, to dlaczego ten temat jest taki mośny, dlaczego tyle się o nim rozmawia i dlaczego on się tak często pojawia jako pewnego rodzaju wymówka, excuse w różnych inżynierskich rozmowach?
No to tutaj wynikamy ciekawych aspektów. Przepraszam cię, Krzyśko. Spoko. Proszę. Nie, nie, ja tylko chciałem dodać, że wiecie, dla mnie to jest taki, bardzo fajnie pasuje metafora, jeżeli się rozmawia, bo to na pewno pojawia się pytanie, jak rozmawiać z osobami nietechnicznymi w organizacji na temat długu technologicznego, natomiast metafora pożyczania pieniędzy też bardzo fajnie działa, czyli mogę dokonać czegoś dużo, dużo szybciej, kupić mieszkanie, wyremontować, jeżeli zapożyczę się w banku, no ale bardzo często osoby nietechniczne myślą o tym, że ten okres niespłacania, który często w kredytach występuje, najczęściej, wiecie, tam 2-3 miesiące na przykład, jest przeciągnięty bardzo, bardzo daleko w przyszłość, więc to jest też fajna metafora. Ja bym nawet jeszcze ten temat trochę rozwinął, bo nie tylko jest rozciągnięty w przyszłość, ale jak wystarczająco długo czekasz, to nie będziesz musiał spłacić, przynajmniej jest taka szansa, że to się wszystko przedawni i uda ci się uciec od tych kosztów i wielu ludzi w ten sposób myśli.
Natomiast tam rzeczywiście jest trade-off i trade-off przynajmniej, tak jak ja to się staram interpretować, trade-off to jest między krótkoterminową efektywnością w zasadzie finansową, bo o to głównie chodzi, a zdolnością do adaptacji. Gdzieś każda firma na tej skali się znajduje i teraz to, co nam wyszło z researchu, to dla mnie to był po prostu szok, jako dla informatyka i kogoś, kto był uczony, że dług technologiczny trzeba nad nim stale pracować, to wyszło nam coś takiego, że są dwa typy firmy. Są firmy, które nie mają problemu z długiem technologicznym, pomimo że mają dług technologiczny i są firmy, które mają problem z długiem technologicznym, pomimo tego, że mają dług technologiczny i że o tym wiedzą i że nie mogą nic zrobić. I to spowodowało takie zainteresowanie, przynajmniej moje, co powoduje, że te firmy myślą inaczej. I jedną z hipotez, którą w tej chwili staramy się zmierzyć, to po prostu to, że ludzie, którzy odpowiadają za decyzje o długu technologicznym i ludzie, którzy odpowiadają za dług technologiczny, to są różne osoby.
Jeśli jesteś szefem działu biznesowego i zrobisz plan i możesz zaciągnąć dług technologiczny i wtedy dostaniesz swój bonus na pełniąc roku i dociągniesz wysoką efektywność, to to zrobisz, tym bardziej jeśli odpowiedzialność za dług technologiczny będzie należała do działu IT. I w ten sposób lądujemy w takim fajnym systemie korporacyjnym, gdzie jedni ludzie biorą wszystkie korzyści, czyli jakby to mówić, biorą tożyczkę i dostają dofinansowanie i mają lepsze wyniki finansowe, a biedni informatycy muszą sobie radzić z, jakby to powiedzieć, rosnącym podtapianiem czy zaciskającym się petlą i coraz trudniejszymi warunkami do pracy. To jest jedna ciekawa rzecz, powiedziałeś kilka ciekawych rzeczy, ale jak dla mnie cały czas się gdzieś przebija pod spodem, że to może być taki bardzo fajny, uniwersalny ekskluz. Że no teraz jest na przykład wolniej albo teraz nie możemy czegoś zrobić, no bo niestety wcześniej mówiliście nam, że ma być szybko, w związku z tym my podjęliśmy takie, a nie inne decyzje.
I to jest, to brzmi bardzo subiektywnie przede wszystkim. Więc teraz takie podstawowe pytanie, czy da się obiektywnie mówić o długu technicznym, na przykład mierząc go, porównując go i czy jeżeli takie miary są, da się je wprowadzić, to czy one są uniwersalne pomiędzy różnymi organizacjami? To jest dobre pytanie, ja tylko dodam, bo to jest pytanie, wiesz, dokładnie w czym wymierzyć, no bo będziemy też patrzeć, znaczy Krzysiek już trochę zaznaczył, że są dwie strony, nie? No bo masz ludzi, którzy, w szczególności w takich firmach tradycyjnie podzielonych, czyli nie jesteś firmą produktową, tak jak Wojtek pracuje w firmie, która jest, krótko mówiąc, przynajmniej nastawiona w całości na swój produkt, tak zakłada, nie? A jesteś firmą bardziej taką tradycyjną, gdzie masz jakiś biznes, który jest wspierany przez to, nie? I masz dwie strony, gdzie jedna może dążyć do jakiejś tam, i może zależeć na tym, żeby to poprawiać, nie? Czy z punktu widzenia, chcemy działać efektywnie i drugie, która po prostu ma krótkoterminowe wyniki, które jadą gdzieś, nie?
I one mogą nie być zainteresowane, albo mieć różne miary tego długu, tak? Krzysiek, chyba chciałeś też powiedzieć, czy auto to jest ciekawe do podciąga? To jest... Ja ten temat poruszę, tak? Bo z jednej strony gdzieś widziałem demo, gdzieś moja firma zrobiła coś takiego, że wchodzą, potrafią wymierzyć, wymierzyć firm we firmie za pomocą analizy tych starych aplikacji, jeszcze mainframe'owych i w ogóle, za pomocą analizy metadanych, dokładnie gdzie firma ponosi największe straty i powiedzieć na przykład, że sposób, w jaki wy te aplikacje utrzymujecie, powoduje, że płacicie dwa razy więcej za obsługę, albo deplojmenty nowych feature'ów są dwa razy droższe niż u waszej konkurencji. I to jest stosunkowo dobra miara długu technologicznego w organizacji, ile kosztujecie pojedyncia zmiana. Natomiast tutaj wchodzi całe... Coś, co mi się w głowie nie mieści, bo ta pojedyncza zmiana dla samego softu może w to wycenić jakoś przez punkty funkcyjne czy jakieś takie... przez jakieś inne dziwne formalne metodologie i to będzie miało sens, ale z drugiej strony długiem technologicznym może też być sytuacja Beyinga 737.
One zaczęły spadać parę lat temu, to była dosyć znana sprawa, jeśli chodzi o katastrofy i tam coś się pojawiło, coś takiego, że Beying 737 był za nisko nad ziemią, żeby założyć większe i bardziej efektywne silniki. On był za nisko nad ziemią, ponieważ jak on był projektowany w latach 50., feature'em było to, żeby ten Beying mógł startować z lotnisk, na których nie było infrastruktury. Więc trzeba było go obsłużyć z ziemi, w sensie ludzie na stojąco, więc on musiał być nisko. I teraz gdzieś w miarę upływu tego czasu cały projekt samolotu przestał być assetem, przestał być przewagą konkurencyjną, a stał się długiem technologicznym, bo nagle wszyscy chcieli bardziej efektywne silniki, więc trzeba było te silniki dokładać, trzeba było kombinować i pojawił się znowu taki koncept długu technologicznego i teraz pytanie brzmi, jak to wycenić? Bo to jest zagrożenie egzystencjalne dla firmy, znaczy było, albo nadal jest.
To nie jest coś, co możesz porównać między dwoma firmami, bo nagle twój podstawowy produkt, coś co sprzedajesz, zestarzało się i jak chcesz to zmienić, to musisz nie tylko przeprojektować samolot, ale wyedukować wszystkich pilotów, którzy z tego samolotu korzystali, wszystkich kontrolerów i to jest w zasadzie coś, co jest niemal niewykonalne. I to powoduje, że biznes poszedł w kierunku, w którym poszedł, czyli hakujemy i kombinujemy, jak to zrobić, żeby to wyglądało jak stary samolot. Krzysiek, mówili, że spędziłeś teraz rok badając trochę z różnymi firmami, bo to, co powiedziałaś, to faktycznie tak jest. Robimy sobie, znaczy mamy jakiś cel, skończony czas, skończony budżet, gdzieś pojawiają się trade-offy, a jak pracowałeś z tymi firmami, na ile według twojego obserwacji firm w ogóle jest świadoma tego, że to tworzy? Czy to jest proces świadomy? Czy spotkałeś się w ogóle z takimi, że ludzie to po prostu świadomie mówią, ok, to jest coś, co kiedyś będziemy musieli naprawić, zaciągamy to teraz, a na ile to jest zawsze on the go, czyli lecimy i robimy to, co trzeba, a potem to się staje naszym długiem technologicznym, nie?
Tomku, ja nie potrafię na to pytanie odpowiedzieć, bo tutaj pojawiają się dwie grupy ludzi. Masz ludzi, powiedzmy informatyków, którym podczas szkolenia, studiów czy nauki wbijano do głowy, że dług technologiczny jest zły, dług technologiczny trzeba usuwać. I dla informatyków, dla ludzi, którzy faktycznie piszą kod, przynajmniej w pewnym okresie ich kariery, dług technologiczny jest wbrew zasadom sztuki. I ci ludzie zawsze będą naciskać na to, żeby zrobić to dobrze, czasem nawet zbyt dobrze i przekombinują, ale to jest przynajmniej tak, to ja to tak odbieram. A z drugiej strony masz ludzi, którzy nie rozumieją IT, nie rozumieją kodu i oni są przez ograniczony czas we firmie. Z ich punktu widzenia trzeba dowieźć rozwiązanie i w zasadzie tyle. Dla nich nie istnieje dalej, więc ja nawet nie wiem, czy to jest kwestia świadomości, czy to nie jest kwestia świadomości, czy to jest kwestia tego, że oni mają te swoje bonusy co jakiś czas, że dostaną, nie wiem, nagrodę, jak dowiozą projekt w terminie i w budżecie.
Ciężko mi jest to strasznie powiedzieć. Raczej bym się spodziewał, że albo to jest coś, co się dzieje nieświadomie, albo to jest coś, o czym wszyscy wiedzą i nikt nie chce na ten temat głośno mówić. A ja tutaj chętnie wejdę w polemikę, bo założyliśmy tutaj, faktycznie padło kilka ciekawych rzeczy. Pierwsza rzecz, myślę, że powiedziałeś coś takiego, że uczy się nas, że dług technologiczny jest zły. Ja bym polemikował, bo bardzo często w ogóle się nie uczy o długu technologicznym i mam wrażenie, że nasza świadomość o długu technologicznym jest bardzo, bardzo niewielka. My ją sobie wyrabiamy, ale na przykład ja osobiście na studiach nigdy nie słyszałem, że jest coś takiego jak dług technologiczny. Punkt, do którego chciałem się odnieść, to jest też, że mamy albo taką, albo taką świadomość tego długu technologicznego. I dla mnie, ja mam taką definicję, trochę mogę przewrotną, specjalnie, żeby tutaj słuchajcie, włożyć kij w mrawisko, powiem, dług technologiczny mamy zawsze. I teraz pytanie, jaki?
I skąd on się bierze, prawda, bo to za chwileczkę mogę się do tego odnieść. Dla mnie dług technologiczny bezpośrednio łączy się z moją wiedzą na temat produktu, na temat jego ekosystemu, na temat konkurencji i w związku z tym, jak my go budujemy, my budujemy jakieś procesy, budujemy jakieś produkty, tymi procesami jakieś, wiecie, jakieś procesy biznesowe. I teraz bezpośrednio dla mnie się to łączy z wiedzą i to się fajnie pokrywa, czyli jeżeli jest wiedza uświadomiona, ta eksplicyta, to dług technologiczny jest podejmowany, tak jak powiedziałeś Krzyśku, eksplicite, czyli my jesteśmy w stanie świadomie podjąć decyzję na temat długu technologicznego, optymalizując na przykład czas dostarczenia do rynku lub zaciągając dług technologiczny, używając na przykład danego vendora, danego produktu, pomimo tego, że wiemy, że to stworzy nam vendor loka i uzależnienie od jego długu technologicznego.
Druga kategoria, którą bym wrzucił, to jest dług techniczny nieuświadomiony, czyli całkowicie nie wiemy czegoś na temat procesów, nie wiemy czegoś na temat produktu, tego całego ekosystemu, w którym on żyje, jego użytkownicy używają, lub nie znamy bardzo dobrze technologii, których używamy i nieświadomie idziemy i sobie zaciągamy ten dług na różne sposoby. Co o tym myślisz, myślicie? Mi się ten koncept podoba, ale może ktoś inny teraz. Ja się tak wtrącę bardzo krótko. Dla mnie ta druga kategoria to nie jest dług techniczny, tylko to jest zła inżynieria. Jeżeli nie jesteśmy świadomi, czyli to nie jest trade-off, tylko po prostu robimy coś bezrefleksyjnie, to to nie jest dług, to jest po prostu zła inżynieria. Jeżeli chodzi o dług, powiedziałeś trochę, że wkładasz kim rowisko. Powiem ci, że za słabo włożyłeś, w sensie może włożę bardziej, bo powiem tak, że dług techniczny to nie jest nic złego, to jest po prostu cena podejmowania decyzji.
To jest tak, że my optymalizujemy się pod kątem tego, co jest najważniejsze dla naszej firmy. Więc jeżeli np. czujemy, że o, nasz produkt łapie traction i że za chwileczkę wchodzimy na zupełnie nowy, dziewiczy rynek i być może pierwszy, który wejdzie, zajmie to, wtedy zaprosimy pieprzyć wszystkie techniczne standardy. Kurczę, mam dokładnie taki przykład firmy, z którą swego czasu współpracowałem. Bardzo ich szanuję, na chwilę obecną mają ewaluację powyżej miliarda dolarów. I patrzyłem na nich przez Pryzmat, nie miałem dostępu jakoś bardzo głęboko do ich architektury i w pewnym momencie mówię im, że słuchajcie, patrzę na to, co żeście zrobili, trochę odkryliście zupełnie nowy biznes, wasz produkt jest unikalny, tak naprawdę do tego konkurencji nie macie, w bardzo krótkim czasie to wszystko zbudowaliście. I to jest naprawdę super, bardzo mi się ten produkt podobał, uważam, że świetnie, żeście trafili. I teraz jeszcze dodatkowo macie kupę kasy, podnieście się kolejną rundę, no nic, tylko ręce do kasków. A oni mi powiedzieli, to my ci coś pokażemy, jak to wygląda pod spodem. I okazało się, że podjęli takie decyzje, które, tak powiedział Krzysiek, w podręcznikach, to one są, jakby Krzysiu na to spojrzał, to powiedziałby, Jezus Maria, tak się nie robi. Ale oni to zrobili w pełni świadomie.
Dlaczego? Na przykład przenieśli masę logiki na front-end, po prostu ładując wszystkie dane do blobów, mając gdzieś jakąś chorą logikę, tam, persewania tych blobów. Ale czemu oni to zrobili? Po to, żeby nie mieć jakiejkolwiek dyskusji w firmie między back-endem a front-endem. Firmy mieli tak się nie sam front-end. I po prostu rzucanie tych blobów do bazy danych. Bo ich priorytetem było to, że oni totalnie nie wiedzieli, jak ma wyglądać ich UX, totalnie nie wiedzieli, jak ludzie będą z tym pracować, więc potrzebowali błyskawicznie iterować. Potrzebowali bardzo szybko robić zmiany i jak najmniej potrzebowali takiej tej ceremonii dookoła tego. Więc przeniesieli wszystko na front-end, wiedząc, że jeżeli to złapie, jeżeli to się ludziom spodoba, to wtedy będą mieli masę kasy, żeby to naprawiać. Natomiast jeżeli będą szli zbyt wolno, bo będą jechali zgodnie ze sztuką, to nigdy nie będą mieli nawet tej szansy, żeby to naprawić. Więc jak wtedy na to spojrzałem, to stwierdziłem, no w sumie to genialne posunięcie. Nie da się tego krytykować i też ciągle gratuluję. Natomiast jak dla mnie to jest właśnie taki idealny przykład takiego świadomego zaczęgania długu technicznego i kolejne potwierdzenie, że to wcale nie musi być nic złego, jeżeli robimy to świadomie.
Rozgadałem się, sorry. Właśnie mam przypomnienie. Jeżeli ktoś chciałby zadać głos z naszej widowni, prośba o podnoszenie łapek. Mam nadzieję, że nikogo nie przegapimy. Ja tutaj wejdę też. Trochę faktycznie tak, bo tak jak Krzysiek powiedział, że uczą nas, że to, że nas tego uczą, że powinniśmy go unikać i tak dalej, jako długu technologicznego, tylko faktycznie jest tak, że my się o tym dowiadujemy potem, bo ja te pojęcia dług technologicznych przez wiele lat nie słyszałem. Trochę jest też tak, że to my jak w środowisku odnajdujemy, że on istnieje, bo mówimy, słuchajcie, zrobilibyśmy lepiej. Ale właśnie nawet jeszcze dalej idąc tym, co Sebastian powiedział i tutaj ciekawe, co o tym myślicie, bo z zaciągania go można zrobić dokładnie feature swój. Nie wiem, czy pamiętacie ten taki duży artykuł, gdzie WhatsApp napisał, jak oni zaczęli. Był taki wywiad czy artykuł. I oni z zaciągnięcia tak naprawdę długów versus to, co się dzieje dookoła, zrobili właśnie swój sukces, bo oni generalnie doszli do wniosku, że zamiast się męczyć z najnowszą technologią, to generalnie zrobią krok wstecz i zaczną robić to na starszych rzeczach, żeby było szybciej, żeby po prostu działało to dla określonej grupy użytkowników.
Więc oni generalnie stworzyli coś, co było długiem samym w sobie od początku, tylko dlatego, że takim wymyślili sobie biznes model. No i na przykład ja też ze swojego podwórka mogę powiedzieć, że my tam zaczynaliśmy jakąś usługę robić i faktycznie tutaj jest tak, że masz zespół, który generalnie nie wie, jak coś zrobić. No i teraz oni mogą albo zacząć coś robić, albo zacząć się edukować. No i my generalnie podeszliśmy do tego tak, że oni zaczęli coś robić. No i po pół roku w zasadzie to, co zrobili, trzeba było wyciąć do kosza i zacząć robić od nowa. Teraz po którymś tam znowu musimy to przerobić i zacząć ten. Ale inaczej byśmy nie ruszyli. Więc to jest chyba najważniejsza rzecz, tak mi się wydaje, że to nie należy tego postrzegać jako zła, tylko pytanie, na ile to jest świadome. I to trochę się o to pytałem Krzyśka, ale tak jak powiedział, nie widać tego. Czyli na ile to jest świadome, to co robimy, nie? Tomek, rzuciłeś bardzo ważne tutaj, bardzo ważne sformułowanie. Teraz zanim mi ucieknie, bo tak, ja posługuję się często taką grafiką, gdzie po jednej stronie jest krótkoterminowa efektywność, po drugiej stronie jest zdolność do reagowania na zmiany.
Więc to, o czym wy teraz mówicie, czy to, co usłyszałem, to jest przede wszystkim bardzo mocne skupienie na reagowaniu na zmiany, bo nie wiesz, jak będzie wyglądać przyszłość, jeśli spodujesz jakiś rynek, więc podejmujesz świadomą decyzję, że ja się skupiam na tym, żeby jak najszybciej dowieść produkt i będę korzystał z technologii, które może nie są najnowsze, może nie są najlepsze, ale są znane, dobre i ja wiem, że z pomocą tych technologii szybko tam dojadę. To może być albo nie musi być dług technologiczny, zależy od tego, co będzie się działo dalej. Bo jeśli optymalizujesz na jedną zmianę, czy w sensie masz jakiś kawałek do wyeksplorowania i ją szybko wyeksplorujesz i na tym się kończy sprawa, to ty nie wiesz, czy masz dług technologiczny. Dług technologiczny, o długu technologicznym się dowiesz, jeśli rynek zacznie się dalej zmieniać. I na przykład w branży tej lotniczej, jak mamy samoloty, które mają okres wsparcia, powiedzmy, 80 lat, cztery pokolenia programistów, to tam w cenę samolotu wlicza się wielokrotne przepisanie kodu od nowa.
Oni się już po prostu nauczyli, że żadna technologia tyle nie przetrzyma, żaden język programowania, żadne paradygmaty i w zasadzie wiedzą, że będą musieli ten sam samolot, to samo oprogramowanie z nowymi featuremi wielokrotnie przepisać. I to jest pewnie jedna rzecz, która tutaj, ja bym dopowiedział do tego, co Sebastian i Tytomie mówiliście, jak zrobisz szybkie rozpoznanie rynku, masz jakąś platformę, która działa, super osiągnięte ceny i sukces finansowy, pytanie brzmi, czy jesteś przygotowany na dalsze adaptacje do otoczenia, bo jak jesteś, nie ma problemów, jak nie jesteś, to masz dług technologiczny. Czy są finanse zabezpieczone? I to jest ciekawe pytanie, kto spotkał się z tym, że ktoś tak właśnie planuje? Sebastian, Wojtek? Wiesz co, to nawet, ja się całkowicie zgadzam z tym sformułowaniem, bardzo mi się to spodobało odnośnie tego planowania i już jakiegoś przyszłego przypisywania. Nie wiem, czy kojarzycie książkę Wida Larsona, Elegant Puzzle. Tam jest taki bardzo mało wyróżniający się właśnie kawałek, ten kawałek dotyczy rewriteów. I kiedy po raz pierwszy na to spojrzałem, zacząłem czytać tą książkę parę lat temu, to mnie to striggerowało.
Jakie rewritey? Bo mnie się rewritey kojarzą z tym, że jest sobie rzeczywiście jakiś tam stary moloch korporacyjny i w pewnym momencie dochodzą do takiego etapu, że patrzą na jakiś swój wielki, pewnie monolityczny system i stwierdzają, co to za w ogóle tragedia, musimy to teraz przepisać od zera, no i odpalają projekt, trwa pięć lat, w ramach którego powstaje coś gorszego i jakieś wszystkie idealistyczne wizje się rozpadają i tak dalej. Więc sobie myślałem, że ten Larson to przychodzi tam z Uberów, nie Uberów, to co oni też robią tego typu rzeczy. Natomiast on to potem opisuje i właśnie rewrite to jest, cofając się o dwa kroki wstecz, takie projektowanie oprogramowania, żeby dało się je cząstkowo przepisywać, to jest ten efekt łodzi Tezeusza, czyli programowanie składa się z części, które możemy przepisać i potem tak naprawdę okazuje się, że nie ma już żadnej oryginalnej części. Każda z tych części tego oprogramowania ma jakąś swoją datę przydatności do spożycia, czyli jest założenie, że na przykład w ciągu tylu a tylu lat albo przy przekroczeniu takiego a nie innego warunku, czyli na przykład skali, że coś piszemy na skalę na przykład na chwilę obecną, ewentualnie o dwa rzędy w górę, a jeżeli to przekroczymy, to już musimy przepisać. I oprócz tego, no bo to wymusza pewnego rodzaju projektowanie, czyli musimy mieć pewnego rodzaju loose coupling,
musimy mieć jakieś takie bardzo dobrze zdefiniowane kontrakty i to tak naprawdę, to podpisanie pod rewrite'y, czy ze świadomością tego, że będziemy to przepisywać i że nie ma w tym nic złego, to był trochę fundament tego blitzscaling'u, tego szybkiego skalowania platform, które potem nie znikały gdzieś pod takim naporem długu technologicznego. Więc jak dla mnie to jest jedna z podstawowych technik, to trochę wyprzedzamy, bo myśmy o tym powiedzieli trochę później, zarządzania długiem technicznym, czyli ciężko jest walczyć z długiem technicznym w zasadzie takiego inkrementalnego zmniejszania, czyli siądźmy teraz i refaktorujmy, bo to się bardzo rzadko sprawdza, natomiast znacznie łatwiej jest ten dług odcinać na takiej zasadzie, że no dobrze, mamy tutaj ten kawałek, pisaliśmy go przy innych założeniach, te założenia się nam zdezaktualizowały, teraz mamy trochę inną rzeczywistość, napiszmy ten kawałek, ale w separation, odseparowany na nowo, zgodnie z tymi nowymi regułami, patrząc przez pryzmat nowego kontekstu, to taki sposób odcinania to jest, uważam, jeden z bardziej efektywnych sposobów walki z długiem technicznym.
Tutaj ja też mogę dodać, bo Tomku zapytałeś o doświadczenia, to ja mogę powiedzieć, że mam o tyle szczęście, że widzę to na co dzień, tego typu decyzje i coś, co się fajnie sprawdza, to zbudowanie pewnych zasad, gdzie jesteśmy w stanie się umówić właśnie na co się godzimy, jakiś jasny kontrakt, i żeby podejmować świadomie decyzje, i te rejty, o których Sebastian mówisz, też świadomie podejmować, czyli na przykład w firmie, w której ja teraz pracuję, jest coś takiego jak bety, i betem jest po prostu najczęściej nowa funkcjonalność, nowy produkt, i bet z założenia może… tam optymalizujemy podczas i sprawdzenie danej rzeczy. Jeżeli to wszystko jest okej, następuje pierwszy rewrite. Drugi rewrite, przepraszam, jest w momencie osiągnięcia ogromnej skali, i wtedy się optymalizuje pod całkiem inne rozwiązania.
Chodzi o to, żeby od początku nie zrobić over architecture, tylko zoptymalizować bardzo mocno na weryfikację pomysłu biznesowego. To jest przykład organizacji, w której ruszasz się szybciej, albo właśnie robisz te eksperymenty. Problem zaczyna się wtedy, jak masz organizację, która… a tak jest, że mówiąc, to wiecie, chyba większość firm spadnie w ten bucket, organizacji, które nie działają w ten sposób. Bo jak ja myślę o… my teraz mamy trochę inne doświadczenia, znaczy w tej chwili przynajmniej, ale jak ja myślę o firmach Enterprise, to tam organizacji, które mogą działać w ten sposób, tak jak powiedziałaś, to jest mało. Ale szczerze to chyba nie spotkałem, nie? A z drugiej strony, jak popatrzysz, to wiele organizacji Enterprise udaje się z coraz większym sukcesem przejść w taki model. Bo na przykład, jeżeli byśmy zobaczyli to, co ostatnio robi Microsoft, to jest dokładnie to. Czyli wiesz, bardzo już potężna firma, której udało się zmienić core myślenia takiego biznesowego, i faktycznie udała się w tą kulturę, tak jak mówimy, natomiast to jest pewnie całkiem inny odcinek.
To oni musieli wyobserwować innowation do innej firmy, to OpenAI było tak naprawdę źle do tej informacji, natomiast jak to wpłynęło na całą kulturę Microsoftu i czy Microsoft ma z tym wiele wspólnego, to dopiero się przekonamy. No wiesz, tam jest dużo więcej produktów, GitHub chociażby, i wszystkie narzędzia developerskie. Natomiast słuchajcie, ja mam, żeby wrócić, bo to całkiem inny odcinek. Ja mam do was pytanie, może trochę przewrotne. Krzyśku, z twojej perspektywy i doświadczenia, czy da się budować produkty bez długu technologicznego? Czy to ma sens? I kiedy, jeżeli tak, to kiedy w ogóle coś takiego robić? Oj, dobra, więc tak. Tutaj ktoś wcześniej powiedział, że dług technologiczny jest zawsze. Długu technologicznego nie ma tylko w przypadku, kiedy jesteś w stanie zaadaptować się do zmieniających się warunków na rynku, a taka sytuacja nigdy nie występuje, bo to wymaga nieskończonych zasobów. Więc zawsze jesteś gdzieś w skali, zawsze jesteś gdzieś na skali tego długu technologicznego. On jest mniejszy lub większy, ale zawsze masz jakieś decyzje, które już zostały podjęte i które cię ograniczają
na przyszłość i które będą cię spowalniać. I teraz budowanie produktów bez długu technologicznego, czy nawet z minimalnym długiem technologicznym, bardzo mocno zależy od podejścia finansowego. Bo jeśli masz, powiedzmy, budżet i w określonym budżecie musisz zbudować produkt, który robi miliony feature'ów i inne rzeczy, to tam będzie dług technologiczny i niestety to jest tak, jak działają duże korporacje, gdzie najpierw zleca się system, przechodzi przez procurement i potem zostaje wybrany dostawca. Tam dług technologiczny powstanie, bo to jest mocno przy tradycyjnym modelu wyceny, zawsze będzie niewyszacowane i potem zawsze dostawcy przytną właściwy design po to, żeby dowieść funkcjonalności w czasie. Natomiast jeśli mamy firmę, która jest nastawiona bardziej na usługi, czyli coś jest w modelu tym as a service i programiści, nie powiem, że mają wolną rękę, ale są bardziej skupieni na utrzymaniu biznesu niż na samym czystym kodzie, mają to myślenie, w sensie czy wysiłek włożony w dewelopowanie nowych feature'ów,
czy w usuwanie długu technologicznego jest właściwym wysiłkiem. Oni podejmują tę decyzję i oni będą mierzyć się z konsekwencjami. To wtedy oprogramowanie, które powstaje, powinno być dużo zdrowsze i obarczone mniejszym ryzykiem długu technologicznego. Oczywiście to Cię nie uratuje przed wielkimi zmianami na rynku, bo może się okazać, że cały produkt, w ogóle rynek się skończył na daną usługę. Jak najbardziej, ale w tym podstawowym zakresie to będzie trochę, wydaje mi się, lepiej. Nie wiem, czy odpowiedziałem na pytanie, czy po prostu jeszcze zrównatwca... Chłopaki się odniosą, to ja tylko zrobię krótki call to action. Słuchajcie, jest nas kilkadziesiąt osób. Jeżeli macie swoje doświadczenia w temacie, to włączcie się. Nie wiem, żaden z Was nie walczył z tym w firmie, więc nie płakał, nie patrzył na ten kod i się zastanawiał albo infrastrukturę, bo to nie tylko kod, tak jak Krzyś powiedział, i się zastanawiał, kto to zrobił. Jakbym to zrobił lepiej i poszedł z tą propozycją gdzieś i dostał po głowie, więc ja bym z chęcią odsłyszał, dlaczego.
Także dołączcie do dyskusji. Klasyka firm budowlanych, jak przychodzi, wiesz, kontynuować remont po poprzedniej ekipie. No właśnie, Sebastian, może Twój punkt widzenia na temat takiego czystego bardzo budowania, czy jest to możliwe w ogóle? My w sumie nie powiedzieliśmy o jednej rzeczy, pewnie dlatego, że uznajemy ją wszyscy za tak oczywistą, że stwierdziliśmy, że nie będziemy o tym gadać. Dług techniczny, ważne jest zrozumienie jego konsekwencji, bo jego konsekwencje nie są na moment podejmowania decyzji o długu, ten świadomy czy nieświadomy, tylko one bardziej są już odłożone w czasie. Czyli na przykład wpracowanie pewnego długu technicznego może oznaczać, że my coś robimy wolniej albo robimy więcej jakichś błędów, albo może się okazać, że są większe problemy z podejmowaniem decyzji w przyszłości, bo są jakby mniej jasne, że pojawiają się jakieś defekty, downtime, więcej błędów, więcej ogólnie pracy, która nie dodaje jakiejś wartości, jakiegoś toilu i tak dalej.
A więc ja bym powiedział już teraz odnosząc się do samego pytania, jeżeli my nie mamy żadnego długu technicznego, to jest dobry wskaźnik, że coś jest na mnie tak. Znaczy, że nie musieliśmy podjąwać żadnej trudnej decyzji, nie musieliśmy czegoś poświęcić, bo to oczywiście kontekst jest king, czyli czasami pewne rzeczy możemy poświęcić, bo one są dla nas po prostu taniej, nie zależy nam na nich aż tak bardzo, bo optymalizujemy się pod innym kątem. Jeżeli nie mamy żadnego długu, to znaczy, że być może za bardzo stawiamy na perfekcjonizm i skupiamy się na tzw. sukcesie technicznym, a nie na sukcesie biznesowym. Więc jak dla mnie, jeszcze raz podkreślę, w ogóle był taki fajny trend swego czasu gdzieś tam w mediach społecznościowych, właśnie, że dług techniczny jest złego rodzaju abstrakcją, nie używajmy jej, że to jest po prostu cena podejmowania decyzji. Więc jeżeli my nigdzie tej ceny nie pokazujemy, nie uwzględniamy i jej też nie widać, to jak my tę decyzję podejmujemy? Widać, że dołączył do nas Tomek. Tak. Cześć wszystkim. Tak się przysłuchuję i faktycznie, sam powiem sobie z swojej perspektywy, o długu technologicznym dowiedziałem się dopiero po pięciu latach programowania, jak mi program SonarCube powiedział, że coś takiego istnieje. I wtedy zacząłem się dowiadywać, co to jest i jak.
I tak naprawdę, no, już po tych doświadczeniach, co mam, no to chyba wszyscy muszą żyć z długiem, bo nie wyobrażam sobie właśnie firmy, gdzie nie ma długu. Chociażby dlatego, że dobra, skupiamy się na kodzie. Fajnie. Staramy się, żeby on był jak najmniej pozbawiony właśnie długu. Może się nawet udać. Ale przychodzi wtedy właśnie temat architektury i chociażby takiej, no, pewnej rewolucji, która była swojego czasu, czyli mieliśmy wirtualne maszyny, nagle mamy konteneryzację. I to wcale nie jest tak łatwo nawet najlepszy program przystosować. Więc uważam, że nie da się go pozbyć, a trzeba z nim żyć i się z nim tak naprawdę zaprzyjaźnić. Bo raz będziemy potrzebowali właśnie zaciągnąć, a raz nie będzie problemu, że go mamy, bo nie wiem, mamy rozwiązanie, które ma zadziałać pół roku, rok, ma coś zrobić. Tam się nie będziemy przejmowali, że jest jakikolwiek dług. I też druga sprawa, ostatnia, znaczy tak mam nadzieję, że ostatnia, to, że my chcemy walczyć z długiem, nie znaczy, że osoby, które przyjdą po nas albo były przed nami, mają takie same podejście.
Więc może się okazać, że nawet jeżeli nam chce się z tym działać, mamy na to plany, no to są inni deweloperzy też, inne osoby w firmach. To tyle. Ja tutaj bardzo chętnie się odniosę do czegoś, co zarówno Sebastian powiedział, jak i ty, mówiąc o tym, czy da się budować bez długu. Bardzo często to jest bardzo istotne, jeżeli mamy wrażenie, że budujemy bez długu, bo jesteśmy pasjonatami clean code, clean architecture, jest jedna bardzo ważna, ukryta zależność. Nawet jeżeli, załóżmy, jakimś sposobem, nie mamy długu procesowego, nie mamy długu, jeżeli chodzi o nasz software development lifecycle, mamy piękną architekturę, to używamy języka frameworków, vendorów, naszych mur, narzędzi itd. Tam jest mnóstwo ukrytego długu technologicznego, którego też nie rozumiemy, nie jesteśmy łatwo w stanie zmierzyć. To jest też bardzo istotne, bo myślę, że zaraz przejdziemy do rady, jak zarządzać długiem technologicznym, jak go mierzyć itd.
Ale nie jesteśmy tego w stanie się dowiedzieć i to jest bardzo istotne. I to też łączy się fajnie z tym, co ty, Krzyśku, powiedziałeś, czyli właśnie tego, że tak naprawdę to wszystko sprowadza się do decyzji biznesowych i po co optymalizujemy. Natomiast słuchajcie, przechodząc właśnie bardzo płynnie, bo to już padło kilka razy, jak mierzyć dług technologiczny? Czy możemy to robić, jak mierzyć? On ma wiele aspektów, jednym z nich jest kod i wspomniany Sonar Cube. Jak wy podchodzicie do mierzenia długu technologicznego? Jak mam tak wywołać, to może Sebastian. Okej. To tak w telegraficznym skrócie. Mierzyć możemy kilka rzeczy. Po pierwsze, mierzyć możemy to, co… Efekty długu to jest jedna rzecz i takie najbardziej namacalne efekty, które możemy mierzyć, to np. czas kompilacji, ilość błędów, ilość sfejlowanych release'ów, to jest ilość zależności, które np. mamy. Czyli takie kwestie, które są istotne z perspektywy tego kątu, pod którym my optymalizujemy.
Czyli np. jak optymalizujemy pod prędkość, to co tą prędkość nam zmniejsza. Jeżeli jakość, to co to jakość nam zmniejsza. To jest jeden taki rodzaj, który możemy mierzyć. Kolejna rzecz, którą możemy próbować mierzyć, jeżeli chodzi o dług technologiczny, to są jakieś negatywne zjawiska, które w tym długu mamy. Czyli przykładowo, nie wiem, czy kojarzycie taki koncept jak lava flow effect. Lava flow effect to jest koncept, w którym mamy jakąś architekturę i w pewnym momencie ta architektura rozwiązania nam się nie podoba, przychodzi mądry deweloper i mówi, że to mam pomysł na lepszą, zaczyna ją wprowadzać, robi to jakoś eksperymentalnie, zdąży zrobić to w jednej trzeciej, a potem albo się zniechęci, albo zmieni firmę, albo zmienią się priorytety i zostajemy z dwiema architekturami, starą i nową. No i tak przypomina to trochę to, jak lava wypływa z wulkanu, czyli płynie sobie takimi zygzakami. I teraz mierzenie w takim kontekście po prostu oznacza, że my widzimy, jak dużo mamy tej starej architektury, której chcielibyśmy się pozbyć, mierzymy to, nie wiem, w czymkolwiek, w klasach, kontrolerach, mikroserwicach i tak dalej, mierzymy tę ilość i śledzimy, w jakim tempie się tego pozbywamy. To jest inny sposób na to, jak można ten dług techniczny mierzyć. Jest jeszcze ten sposób,
o którym powiedział Krzysiek, czyli na przykład już patrzymy na pod kątem velocity, ilości pitcherów, tych zmian atomowych. To nie jest takie proste, bo czym jest zmiana atomowa? Jedną zmianę do drugiej zmiany też nie jest za każdym razem łatwo porównać. Natomiast jeżeli chodzi o takie sposoby mierzenia, to to są te chyba takie najbardziej oczywiste, tak mi się wydaje. Ja mogę zaproponować jeszcze jeden sposób, ale to w sumie teraz, dopiero jak się zastanowiłem, to do mnie to dotarło. Bo ja się tym długim technologicznym zajmuję, ale jak padło pytanie, jak wy to mierzycie, to dotarło do mnie, że ja tego po prostu nie robię. Albo inaczej, jest bardzo nieoczywista miara, tylko nieświadoma i nigdy nie myślałem, że to jest miara, a to jest poziom bólu dla CIO i CPO. Ok, powiedz coś więcej. Bo czasami się zdarza, znaczy tak, ja pracuję dla firmy, która owszem ma jakiś tam dział wytwarzania, opowiadania i w ogóle, ale ja jestem bardziej na styku rozmów z klientami i często pada właśnie pytanie, co dla danego klienta można zrobić, co jest dla niego największym wyzwaniem i w ogóle.
I dla ludzi, z którymi czasami rozmawiam, dług technologiczny jako miara, czy jako metryka, jest bardzo odległym konceptem. Oni się tym w ogóle nie chcą, albo nie przejmują, o ile to nie wypłynie w jakiś bardziej istotny sposób. Co jest istotne, to jest jak wysoko to jest w liście korporacyjnych priorytetów. Czyli jeśli konkurencja danego klienta, powiedzmy, prześciga i dostarcza featury i zmienia się szybciej niż klient może, to wtedy nagle dług technologiczny staje się problemem, którego nawet nie trzeba mierzyć, tylko trzeba rozwiązać. No właśnie, to... Natomiast... A jeśli to nie jest problem, no to sorry, to nie jest problem, to my tego w zasadzie nawet nie musimy mierzyć, nie musimy analizować i inni ludzie się gdzieś tym zajmą. Ja może wejdę... I to prowadzi czasami do takich... Ok, dobrze.
Sorry, ja próbowałem zadawać pauzę, ale to ten... Przepraszam być tym... Ale właśnie, bo jak to powiedziałaś, moje doświadczenie... Ja nie spotkałem się z żadną organizacją, która to mierzyła w żaden sposób. Faktycznie moment tylko znowu... Ja nie pracowałem przez ostatnie naście lat w firmach produktowych na przykład, nie? Ale współpracując z firmami, które niektóre były produktowymi, to był faktycznie ten poziom bólu, który to wydbało. Czyli te firmy nie miały metryki, która mówiła, to jest nasz dług, to jest coś, co musimy naprawić i tak dalej. Tylko te firmy miały metryki pod tytułem... Taki bardzo konkretny przykład. Pracowaliśmy z firmą, która zajmuje się medtech i ich trigger do tego był, że po prostu przyszedł biznes i powiedział, za wolno wypuszczamy produkty na rynek, konkurencja robi to szybciej. I do tego momentu w ogóle się nie zastanawiali, że to, co robią, to jest dług. Tylko w momencie, kiedy firma przyszła do nich i powiedziała, nasze produkty wychodzą rzadziej na rynek niż konkurencja, to wtedy musieli się zastanowić, dlaczego.
I to było ciekawe, bo faktycznie nawet z zewnątrz ktoś musiał im powiedzieć, to akurat byliśmy my, że to, co robią, to jest coś, co jest po prostu stare i to ich spowalnia, bo oni akceptowali to po prostu jako to jest sposób, jaki robimy. Więc to było bardzo nieuświadomione, nie było na tym żadnej metryki do momentu, kiedy nie było triggeru z zewnątrz. I drugi taki przykład nawet miałem gdzieś tu w Polsce, gdzie trigger też jest z zewnątrz, czyli CIO przychodzi i mówi, musimy zmienić swój produkt, jak to zrobimy. No i wtedy wychodzi cała lawina pod tytułem, okej, no to mamy takie nawarstwione rzeczy, aż do poziomu organizacji. No to ja mogę powiedzieć, że my to u nas mierzymy, mierzymy to bardzo rygorystycznie. Nie jest to zagregowane na poziomie jednej metryki, którą ktoś mógłby nazwać długiem technicznym, natomiast są to właśnie metryki, które tak suma sumarum składają się na ten dług. To ja tutaj zgodzę się, chociaż powiem, że dopiero się też ten temat mocno zaczął rozwijać w filmie, w którym ja teraz pracuję.
Ja bym jeszcze chciał tutaj nawiązać do tego, co powiedzieliście, natomiast troszeczkę może skręcić i kolejny raz, i kiedy i jak likwidować dług, i to, że nie każdy dług zawsze jest zły. Na przykład jedna z heurystyk, która myślę, że jest bardzo dobra, to jest jeżeli już zaczniemy rozumieć nasz dług technologiczny, jakkolwiek to zrobimy, dobrze jest też zrozumieć nasz produkt i jak on, z czego właściwie się składa. Tutaj z bardzo fajną pomocą może nam przyjść kilka wzorców strategicznych z DDD i mianowicie inaczej będziemy refaktoryzować zarówno procesy, jak i architektury, jak i kod naszych core'owych części naszego produktu, a całkiem inaczej, generyczne czy supportujące, czyli generyczne, to są skomplikowane problemy, które już zostały rozwiązane, czyli na przykład, wiecie, ten mityczny chociażby system fakturujący.
Nie musimy pisać własnego, możemy go kupić, zlikwidować, odciąć, tak jak Sebastian mówiłeś, grubym cięciem dług technologiczny, kupując gotowy produkt z spółki i integrując. Jest ok, w ogóle nie wpływa na naszą... Połowa zespołu tworząca faktury naprawdę będzie Cię przekonywała, że ich problem jest unikalny. Nie, nie, nie. Jeżeli, powinienem dodać, jeżeli moim core'owym produktem oczywiście nie jest system fakturujący lub system rozliczeń jakichś fiskalnych, więc jeżeli to jest domena faktycznie dla mnie generyczna, to całkiem inaczej do tego podejdę. I teraz jeszcze jedną rzecz chciałem dodać ze swojego doświadczenia. Dobrze jest zmierzyć ilość zmian, czyli stabilność, powiedzmy, tego kodu, do ilości bugów, bo jeżeli nawet coś porosło mchem i, wiecie, tam wiatr hula, natomiast tych zmian nie ma, czyli ten kod jest stabilny, nie ma bugów, to bardzo często zespół, który przychodzi z prośbą o refaktoryzację, robi to, bo się nudzi na przykład, prawda?
Natomiast do czego pijesz? Wtedy bardzo ważne jest, żeby zrozumieć faktycznie co i kiedy refaktoryzować, jak likwidować ten dług technologiczny. No i oczywiście wtedy mamy sytuację, jak często mamy zmiany, zrobić sobie taki kwadrant, ile mamy bugów do tego, czyli ile mamy defektów i wyjdą nam bardzo ładnie priorytety do refaktoryzacji i względu na typ tego, o jakim części naszego produktu mówimy, możemy podjąć właściwe decyzje. Jak wy do tego podchodzicie? Ja mam taką myśl trochę też, tak jak Krzyś powiedział, że przyszło mi w trakcie tej rozmowy, trochę też zainspirowana tym artykułem, który ostatnio Sebastian się podzielił, o opisaniu strategii i inżynieringu, bo też jest kwestia tego, że my ten dług wprowadzamy nawet, bo dług przeważnie kojarzy się z czymś starym, z coś co było i tak dalej. I przyszła mi taka myśl do głowy, że my tak naprawdę wprowadzamy dużo tego przez próbowanie rzeczy nowych i wkładanie ich na produkcję na przykład.
Czyli ktoś wpada na pomysł, wezmę jakiś nowy framework, przetestuję go i zrobi produkt i to idzie, i to tworzy różnego rodzaju rzeczy. Więc na przykład jedną z takich rzeczy, które jest zdefiniowanie jak pracujemy i taki indykator, który wydaje mi się byłby sensowny, ale to jest tylko pomysł, to jest patrzenie na to, ile mamy requestów o to, żeby to zmienić. No bo jeżeli mamy jakieś założenia jak pracujemy, jest pytanie, ile nowych rzeczy nam wchodzi, które się z tym nie zgadzają, bo wtedy to jest albo ktoś już nam odstaje od tego, co robimy, czyli ludzie chcą robić inaczej z jakiegoś powodu, a my, i to nie jest zgodne z tym, jak działamy, więc albo te nowe requesty są złe, albo to, co mamy, staje się naszym legasy, albo to pozwala nam to ograniczyć, bo mówimy, ok, robimy mniej na nowych rzeczach, ale za to nie tworzymy sobie takiego graveyard rzeczy niesprawdzonych. To taka myśl trochę z boku.
Ja mam jeszcze szybki wtręt w kwestii rozwiązywania. Ja widzę takie trzy podstawowe ścieżki i te różne inne się bardzo często umieszczą w ramach tych, więc pierwsza ścieżka to jest taka ścieżka typowo managementowa, czyli właśnie, nasz główny efort na początku to jest, żeby zmierzyć, bo wszystko, co zmierzymy, możemy tym zarządzić. Potem już jesteśmy w stanie śledzić trend, jesteśmy w stanie śledzić w czasie, widzimy, jakie są tego efekty i nawet eksperymentalnie możemy podejmować się różnych kroków i wtedy widzimy, czy coś się z tym dzieje, czy nie. Oczywiście to jest pytanie, czy to dobrze mierzymy, czy nie, ale to też jest kwestia, coś, co trzeba sobie wypracować. Więc to jest pierwsza ścieżka. Druga ścieżka nazywa się ścieżką podatkową i ona jest skuteczna w wielu organizacjach. Ścieżka podatkowa polega na tym, że sobie uzgadniamy, czyli na przykład 20% naszych story pointów, czy tam w czym się mierzymy, jakiejś miary, velocity, idzie na przykład na walkę z drugiem technicznym. No i to jest taka ścieżka, która często jest pułapką, no bo te punkty, czy tam ten czas jest często przepalany na taki tak zwany pseudo-refactoring, czyli bawimy się, żeby kod był czystszy, ja nienawidzę tego określenia, czysty kod, czy piękniejszy, czy whatever.
Więc tutaj tak czy siak trzeba wprowadzić pewnego rodzaju reżim. Jest jeszcze ta trzecia ścieżka. Ta trzecia ścieżka jest najbardziej radykalna i czasami wychodzi w jakichś takich mega popularnych postach na tam LinkedInach i tak dalej, gdzie firmy przyjmują sobie jakiś bardzo konkretny framework do tego, który czasami jest bardzo radykalny, kontrowersyjny, no i teraz czasami to działa, czasami nie. No takim przykładem jest słynny swego czasu immutable code, czyli po prostu jak piszemy, to szatkujemy to na takie mikroserwisy, mikrofunkcje, mikro coś tam, ale piszemy je już tylko raz. Czyli potem za każdym razem jak mamy ją zmienić, to de facto piszemy ją od nowa. I to jest taki sposób, gdzie mamy ciągłe te resety tego długu i ciągle pozbywamy się jakichś takich starych zależności. No wtedy też zakładamy, no okej, to jest pewnego rodzaju w specyficznych firmach to może zadziałać, to jest jeden z przykładów podejścia radykalne i ono ma szansę zadziałać tylko i wyłącznie wtedy, jeżeli się go trzymamy wręcz religijnie, czyli tutaj nie mamy żadnych kompromisów. Jest taki, jeżeli chodzi o takie trzy ścieżki podejścia do długu, to ja bym wyróżnił takie. Czy się spotkałeś się może z czymś innym, oprócz tego co mówimy, z tym gdzie rozmawiałeś z firmami?
Wszyscy tak, wśród ludzi z którymi rozmawiałem, to tak jak wcześniej, tak jak wcześniej wspomniałem, że to jest po prostu poziom próg bólu i jeśli ten, z mojego punktu widzenia, jeśli ten próg bólu będzie wystarczająco mocny dla organizacji, wówczas w organizacji formuje się, jakby to powiedzieć, taka, nie wiem, grupa ludzi, czy taki punkt widzenia, że dług technologiczny trzeba usunąć, że trzeba zainwestować i przydzielić wystarczający budżet, żeby w końcu zrobić rzeczy trochę lepiej niż były zrobione i w związku z tym po prostu wszystko, wszystko zaczyna się toczyć. Szczegółów na niższym poziomie, znaczy na poziomie bardziej technicznym, to nie jestem po prostu, nie jestem w stanie powiedzieć jak to się dzieje, bo myślałem, że wtedy są wszystkie te techniki w jakimś, w jakimś zakresie stosowane.
Mój punkt, moje skupienie jest właśnie na tym, jak tych ludzi przekonać do tego, żeby w ogóle zająć się tematem długu technologicznego albo jeśli chcą się zająć, jak pomóc organizacji to, znaczy podejść do tego tematu, bo był to temat zaniedbany przez poprzednie lata. To Krzyśku, bardzo fajnie nawiązałeś do ostatniego pytania, które aż mi się ciśnie na usta. Jesteśmy osobami inżynierami, osobami technicznymi, musimy na co dzień negocjować naszą pracę z osobami nietechnicznymi. Jak rozmawiać o tym długu? Jak rozmawiać z osobami nietechnicznymi, z Twojego doświadczenia? Ja może zanim się o tym odpowiadać, to trochę doprecyzuję albo pociągnę drugą część pytania. Jak już z nimi rozmawiamy, to dlaczego oni mogą nie chcieć tego rozwiązywać? Dobrze. To jest coś, co jeszcze wyszło powiedzmy z researchu, było przetestowane na bardzo wąskiej grupie klientów i najważniejszą rzeczą w organizacji, jako z punktu widzenia osoby technicznej,
jest doprowadzenie do tego, żeby decyzje i koszty długu technologicznego były podejmowane przez jedną i tę samą osobę. Nie może być takiej sytuacji, że Wy jako osoby techniczne dostaniecie budżet, który nie pozwala na zrobienie rzeczy w prawidłowy sposób, nieważne co znaczy prawidłowy, czy zgodnie ze sztuką, czy optymalizacja na zmianę, coś co widzicie prawidłowy. Wy będziecie musieli zrobić kompromisy i będziecie w przyszłości cierpieć z powodu długu technologicznego, bo będą Wam mówić, że nie dowodzicie na czas albo inne rzeczy, a ktoś inny pokaże, że Wy robił rekordowe zyski, bo akurat w tym roku wszystko się tak spięło i w przyszłym roku tej osoby już nie będzie. Więc z Waszego punktu widzenia, czy z punktu widzenia osoby odpowiedzialnej za technologię, trzeba mówić o konsekwencjach, które będą. I taki przykład Wam podam z firmy, dobra nazwę nie mogę powiedzieć, ale mieli taką sytuację, że przyszedł dział biznesowy, powiedział, że mają plan na trzy lata i życzą sobie, żeby im ustawić chmurę obliczeniową w Amazonie.
Zoptymalizowaną najlepiej jak się da. No wiecie, że jak się optymalizuje chmurę, korzysta się z tych reserve instances itd. I potem biznesowi się okazało, że nie idzie tak dobrze jak trzeba i chcieli zdestalować tę chmurę bardzo mocno w dół. Wyobrażacie sobie, jaki był problem z długiem technologicznym w tej sytuacji, bo zrezygnowali, w sensie podjęli decyzję, a dział technologiczny w tamtym czasie nie był w stanie wyedukować klienta na temat konsekwencji decyzji. I skończyło się na tym, że dział technologiczny ponosił konsekwencje, czyli koszty tej chmury, a nie wewnętrzny klient, który podjął faktyczną decyzję. Z mojego punktu widzenia doprowadzić do tego, że jedna osoba jest odpowiedzialna i za decyzję o dług technologiczny i za potencjalne korzyści, albo w dziale IT, albo tak podnosić wewnętrzne koszty czy wewnętrzne szacunki, żebyście mogli zrobić rzeczy prawidłowe. Oczywiście może to znaczyć, że trzeba będzie zmienić pracę, no właśnie, ale to już jest kwestia wewnętrznych priorytetów, jak bardzo chcemy się dać.
Tu trochę wróciliśmy do tego, o czym mówił Sebastian, no bo pytanie, czy najlepszą miarą w ogóle nie jest w jakiś sposób przypisanie do niego kosztów. I teraz pytanie, jak go ustalić, ale i kogoś, kto ponosi ten koszt. Bo według mnie, tak patrząc, problem jest z równe tą odpowiedzialnością albo unersiwem tego. No bo pytanie, dlaczego ktoś miałby się tym zająć, jak nie ponosi konsekwencji, tak jak powiedzieli, w szczególności, jeżeli, to wcześniej mówiliście, jeżeli ma jakieś krótkoterminowe benefity, nie ponosi konsekwencji decyzji pod tytułem zróbmy to tak, bo za rok i tak mnie tu nie będzie, albo ja już będę się zajmował czymś innym, albo odchadzę ten sukces i zostanie to komuś do utrzymania. A teraz przypisanie do tego kosztu, który ktoś musi ponieść. I tu pewnie dałoby się, krótko mówiąc, też na przykład wymyślić jakąś funkcję pewnie zwiększania tego kosztów czasie, nie? Czyli jeżeli nie zajmujesz się tym rozwiązaniem i patrzymy na jego utrzymanie i tak dalej, to koszty go rozwiązania coraz bardziej rośnią, ona obciąża twój budżet, nie? No to to by pewnie wymusiło w jakiś tam sposób podejście do tego usystematyzowane.
Czyli niestety bardzo ciężko jest to mierzyć upfront, czyli jeżeli na przykład przychodzi osoba produktowa z jakimś pomysłem i jakimś wymaganiem, słuchajcie, musimy to zrobić w ciągu na przykład miesiąca, dwóch czy trzech, czy tam w możliwie najkrótszym czasie, to teraz powiedzenie takiej osobie, że no dobra, zróbmy to na przykład mniej więcej trzy tygodnie, ale powolni to nasze tempo developmental w najbliższym półroczu, o 13,5% jest nierealne. Więc no niestety jest to kwestia pewnego zaufania, jest to kwestia pewnego wytłumaczenia na jakichś paralelach, na porównaniach, jak dług techniczny wygląda w innych organizacjach, żeby to nie było tak, że my sobie coś wymyślamy, bo tu niestety chodzi o to credibility, musimy trochę zilustrować na czym to polega i z czego to wynika. I jeszcze raz wrócę, jak wiemy z takim uporem maniaka, no kluczowe jest to mierzenie, czyli my nie zmierzymy tego upfront, ale my powiemy, że słuchajcie, to spowolni, to będzie miał efekt negatywny, na przykład w czasie kompilacji, czy w czasie dostarczania, czy w ilości efektów, czy w czymkolwiek innym, w czasie onboardowania klienta, whatever, musimy po prostu mieć na pokładzie ludzi, którzy faktycznie to mierzą i też za to są odpowiedzialni.
U mnie kiedyś w jednej firmie fajnym sposobem na poradzenie sobie z długiem technicznym było tak naprawdę ustanowienie stanowiska, head of DX, head of developer experience i ta osoba była odpowiedzialna za to, żeby nie tylko jakoś tam edukować, nie wiem, prezentację z tego robić, ale właśnie zmierzyć, przyjrzeć się, gdzie ten dług jest najbardziej bolesny i też mieć duży wpływ na road mapy poprzez wstawianie nam takich historii, projektów, tematów, które nam ten dług zmniejszą i również otagowanie tych tam pomysłów tym potencjalnym zyskiem. Może nie do końca w temacie ile procent zyskamy, czy ile dni zyskamy i tak dalej, ale jak one się mają względem siebie, czy na tym zyskamy więcej w koszulkach, w XL, na tym zyskamy średnio, M, a na tym nie zyskamy praktycznie wcale. Więc to był też taki mały hint, co takie fajnie działało. Tak, ale to właśnie o to mi trochę chodziło, że nie da się tego zmierzyć upfront, nie wiesz jaki on będzie, bo może być, że nawet decyzja, którą podejmujesz, ona po prostu bardzo długo będzie dobrą decyzją następne 10 lat i nie będzie powodowała żadnych problemów. I tutaj, wiesz, to jest kwestia przypisania każdemu baseline, czyli mówimy, twój koszt jest 100, znaczy jak wprowadzasz nową funkcjonalność czy cokolwiek i potem patrzenie na to,
czy ten kosztuje operations tego, czy jest robiony rewrite, jeżeli tak, to ci cofa licznik, a jeżeli nie, to co roku ten licznik ci rośnie w górę. No i w ten sposób po prostu jest, że jeżeli nie zajmujesz się tym aktywnie, tak jak nawet powiedziałaś, że po prostu nie masz odhaczonego takiego check z boardem jakimś technologicznym, który mówi tak, to dalej jest dobre rozwiązanie, ale twój dług, krótko mówiąc, zaczyna się narastać, narastać i on jest widoczny, że wiesz, dług tej części firmy urósł, a tej nie. No i wtedy wiesz czym się zająć. Taki pomysł po prostu do porozmawiania może następnym razem. Dobrze, mamy 32, wszyscy są gotowi do zajęcia się codziennymi stand-upami. Ja prawie jestem gotowy do wyjścia na miasto w ramach krótkich wakacji, więc będziemy zawijać. Krzyśku, serdecznie ci dziękujemy za dołączenie do nas i podzielenie się swoim doświadczeniem. Było nam niezmiernie miło cię gościć. Cała przyjemność po mojej stronie, dziękuję.
Dzięki jeszcze raz. My słyszymy się już za dwa tygodnie, także nas słuchujcie na naszych social mediach. Będziemy na pewno zapraszać kolejnych gości, taki jest też nasz cichy plan. No i nie pozostaje nic, tylko podziękować wam za dyskusję i życzyć bardzo miłego dnia i udanego weekendu. Trzymajcie się. Dzięki bardzo, trzymajcie się, hej, cześć, miłego weekendu. Napisy stworzone przez społeczność Amara.org Chwila, przyjechał?
