To jest 19. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o wpadkach, błędach i fakapach w IT. Koniecznie powiedz koleżankom i kolegom w pracy o tym odcinku.

Witam Cię serdecznie w Porozmawiajmy o IT. Ja się nazywam Krzysztof Kempiński i w tym podcaście rozmawiam z moimi gośćmi o branży informatycznej, przedstawiam trendy, zjawiska i opinie. Staram się przybliżyć tę branżę tym, których w niej na co dzień nie ma, jak również zaciekawić stałych bywalców. Pozostań z nami.

A teraz zapraszam już na kolejny odcinek.

Krzysztof: Cześć! Moim dzisiejszym gościem jest programista z wieloletnim doświadczeniem, silniej związany z technologią Dot Net. Jak sam mówi o sobie, z plastyki miał 3, stąd jego fascynacja backendem. Dał się poznać w konkursie Maćka Aniserowicza. Jest prelegentem, blogerem, osobą aktywizującą polskich programistów, poprzez różnorodne inicjatywy. Ostatnio również został podcasterem. Jest twórcą podcastu The Session, czyli newsy ze świata IT. Prywatnie mąż i ojciec dwójki dzieci. Moim i Waszym gościem jest Grzegorz Kotfis. Cześć Grzesiek! Bardzo mi miło, że wystąpisz w podcaście, że zgodziłeś się przyjąć zaproszenie do tego podcastu.

Grzegorz: Cześć Krzysztof! Dziękuję bardzo za zaproszenie i przy okazji witam wszystkich słuchaczy podcastu Porozmawiajmy o IT.

Krzysztof: Ja zawsze rozpoczynam od takiego wprowadzającego i trochę rozluźniającego pytania, Grzegorz, czy słuchasz podcastów? Jeśli tak, to jakich najczęściej?

Grzegorz: Tak, słucham. Swojego przede wszystkim, który tworzę, żeby wyszedł jak najlepiej, ale tak poza tym, to programistycznych, tych związanych z branżą w której siedzę. Z polskich, mogę wymieniać, reklamować przy okazji? Nie będziesz tutaj miał za złe nic?

Krzysztof: Nie, nie. Oczywiście jak najbardziej.

Grzegorz: Ok. Chyba dla mnie taki top jeden, jeśli chodzi o polskie IT, to jest Ostra Piła. Nie wiem czemu, ale mówi do mnie ten podcast, jest taki naprawdę fajnie prowadzony. Taka troszkę inna konwencja, niż na zasadzie takich pytań – odpowiedzi – pytań. Fajnie chłopaki to prowadzą. Devtalk Maćka i z polskich odkryłem niedawno Beyond the code, fajny podcast, z Gdańska chłopaki, z firmy Sipstech, prowadzą krótkie takie trochę opowiadające o różnych rzeczach niekoniecznie wewnątrz firmowych. Takich w około IT. To są jakieś takie polskie, które śledzę i Porozmawiajmy o IT oczywiście. Jeszcze z zagranicznych, Complete Developer Podcast, trochę Dot Net Rocks, związany z Dot Netem, bo w Dot Necie siedzę, aczkolwiek Dot Net Rocks trochę już mnie nudzi, bo to jest nic innego, jak każdy odcinek trochę opowiada może o jakimś innym produkcie, niekoniecznie jako takich problemach, ale ten styl amerykański, trochę tak do mnie trafia, niekoniecznie może te reklamy, które tam są, ale da się to słuchać jeszcze. Z poza programistycznych, ich trochę będzie, bo ja wszedłem w te podcasty niedawno, więc zabiorę ci tu trochę czasu. Beyond the grid, jestem fanem moto sportów, szczególnie Formuły 1 i to jest oficjalny podcast Formuły 1, który niedawno zaczął się ukazywać. To jest na zasadzie takich reportaży z kierowcami obecnymi, przeszłymi, osobami, które pracują w Formule 1 i ostatnio słuchałem wywiadu z Louisem Hamiltonem i ten podcast odmienił to, w jaki sposób patrzę na tego człowieka, bo tam osoba prowadząca, nie pamiętam jak on się nazywa, umie tak się wgryźć w to trochę te prywatne rzeczy, tak podpytać i dużo rzeczy ciekawych się dowiedziałem o Lousie. Media go troszkę inaczej pokazywały, więc fajny podcast Beyond the grid. Jest też odcinek z Robertem Kubicą, dla tych którzy śledzą go gdzieś tam i się zastanawiają, czy będzie w końcu jeździł czy nie. Trochę takich do nauki angielskiego, BBC szczególnie 6 minutes i lubię od czasu do czasu posłuchać reportaży Polskiego Radia, to nie są podcasty tak jak teraz nagrywamy, tylko to są właśnie takie typowe reportaże, które puszczane są w radio, ale potem lądują w RSS i można ich posłuchać. Ja lubię tak posłuchać, co tam u innych ludzi, jak tam życie się toczy. One są fajnie zrobione te polskie reportaże i fajna szkoła. Może kiedyś taki poziom osiągnę. Chciałbym coś takiego osiągnąć, żeby tak umieć przeprowadzać z ludźmi takie wywiady. A jak chcę się rozluźnić, już mam dość tego technicznego gadania, to Pogaducha, ale przeważnie Przerywnik, bardzo luźne. Wiesz, trochę jestem już znudzony, albo może za dużo miałem już takich podcastów tych coachujących, „Spójrz w siebie w głąb. Pracuje nad sobą”, te biznesowe, marketingowe, ja już się tym przejadłem. Odpuściłem to na chwilę obecną, bo nie byłam w stanie ich więcej konsumować. Więc tak to wygląda u mnie na chwilę obecną.

Krzysztof: Fajna lista, postaram się to wszystko zalinkować gdzieś tam w notatkach. Ja myślę sobie, jeżeli pokażesz komuś książki, które czytasz, to ktoś może o tobie sporo się dowiedzieć, tak samo właśnie z podcastów. To, co słuchasz to są rzeczy, które cię interesują, także sposób być może tak jak powiedziałeś w jakiś sposób się odpoczywa, więc powiem tak, przez tą listę słuchacze dowiedzieli się o tobie, o twoich zainteresowaniach itd. Dzięki.

Grzegorz: Jeszcze nie wszystkiego, ale trochę już ujawniłem o sobie.

Krzysztof: Fajnie. Super. Mam nadzieję, że wyciągniemy trochę więcej w trakcie rozmowy. Grzesiek, dzisiaj porozmawiamy sobie o wpadkach w IT, czyli różnego typu fakapach i chciałabym tu rozpocząć od pytania następującego: na świecie działa taka inicjatywa, która nazywa się Fuckup Nights i to jest seria takich spotkań, które również mają jakieś swoje lokalne powiedzmy wersje. Idea polega na tym, aby otwarcie i bez skrępowania mówić o właśnie wpadkach, fakapach, jednocześnie czerpiąc naukę w myśl powiedzenia, że najlepiej uczyć się na cudzych błędach. Czy według ciebie powinno się mówić o wpadkach w IT? A jeśli tak, to w jakim celu?

Grzegorz: Odpowiedź jest prosta. Tak, powinniśmy mówić o wpadkach w IT i ja się cieszę, że o nich słyszymy, bo tak jak w pytaniu zadałeś, uczymy się na cudzych błędach najczęściej i to jest fajne, że my możemy czerpać z czyjegoś doświadczenia, a cel, przede wszystkim zapobieganie, żeby w przyszłości coś takiego nie miało miejsca, nie powtórzyło się, aby zmniejszać potencjalne straty z takiej wpadki. Bo umówmy się, że taka wpadka, to jest najczęściej strata finansowa, duża, mała, mniejsza, różne są kalibry, to są nawet miliardy dolarów w niektórych przypadkach, dla kogoś, kto prowadzi mniejszy biznes, to może być, być albo nie być, bo taka duża firma nawet jak zaliczy wpadkę, to najczęściej trochę traci PR, może marketing, gdzieś tam akcje lecą w dół, ale niekoniecznie kończy się takim, że ona jest zmieciona z rynku. A taki mały gracz jak zaliczy taką wpadkę, to jest dla niego czasem być albo nie być, więc tak, cieszę się, że ten Fuckup Nights jest. Raz byłem na edycji tutaj w Gdańsku i to naprawdę były ciekawe przypadki, one może niekoniecznie zawsze są związane z IT, ale gdzieś tam wokoło tego programowania miały miejsce. Takie też ze startupem, jedną słyszałem ciekawą wpadkę. Można by dużo mówić. Także tak, mówmy o wpadkach, uczmy się, wyciągajmy z tego wnioski, aby w przyszłości ich nie powtórzyć, takich wpadek.

Krzysztof: Tak, bardzo mądre zadanie. Ja myślę sobie, że trzeba mieć też sporo odwagi, żeby na takim spotkaniu wystąpić, żeby często przyznać się do swoich błędów, także na pewno chylę czoła przed ludźmi, którzy się tego podejmują. Ok. Z tego co wiem, nie ma jakichś badań naukowych prowadzonych w kontekście podziału czy jakiejś kategoryzacji fakapów w IT, dlatego taki najprostszych, który przyszedł mi do głowy, to podział na te software’owe i hardware’owe. Czy według ciebie wyczerpuje to już wszystkie możliwości, czy może są jakieś inne?

Grzegorz: Zdecydowanie nie. My najczęściej słyszymy o tych software’owych, pewnie zaraz do nich przejdziemy jakie to są i hardware’owych, jakiś sprzęt po prostu padnie, albo jest źle zaprojektowany. Dodałbym tutaj takie wpadki z zakresu zarządzania projektem. Po prostu coś nie wypaliło, bo projekt był źle zarządzany. Źle była dobrana metodologia zarządzania takim projektem albo architekci przestrzelili technologię, może wybrali zbyt nową , niesprawdzoną na rynku, w wersji beta np. w startupach można sobie troszkę wybierać, to co jest świeże, mamy Greenfield i możemy trochę popłynąć na czymś, więc tutaj bym dodał jeszcze właśnie tych kilka rodzai. Ale trzeba pamiętać, że nad tym wszystkim, czy to software czy hardware, metodologia, technologia, zarządzanie i tak za tym stoimy my, programiści, inżynierowie projektanci.

Krzysztof: Oczywiście, że tak. Myślę, że o tym sobie jeszcze powiemy później. Ok, to może pociągnijmy tą gałąź softwarową, ponieważ ona wydaje się najbardziej taka jaskrawa i najczęściej wychodzi na wierzch. Jak według ciebie dług technologiczny wpływa na potencjalne problemy w przyszłości?
Grzegorz: Na pewno jest większa. To nie ma wątpliwości, że dług technologiczny zwiększa szansę na potencjalne problemy. Jeszcze się nie spotkałem, żeby je zmniejszał, chyba, że robimy taki projekt, który piszesz na raz, wypuszczasz i zapominasz. Nie ma utrzymania. To wtedy może się nie musisz tym przejmować, że narobisz sobie długu, bo to za tydzień nie będzie już nikomu potrzebne. Myślę sobie tutaj jeszcze o tych technologiach, które wybieramy do projektu, a które się deaktualizują i z czasem możemy mieć problem taki, że dany framework, biblioteka przestaje być utrzymywana, nie są udostępniane potencjalne jakieś poprawki bezpieczeństwa, natrafiamy na jakiś problem i wtedy okazuje się, że trzeba nagle po kilku dobrych latach wymieniać coś, co jest takim naszym corem w systemie lub, co gorsza nie mamy ludzi, którzy będą chcieli z tym pracować. Ja obecnie pracuję w projekcie, w którym mamy webforcy jeszcze, projekt  letni, tam jest mix technologii i jest problem ewidentnie. W ogóle, kto nowy wchodzi na rynek, nie uczy się webforców, więc wiesz, jak szukamy ludzi, to też trzeba po prostu takich, którzy mają doświadczenie, którzy gdzieś tam słyszeli o tym, więc tak, taka zdeaktualizowana technologia może być problemem dla nas w przyszłości. Nie wiadomo kto będzie chciał to utrzymywać. I jak tam jeszcze z tym długiem? Na pewno spowalnia rozwój projektu, to zdecydowanie, a to z kolei ma przełożenie na biznes. Wolno rozwijamy projekt, babrzemy się w tym kodzie, babrzemy się w tych jakichś błędach, zaszłościach, ciągniemy to za sobą, to to się przekłada na biznes. Nie dowozimy na czas, są straty z tego powodu finansowe, a dzisiaj chcemy dostarczać szybko nowe funkcjonalności, chcemy być konkurencyjni na rynku, ale nie jesteśmy w stanie. Tak, dług technologiczny to jest coś, z czym powinniśmy walczyć i to może być dla nas dużym problemem. Dodałbym tu jeszcze, jeśli jeszcze mogę coś dołożyć, że z tym długiem to jest tak, że to jest rzecz trochę trudno mierzalna. Ja nie spotkałam jeszcze jakichś takich estymacji. Używamy sonara, mam styczność z sonarem i on na zasadzie takiej statycznej analizy kodu, daje pewne estymacje, że dołożyłeś jeden dzień do projektu, może dwa dni dołożyłeś swoimi błędami, ale to jest na zasadzie tylko analizy kodu, on nic nie wie o funkcjonalności, on nic nie wie o zależnościach, on nic nie wie, że np. webforcy są już dawno w plecy i nie ma kto tego utrzymywać, więc mamy pewne estymacje, ale to takie mówię bardziej chyba na zasadzie analizy kodu.

Krzysztof: Myślę, że bardzo ważną rzecz poruszyłeś właśnie na końcu. Ja mam osobiście taki problem z długiem technologicznym, że troszkę nie lubię takiego generalizowania, ponieważ oczywiście można powiedzieć, że dług technologiczny zawsze jest zły, ale tylko mam wrażenie, jeśli rozpatrujemy go w kontekście takim akademickim czy takim teoretycznym, że powiedzmy faktycznie wpływa nam negatywnie na różne czynniki związane z projektem, technologią, ludźmi, ale często jest tak, że po prostu nie opłaca się go niwelować, jest ten aspekt biznesowy, ten aspekt ekonomiczny, który jest pewnym przeciwwskazaniem do tego, żeby zawsze ten dług technologiczny niwelować. Wydaje mi się, że dopiero pełny taki obraz projektu, tej części, tej odnogi technologicznej i tej biznesowej może nam powiedzieć, czy w danej sytuacji konkretnej, ten dług technologiczny jest zły czy nie. Czasem, oczywiście rzadziej, bywa tak, że jest on dobry, że godzimy się ponieważ nie ma oczywistych korzyści wynikających z próby jego zniwelowania, więc mam taki troszeczkę ambiwalentny stosunek do długu technologicznego.

Grzegorz: Tak, można powiedzieć, że jak zawsze trzeba wyważyć. Czy jesteśmy w stanie to zaakceptować i to dla nas nie jest ból? Niestety czasem jest tak, że my to akceptujemy, bo patrzymy na chwilę obecną. Dobra, to nie jest dla nas teraz problem, ale nie patrzymy w przód, miesiąc, rok, co będzie potem. Odkładamy na później te problemy.

Krzysztof: Ok, Grzegorz, w formule swego podcastu The Session o newsach z świata IT, zawarłeś taką część poświęconą na wpadki ostatniego tygodnia. Czy zauważasz jakąś prawidłowość? Czy jakiś rodzaj wpadek występuje najczęściej według ciebie?

Grzegorz: Tak, najczęściej możemy spotkać wpadki związane z bezpieczeństwem. Ich jest najwięcej. Może dlatego, że są najważniejsze. A wśród nich, chyba najczęściej, to niestety przechowywanie haseł czystym tekstem, tzw. plain text. To jest zmora. To jest zmora i nawet duże firmy, duże portale, serwisy, z tym się borykają. To wychodzi na światło dzienne po jakimś czasie, bo dzisiaj w Internecie wszystko szybko się dzieje i to nie jest tak, że jesteśmy w stanie to ukryć. Najczęściej te wpadki są odkrywane przez osoby zewnętrzne, które penetrują system, które próbują się do niego włamać i wtedy dowiadujemy się, że takie firmy bodajże chyba T Mobile, nie wiem czy Git Hub też przez chwilę nie miał takiej wpadki, mają hasła w plain tekście, oczywiście tłumacząc to, że to jest taki system drugorzędny, backupowy, gdzie tylko admin ma dostęp i on tam sobie coś na tym sprawdza, więc tak, takie z bezpieczeństwem najczęściej występują. Sisco miał taką wpadkę, ona się powtarzała, ale to wynika z dojrzałości tej firmy, zaraz to wytłumaczę, że w swoim oprogramowaniu mieli zaszyte hasło admina. To miało im pomóc w dostawaniu się gdzieś tam do pewnych funkcjonalności w systemie, a wyszło to przy okazji audytu, który firma przeprowadza. Wzięli po prostu, nie wiem czy zewnętrzną firmę czy kogoś z zewnątrz, ale przeprowadzają audyt całego swojego oprogramowania, czyli też świadczy o pewnej dojrzałości, że my się odkrywamy sprawdźcie nas jak to jest i tam wyszły takie rzeczy właśnie. Firefox też miał problem z hasłem, przechowywali master password, on był zaszyfrowany, ale był w SH1 chyba, czyli już bardzo nieaktualnym i dawno potencjalnie do złamania, czyli już złamanym algorytmie szyfrowania, więc jak widzisz, to głównie bezpieczeństwo. No i też jak spojrzymy na OWASP, czyli taką stronę, która bada bezpieczeństwo, OWASP to jest portal, w top ten, to są głównie błędy bezpieczeństwa. Aczkolwiek od czasu do czasu można się natknąć na takie śmieszne wpadki, jak literówka w pliku konfiguracyjnym gry Cywilizacja VI, i tam chodziło o słówko yelt, ono było źle napisane, była literówka, która to słowo odpowiadało za zachowanie sztucznej inteligencji i ono było naprawdę dziwne, gracze to zauważyli. Ono też jest udokumentowane, są artykuły na temat tej wpadki, więc nie zawsze to są wpadki bezpieczeństwa, ale powodujące np. dziwne zachowania sztucznej inteligencji w grach.

Krzysztof: Ciekawy przykład. Ja w 7 odcinku swojego podcastu rozmawiałem właśnie z ekspertem do spraw bezpieczeństwa i tak naprawdę uderzyło mnie jak dużo jeszcze potrzeba nie tylko takiej wiedzy czy świadomości dla użytkowników systemów informatycznych, ale również dla twórców, programistów, bo często my jako programiści nie myślimy nad bezpieczeństwem naszych rozwiązań, jeśli nie ma tego jakoś odgórnie narzucone w wymaganiach projektu, to raczej gdzieś tam po prostu spychamy, to na ostatni gdzieś tam krok działań, często do tego nie dochodzi, więc wydaje mi się, że trzeba troszkę świadomości jeszcze.

Grzegorz: Dużo świadomości, tak i w bezpieczeństwie, jak i mam wrażenie, że w testach. Najczęściej bierzemy programistę, żeby zrobił nam funkcjonalność, ale zaniedbujemy trochę przetestowanie jej dobrze i ogarnięcie funkcjonalności, więc to kuleje.

Krzysztof: Tak, zgadza się. Pociągnijmy troszkę ten temat. Według mnie, szeroko rozumiana wpadka w IT, właśnie może być wykorzystana tak jak tutaj mówiliśmy do ataku, do kradzieży danych i takich innych powiedzmy działań przestępczych. Czy powinno się zatem szeroko mówić o znalezionych błędach w kodzie? To przecież daje potencjalnym przestępcom nowe możliwości, jeśli wiedzą jaka jest luka, mogą ją wykorzystać do swoich celów, czy zatem powinno się o tym szeroko mówić?

Grzegorz: Tak, przestępcy wykorzystają tą lukę , o ile nikt się nią nie zajmie, ale tak jak już wspomniałem na początku powinniśmy o tym mówić, a jeśli ktoś będzie to ukrywał, to prędzej czy później to wyjdzie na jaw. Szczególnie w przypadku dużych graczy, Cisco, Git Hub, czy Microsoft, Netflix, Google, to są firmy z których usług korzysta wiele ludzi na całym świecie, to nie jest jakiś Januszeks, który robi software dla 10 osób i nikt tam nie będzie penetrował systemu, nikt tam nie będzie go próbował zhakować. Podoba mi się to, że właśnie te duże firmy, jak np. Sisco, przeprowadzają audyt, w którym dowiadujemy się o potencjalnych problemach, jakie wykryli, o błędach. Fajnie, że są też te programy Bagunte, Google ma i Netflix, i płacą za to kasę, czyli płacą nam za znajdowanie luk. To jest po prostu takie można powiedzieć pełne otwarcie. Macie tu nasze API, macie nasze systemy, nasze aplikacje, rozwalajcie je, róbcie z nimi wszystko, co możliwe i my wam jeszcze zapłacimy kasę, jeśli znajdziecie błąd, udokumentujecie to, czyli taka można powiedzieć pełna transparentność. A z tymi lukami, że ktoś może je użyć, tak może, ale z drugiej strony nie powinny być chowane, użyje, jeśli ktoś po prostu nie załata tego systemu. Są takie luki zero-day, które rzeczywiście dowiadujemy się o nich dopiero w dniu, kiedy zostały wykryte i firmie czy komuś może zająć kilka dni załatanie tej luki i to są najbardziej groźne, takie dziury w systemie, ale z drugiej strony to, że widzimy, że firma się wypowiada, mamy problem, mamy błąd, był wyciek, to wiem, że firma coś z tym problemem robi. Właśnie z tym T-Mobilem i z tym hasłem ten problem, tam chyba chodziło o to, że ktoś się zapytał na infolinii T-Mobile, jakiś problem miał z hasłem i konsultant mu pierwsze 4 znaki tego hasła podał i zaczęła się cała afera, poszło na Twitterze, Reddiciei tam w ogóle w innych newsach, w portalach informacyjnych i to wymusiło też niejako na tej firmie podjęcie stosownych kroków. Teraz sobie wyobraź, gdybyśmy o tym nie wiedzieli, gdyby to było w ogóle chowane i tylko przestępcy by wiedzieli o tych lukach, byłoby chyba nie wesoło, więc tak, jest to wiele lepsze niż taka cisza i brak komunikatów.

Krzysztof: Oczywiście, że tak, Tak jak wiem, wpadki i błędy się przydarzają. Powiedziałabym, że błędy są wręcz integralną częścią wytwarzania oprogramowania. Czy jest jakaś odpowiedzialność, jakieś konsekwencje, czy są wyciągane w stosunku do np. programistów, czyli tak naprawdę osób, które przyczyniają się do powstawania tego typu wpadek, błędów i innych fakapów?

Grzegorz: Wiesz, co wiedząc, że zaprosiłeś mnie do tego odcinka o takich wpadkach, zapytałem mojego pracodawcę, a jak to jest u nas, to mówi: „Wiesz, u nas to jest tak, że mamy prawo, prawo pracy, jakieś tam prawo cywilne i nie masz takiego zapisu w umowie.”, czyli ja nie mam, fajnie, jestem chroniony. Ale nie spotkałem się u nas w kraju, żeby był taki przypadek, że programista był pociągnięty do odpowiedzialności, żeby jakaś sprawa karna się toczyła. Oczywiście musimy wziąć na bok tych wszystkich hakerów, którzy robią to świadomie, oni popełniają przestępstwo specjalnie gdzieś tam psują nam system itd., czyli jest ten zamiar, zły zamiar, a my z reguły działamy w dobrej wierze, chcemy wytworzyć oprogramowanie, jak najlepsze, mam taką nadzieję, a przy okazji mamy jakieś potknięcie i rzadko się słyszy, żeby któryś programista za przeproszeniem beknął za to. Najczęściej idzie to gdzieś na szczebel wyżej, jakiś managment czy kierownictwo, które odpowiada za cały projekt, Jest coś takiego, jak dodatkowe ubezpieczenie, odpowiedzialność finansowa. Wiem, że w Wielkiej Brytanii, każdy kontraktor, powinien posiadać ubezpieczenie z tytułu prowadzenia działalności gospodarczej, bez tego po prostu ani rusz. W Polsce, w niektórych zawodach też tak jest. Moja żona jest fizjoterapeutką i ona musi mieć takie ubezpieczenie odpowiedzialność cywilna w pracy, bo jakby komuś przez przypadek rączkę mu złamała, to byłoby nie fajnie i wtedy z takiego ubezpieczenia to schodzi. Znam przypadek, że w Wielkiej Brytanii, ktoś pracując z systemem uruchomił tam źle jakiegoś crona i 150 funtów poszło z takiego ubezpieczenia, czyli widzisz, że zrobiłeś pomyłkę, do ubezpieczalni i po prostu stamtąd ci to ściągną. Prawdopodobnie jakby ta osoba nie miała ubezpieczenia, to pewnie by poszło z jej pensji. Ostatni przypadek, który był taki głośny do Volkswagen i Diesel Gate, czyli cała ta afera emisji spalin. Prześledziłem dokładne losy osób odpowiedzialnych za to, bo tam było po prostu jawne oszustwo w liczeniu tych spalin, więc musiało być jawnie źle napisane oprogramowanie, które wyliczało ten pomiar tych emisji spalin, więc ktoś musiał dać zielone światło na takie coś i z tego co wiem, tam żaden programista chyba nie był pociągnięty do odpowiedzialności, ale za to polecieli kierownicy działów RND, Research and Development, czyli szefowie badań i rozwoju. Zawieszono jakieś osoby bezpośrednio sprawujące kontrolę nad nimi. Czyli jakby tak to wszystko podsumowując, nie spotkałem się z odpowiedzialnością bezpośrednio do której programista byłby pociągnięty, bardziej na szczeblu takiego managmentu, osób odpowiedzialnych za zespoły zarządzania.

Krzysztof: Fajny pro tips z tym ubezpieczeniem. Faktycznie ja też widzę w swoim otoczeniu, że co raz więcej takich firm małych, jednoosobowych, kontraktorów właśnie zabezpiecza się w ten sposób.

Grzegorz: Myślę, że tak. Myślę, że to jest dobra opcja, o której każdy kontraktor powinien myśleć, bo osoby pracujące na etatach, one są chronione przez prawo pracy, więc tam jest troszkę inaczej to rozgrywane.

Krzysztof: Dokładnie. Poza tym myślę, że co raz częściej jest tak, że to nie jest tak, że programista tworzy kod i to bezpośrednio leci na produkcję, tak kiedyś było, ale już mam nadzieję, że odeszliśmy daleko od takiego sposobu dostarczania oprogramowania. Są testerzy i jest jakiś tam powiedzmy proces deploymentu tego wszystkiego, więc jest szansa, żeby potencjalne błędy wychwycić, a poza tym wydaje mi się, że wzrosła troszeczkę świadomość i tak jak mówiłem, te błędy są traktowane jako taka integralna część całości, że to jest coś, co się po prostu w mniejszym albo większym stopniu musi wydarzyć. To nie jest niczyja wina albo takie intencjonalne działanie. Ok, porozmawiajmy chwilę o wpadkach biznesowych w IT. Czy według ciebie, do takich wpadek może należeć uzależnienie się od jednego dostawcy usług, bo właśnie bywa nie raz tak, że powiedzmy software house mają jednego wielkiego klienta, czy nawet tacy drobni kontraktowy świadczą usługi tylko dla jednego pracodawcy, jednej firmy? Czy według ciebie takie uzależnianie się może być potencjalnie niebezpieczne?

Grzegorz: Z punktu widzenia biznesowego, jakbym był kontraktorem i rzeczywiście pracował dla jednej firmy, to chyba trochę słabo. Wolałbym to zdywersyfikować. Myślę tutaj, duży software house, jeden projekt, też słabo, bo jak coś zawalą itd. Jeszcze do tego przyjdzie im płacić karę, to może być nie wesoło. Myśląc o tym uzależnieniu się od jednego dostawcy usług, trochę na myśl przychodzi mi tu chmura, gdzie bardzo jest to popularny temat i uzależnienie się od jednego dostawcy usług w chmurze, jaki to może mieć potencjalny problem, a i tak już jeden się zdarzył. Z AWS-em mieliśmy taką sporą wpadkę w zeszłym roku, więc kto tylko używał AWS, miał przez kilka godzin problem z dostępnością usług. Tam był potężny przestój na całym świecie, więc tak, jeśli mógłbym tutaj powiedzieć coś więcej i doradzić, to wszystko oczywiście zależy, ale dywersyfikacja wskazana. Tak samo przy wyborze dostawców na sprzęt, na jakieś podzespoły, to też jest opcja, żeby nie sprowadzać np., nie wiem strzelam, jednego rodzaju baterii od jednego producenta, bo jak ona nie wypali i będą się nam paliły telefony, to troszkę słabo. Samsung miał taką wpadkę, chyba z  którymś modelem Note’a, paliły się baterie. Na szczęście to był jakiś tam jeden dostawca, problem od jednego dostawcy, ale jakby nagle wszystkie baterie sprowadzali od tego dostawcy i tak wszystkie byłyby wadliwe, to już by było bardzo nie fajnie.

Krzysztof: Zgadza się. Czyli staropolskie powiedzenie, żeby nie trzymać wszystkich jajek w jednym koszyku sprawdza się też w IT. Tak, jak wiemy projekty upadają. Projekty w IT upadają dość często. Niekiedy słyszy się, że przyczyną tego upadku, może być to, że na siłę próbowano zastosować podejście agile;owe, albo próbowano skopiować rozwiązanie, które działa u kogoś innego. Czy według ciebie jest to tylko i wyłącznie domena startup’ów, czy też zdarza się większym graczom?

Grzegorz: Weszliśmy na mój najmniej ulubiony temat, czyli agile i zarządzanie. Ja chyba nie jestem agile. Sam nie wiem do końca, co to jest agile. Ja znam takie wiesz książkowe stosowanie agile, gdzie mam ten manifest itd. A jeśli chodzi o te startupy, ostatnio słyszałem dlaczego tak dużo startupów upada, bo właśnie mają problem z tym zarządzaniem, z tym podejściem do projektu. To są ludzie, którzy mają  bardzo fajny czasem pomysł, naprawdę, na nową technologię. Ja jakbym coś wymyślił, miałbym na to pomysł taki technologiczny, biznesowo bym w ogóle tego nie dźwignął, ani w podejściu zarządzania, więc jakbym na siłę próbował skopiować czyjś sposób zarządzania, jak ten projekt rozwijać, to prawdopodobnie właśnie bym zaliczył wpadkę. Tu jeszcze mi na myśl przychodzą tacy certyfikowani konsultanci agile, którzy czasem wpadają do firm i robią szkolenie: „Słuchajcie, to jest agile, tutaj macie Kanban, to działa tak i tak, i to jest w sumie sprawdzone i musicie to używać.” Nie, to nie do końca tak działa. Oczywiście trzeba się zapoznać z tym agilem, wziąć pewnego jego składniki, ale przede wszystkim dostosować i to ludzie przede wszystkim muszą być agile. Nie firma, tylko to ludzie stanowią ten trzon projektu i to oni muszą stosować, umieć pracować, nauczyć się tego podejścia. Jeśli mógłbym tak jakoś to ująć, ale mówię to nie jest moja domena i jak myślę, słyszę o zarządzaniu, o tych miękkich takich, o tych PMowych rzeczach to troszkę mi skóra cierpnie. Za dużo w back endzie siedzę. Zasiedziałem się w back endzie.

Krzysztof: Pewnie. Myślę, że tak. Święte słowa, to ludzie powinni właśnie stosować podejście agile czy być agile, a nie tylko dużo firmy. Ok, Grzegorz, widzimy często, że awansując z dobrego programisty na menedżera, często tracimy dobrego programistę, a zyskujemy słabego menadżera. Czy wpadki w IT również dotyczą tej działki HR-owej i zarządzania zespołem?

Grzegorz: Myślę, że tak. Troszkę się to zmienia, jeśli chodzi o działy HR, te które nie tylko odpowiadają za rekrutację, ale zaczęły odpowiadać za poprowadzenie tego programisty, za jego rozwój, za  pokierowanie nim. To wynikało trochę do tej pory z tego, że był taki brak pomysłu, czyli przychodził programista do firmy, mieliśmy takie sztampowe podejście można powiedzieć, zaczynasz od juniora, potem jesteś takim średniakiem – middle i kończysz, albo i nie, jesteś seniorem, i co my mamy dalej z tobą zrobić, bo w sumie ty szybko dochrapałeś się tego seniora, to może wciśniemy cię na takiego project managera i teraz taki dobry, techniczny programista, nagle ma zarządzać ludźmi. Nie zawsze się ktoś go pyta, czy on chce to robić, bo po prostu nie ma nikogo innego, ty masz największą wiedzę techniczną, domenową, to będziesz umiał jakoś te taski rozdzielać, tworzyć issue, gadać może z biznesem, konsultantami i okazuje się, że klapa, bo w ogóle nie jest ta osoba przygotowana, nie do końca może ona chciała ta robić, może motywacją był tylko awans finansowy dla niej, sobie pomyślała „Dobra, jakoś to będzie, jakoś to dźwignę” i to tak chyba trochę właśnie wynika z takiego typowego podejścia, ale jak  wspomniałem, to się zmienia, świadomość programistów się zmienia, że jest coś jeszcze poza tym, że są takie role jak lider techniczny, nie musi być takim tym liderem, który jest właśnie od tych miękkich zadań, rozliczania czasu pracy, tworzenia tych issue, przepisywania, tylko może być liderem technicznym, wyznaczać kierunku rozwoju, architektury, sprawdzać  ten sług technologiczny w projekcie, zapobiegać. Także mamy fajne inne role. Przychodzi mi tu na myśl właśnie niedawno wydana książka Maćka „Programista i co dalej?”, więc właśnie, i co dalej? Więc to nie tylko właśnie ten manager, tylko jeszcze jest coś poza tym i takie trochę podejście, zmiana pracy w pracy, czyli zostajemy w tej samej pracy, ale możemy pełnić tam różne role, niekoniecznie role słabego managera.

Krzysztof: Tak, czyli taki bardziej awans wertykalny.

Grzegorz: Dokładnie.

Krzysztof: Myślę sobie, że tak jak powiedziałeś, ta świadomość rośnie, a poza tym ta branża IT, zwłaszcza w Polsce, jest bardzo młoda, to jest raptem 20 ostatnich lat i troszeczkę jest brak pewnie takiej kadry, która gdzieś mogłaby funkcjonować, więc z braku laku, że tak powiem, awansuje się ludzi, którzy są najbliżej technologii.

Grzegorz: Tak i jedyne co mi przychodzi jeszcze do głowy, że taka kadra może już jest, nazwijmy starsze pokolenie IT, ale ono jest  obecnie prawdopodobnie tylko na uczelniach. A to jest całkiem inna bajka. Wydaje mi się, że to pokolenie takich lat 80, to będzie takie pierwsze pokolenie, osób urodzonych gdzieś tam w pierwszych latach lat 80, to będzie takie pierwsze, które będzie doświadczało tych takich właśnie trochę innych odpowiedzialności, że jeszcze jest coś innego niż tylko ten managment projektu, który czasem jest tak na siłę wciskany, bo boimy się wziąć kogoś z zewnątrz. Wiesz, to jest takie naturalne, ty tu pracujesz 5-10 lat, to się sprawdzisz najlepiej. Nie koniecznie. Może czasem warto zaryzykować i wziąć kogoś z zewnątrz, kto jest tylko dobrym menadżerem, nie pracował dotąd w naszej firmie, ale on się wdroży, on wie jak pokierować ludźmi.

Krzysztof: Myślę sobie, że zwłaszcza programiści, lubią komplikować sobie projekty stosując różne frameworki, czy właściwie mnóstwo framworków, bibliotek lub np. po powrocie z konferencji aplikują tak trochę bezmyślnie zasłyszane tam modne wzorce czy rozwiązania. Czy taki over engineering według ciebie, to proszenie się o problemy?

Grzegorz: Pewnie. My lubimy to przecież. My uwielbiamy te nasze repozytoria z tymi paczkami. Lubimy je zaciągać. Ale jeszcze o tych konferencjach, bo to jest też taki bardzo ważny temat. Co mogę doradzić? Jak jedziesz na konferencje i cały dzień tam słyszysz o tych nowych fajnych rzeczach i sobie już w głowie wyobrażasz, och jak ja zastosuję tą bibliotekę, jak zastosuje to podejście, przecież to rozwiąże wszystkie moje problemy, projekt ruszy z kopyta, to tutaj zalecam spokój, spokój i jeszcze raz spokój. Wróć do domu, zgłąb temat, poszukaj plusów i minusów, na szczególnie tych takich produktowych sesjach, nie do końca są pokazane jakieś minusy tej technologii czy tego podejścia, więc poszperaj trochę, poczytaj o tym, daj sobie kilka dni, niech emocje ochłoną i powoli krokami wróć do tego, zobacz, co z tego możesz wycisnąć, ale taki hura optymizm, rzucanie się teraz na tą nową rzecz, którą poznałeś, to nie jest dobre rozwiązanie, bo zamiast ewolucji, wyjdzie ci z tego rewolucja. A to jest raczej niepożądane w projekcie. Będziesz potem gasił pożar. I jeśli chodzi o te paczki, ty Krzysztof siedzisz w Ruby z tego co wiem, macie Gemstora, ja trochę siedzę w back endzie, to mamy Nugety, a w Nodzie mają MPM i repozytorium składające się, nie wiem, tam jest milion modułów, może już dwa miliony, o wiele za dużo według mnie. Frameworki są dobre na wszystko wychodzimy z założenia albo można tak pomyśleć. I nawet na sklejanie stringów bierzemy framerwork, nawet na obcinanie znaków z lewej strony bierzemy paczkę. Po prostu uwielbiamy to, to jest łatwe, a tu sobie dociągnij zależność i to ci rozwiązuje cały problem, nie musisz pisać swojego kodu, bo przecież za ciebie już ktoś to napisał. Ok, to jest fajne, ale zastanów się czy ty ją na pewno potrzebujesz? Choćby dlatego, że bierzesz takie coś, zaciągasz coś z zewnątrz. Przychodzi mi taka analogia do głowy, zapraszasz takiego nieznajomego do siebie do domu, który mówi ci: „Słuchaj, ja w sumie nie jestem szkodliwy, ja robię to i to. Możesz mnie spokojnie wpuścić do swojego domu”, oczywiście dom to jest ten twój projekt informatyczny. Nie sprawdzasz kodu, czyli nie sprawdzasz tej osoby, nie sprawdzasz licencji, co też jest dużym problemem pomijanym. Okazuje się potem, że ta paczka nie do końca robi to, co powinna robić. Mieliśmy już taki przypadek w repozytoriach oficjalnych MPM, że tam były złośliwe paczki. One miały super ładne nazwy, np. Get Cookies, czyli tam do zarządzania ciasteczkami, miał rozwiązywać wszystkie problemy z ciasteczkami, a robiły coś więcej, bo grzebały po prostu po dysku. Tam był po prostu uruchamiany jakiś dodatkowy, z tego co kojarzę, kod binarny, więc tak, te zewnętrzne repozytoria, to jest problem, takiej natury, że tam po prostu trzeba weryfikować. Nie możesz jako programista ufać do końca, że inny programista zrobi coś dla ciebie w dobrej wierze. To może strasznie brzmi, bo ja bardzo lubię naszą społeczność programistyczną i z założenia też wychodzę, że jest fajna, wspaniała, jej ufam, ale niestety jest ta zła strona, więc takie uzależnianie się od zewnętrznych repozytoriów powoduje jaki problem? Że ono na chwilę padnie, ty nie masz swojego lokalnego i nagle się okazuje, że przez, nie wiem, dzień, nie możesz zrobić deploya, bo nie można pobrać paczek z zewnętrznego repozytorium, a to już miało iść i się okazuje, że mamy straty, nie wiem czy finansowe, ale jest obsuwa. Czy naprawdę je potrzebujemy? Czy wiemy, co ściągamy i czy będziemy w stanie tym potem zarządzać, żebyśmy za pół roku byli w stanie wyliczyć, że mam takie i takie zależności, a nie że jest ich tam po prostu tyle, że nie wiem o co chodzi? Apka np webowa staje się ciężka, bo na starcie zaciąga tam 100 różnych modułów.

Krzysztof: Tak, wszyscy tam byliśmy. Drogie dzieci, to były złote rady wujka Grzegorza, słuchajcie doświadczonej osoby. Grzegorz, gdy zdarza się wpadka, tak jak mówiliśmy, firma może o niej powiedzieć, może poklepać się w pierś, może wyciągnąć wnioski lub może zamieść temat pod dywan. Chciałbym wierzyć, że częściej występuje ten pierwszy wariant, a według ciebie, co występuje częściej?

Grzegorz: To zależy. Myślę, że to jest trochę problem dużych firm i małych firm. Może problem dojrzałości tych firm, na ile one są w stanie przyjąć tą wpadkę na klatę, na ile jest w stanie ich dział PR znieść falę hejtu i tego, co się potem wyleje w Internecie, jakby znieść tą burzę. I teraz duzi gracze, oni to dzielą się, to trafia do publiki, nie wiem, czy zawsze trafia to z ich inicjatywy, bo czasem to może być tak, że ktoś napisze gdzieś, słuchajcie wykryłem problem taki i taki, jest straszny fakap, po prostu zobaczcie jak ta firma nas traktuje i dopiero wtedy widzimy reakcję tej firmy, że włącza się do dyskusji, fajnie, jak rzeczywiście włącza się, próbuje to jakoś załatać, bije się w pierś i jest ok. Gorzej jak zaczyna bagatelizować sprawę i nam wkręcać, że to nie jest nic takiego. Tutaj mają do czynienia z osobami przeważnie o, nie chcę nikogo urazić, ale wysokim IQ i nam się nie da tutaj w kaszę dmuchać i ściemniać, bo od razu przecież wyczaimy co jest nie tak. Mogą komuś tam, mówić takiej osobie, nie wiem, mojemu tacie mogą powiedzieć: „Wie pan co, to nie jest taki problem z tym hasłem, bo to przecież nic takiego, my znamy tylko pierwsze cztery litery.”, ok, dobra kupuję to, ale dla osoby technicznej, ona wie, że to jest potencjalny problem, więc to jest jedna jakby istotna rzecz, a z tym zamiataniem pod dywan, myślę, że to jest bardziej domena takich małych graczy, czyli którzy wytwarzają jakieś oprogramowanie, może gdzieś przeznaczone tylko dla wewnętrznych procesów, to nie wychodzi w ogóle na światło dzienne i nigdy nie ujrzy światła dziennego, nie będzie wykorzystywane poza tą firmą, i tam oni mogą sobie to zamiatać pod dywan i się kapią w tym sosie i sobie z tym walczą. A w dobie Internetu, wiemy, że to się i tak potrafi szybko rozprzestrzenić i się nad tym nie da kontrolować, nawet jak usuną te informacje, to zaraz się pojawią w innym miejscu. Nawet teraz przyszło mi teraz do głowy, nie wiem czy słyszałeś, kilka dni temu pojawił się taki wątek pracownika Tesla, któremu skończyła się umowa o poufności trzy letnia i on po prostu wylał do Internetu, oczywiście nie wiem, czy to są potwierdzone informacje, nie mamy potwierdzenia, czy ta osoba rzeczywiście tam pracowała i czy to są prawdziwe informacje, ale on trochę tak powiedział, jak Tesla od środka wygląda. I teraz jestem ciekaw, czy firma Tesla się jakoś do tego ustosunkuje czy właśnie zamiecie pod dywan, w ogóle się nie wypowie w tej sprawie, bo tam dochodziło do strasznych fakapów. Jak opowiadał jak ktoś przez SSH do samochodów się logował, żeby usunąć jakiś plik, bo samochód po prostu tam się resetował czy strasznie wolno ładował ten zbyt duży plik. Wyszło takie januszostwo trochę w Tesli, aczkolwiek zaznaczam, że nie wiem, czy to są już potwierdzone informacje. Zobaczymy.

Krzysztof: Tak jak już wspomniałeś, chmura to temat ostatnio bardzo modny. Na dobre zagościła w IT. Osobiście słyszałem o takich wpadkach związanych z chmurą typu niepoprawność szacowania kosztów. Nie raz jest to bardzo trudne, zwłaszcza dla niedoświadczonej osoby, w momencie, kiedy płaci się za czas procesora, nie ma się wszystkich danych na wejściu, żeby faktycznie ten koszt finalny oszacować. Z drugiej strony, takie bardzo niskie koszty odpalenia serwera dają pole do popisu dla przestępców, którzy mogą, powiedzmy ataki typu DDOS wykonywać. Kojarzysz jeszcze jakieś wpadki czy właśnie problemy związane z chmurą?

Grzegorz: Jeśli chodzi o chmurę, to myślę, że dużym problemem jest tutaj właśnie te koszty, ale w troszkę innym ujęciu. Nie wypowiem się co do oszacowywania kosztów, bo ja nie miałem z tym doświadczenia. Bardziej wierzę, że nie wiem czy któreś firmy rzeczywiście przestrzeliły, bo z założenia właśnie chmura miała rozwiązywać ten problem tych kosztów i one mogą się pojawić w takich okresach, nie wiem, prowadzisz usługę, jakiś sklep i przychodzą święta i masz duży plik klientów i tam dołączają ci się nowe instancje i przez to możesz dźwignąć tych wszystkich klientów i rzeczywiście tam mogą być większe koszty, ale z drugiej strony miała trochę rozwiązywać ten problem tych kosztów, ale nie chcę wchodzić głębiej, bo to nie moja domena. Jeżeli chodzi o punkt programistyczny tego twojego pytania, to wykradanie haseł i kluczy jest tutaj problemem. Nawet na Git Hubie czy innych publicznych repozytoriach, podejrzewam, że znajdziesz bardzo wiele, zawsze w tych plikach konfiguracyjnych, w kodzie aplikacji, kluczy do usług i teraz jeśli tak osoba o niecnych zamiarach sobie weźmie ten token, użyje, to nagle ci zczyści konto i to jest problem. Jest taki przykład, to był artykuł, gość chyba stracił 14 tysięcy dolarów. Wydaje mi się, że udało mu się to jakoś wyprostować, to był w Amazonie, właśnie przez to, że tych danych dostępowych do chmury nie wyrzucił z kodu źródłowego, który był gdzieś tam publicznie dostępny, więc tutaj bym uczulał, jeśli chodzi o chmurę na takie rzeczy, a jeśli chodzi o tego DDOS’a, to powiem ci nie wiem, nie mam pojęcia czy tutaj ten problem tak występuje, czy można sobie tak DDOS’ować tak sobie łatwo usługę. Pewnie można, nie wiem, czy gdzieś tam Asure przed tym nie zabezpiecza, czy AWS, czy Google, Code Platform, przed tymi DDOS’ami , bo to jest bardzo przecież taki powszechny problem, DDOS’owanie usług.

Krzysztof: Nie poruszyliśmy jeszcze tematu fakapów hardwarowych. Mam wrażenie, że one zdarzają się rzadziej niż te inne typy, o których wcześniej mówiliśmy, ale chyba są dotkliwsze finansowo powiedzmy dla producentów. Przykładowo wymiana klawiatur, dysków, monitorów, innych podzespołów w tysiącach sprzedanych sztuk, to nie lada problem, prawda?

Grzegorz: Wiesz co, a nie wiem. A spotkałeś się kiedyś, żeby z powodu wadliwej myszki firma organizowała akcję serwisową? Chyba nie.

Krzysztof: Myszki może nie, ale Applowe rzeczy nie raz tak są wymieniane.

Grzegorz: Tak, bo gdzieś tam jakiś inżynier trochę nie sprawdził może jakiego rodzaju plastiku użył, czy tam otoczki na kable i to się zaczęło wszystko rozwalać po pół roku. Ale ja myślę, że to jest pestka. Ok, jest to jakiś cios dla firmy i PRowy i na chwilę się użytkownicy obrażą, ale jeśli chodzi o Apple, to pewnie tam jest, no wiesz, trochę taki kult, więc ok wybaczymy. A tak trochę pół żartem, pół serio teraz mówię. Większy problem tu jest, jeśli chodzi o systemy krytyczny, czyli takie, którego awaria lub nieprawidłowe działanie może skutkować śmiercią lub poważnymi obrażeniami ciała człowieka, czy uszkodzeniem sprzętu, czy środowiska. Czyli wyobraź sobie, że mamy jakiś hardware sterujący, nie wiem, w mieście co tam mamy, sygnalizację świetlną, kurcze nie wiem, przepompownie ścieków itd. W Gdańsku mieliśmy wpadkę. Wpadka hardwarowa, siadła pompa i musieli wylewać ścieki do motławy. Nie związane z IT, ale wiesz, to jest wpadka hardwarowa można powiedzieć, siadła pompa i sprowadzali nową czy naprawiali ją kilka kolejnych dni, więc tu też coś nie tak było z zarządzaniem i backupem itd. Ale wracając do tych systemów krytycznych na takie medyczne wszystkie sprzęty, które muszą być niesamowicie przetestowane, tam się w ogóle inaczej podchodzi do pisania kodu, nawet NASA, był taki popularny artykuł, taki Code in cialains  dla systemów pisanych w NASA, czyli co używać, czego nie używać. To jest całkiem inny kod, niż ten taki biznesowy, który my prawdopodobnie piszemy na co dzień do Apek Webowych, jakichś użytkowych, do gier, bo tam wchodzi w grę już dbanie o dobro człowieka, to może się coś bezpośrednio z nim stać. Była taka wpadka. I miliony dolarów. Była taka wpadka, chyba jedna z najbardziej odczuwalnych, jeśli chodzi o życie ludzkie, z systemem Terach. Terach to był, jeśli dobrze teraz pamiętam sprzęt, który wykonywał albo rentgeny, albo zdjęcia rentgenowskie, naświetlał po prostu jakoś tam ludzi i to był problem takie, że 6 osób, 6 chyba poniosło śmierć w wyniku tego sprzętu, a problemem był źle napisany kod. Typowe copy paste. Jeśli się okazało, że to jeden programista nad tym pracował chyba, wziął trochę z poprzednich wersji, trochę z wersji 10 tego produktu, trochę wersji 20. W wyniku audytu wyszło, że kod jest nietestowalny, słabo był testowalny i taki niestety sprzęt ujrzał światło dzienne i 6 osób poniosło śmierć.  Więc tak, to tak hardware, trochę hardcorowo teraz wszedłem w ten hardware. Widzisz na poziomie takim medycznym, czy  sterowanie elektrownią atomową. To są większe problemy myślę, niż te tutaj klawiatury, dyski i monitory, które najwyżej popłaczesz trochę nad tym jak ci się kabelek urwie czy tam jakaś plamka na matrycy wyskoczy na monitorze.

Krzysztof: I często tak jak powiedziałeś, te problemy hardwarowe, to tak naprawdę wynikają właśnie z softwaru, który na nim działa. Przyszło mi do głowy, tylko nie pamiętam już, czy to był Księżyc, czy to był Mars, ale wiem, że lądowanie jakiegoś właśnie statku badawczego zupełnie się nie powiodło, bo programista pomylił mile z kilometrami np. prawda.

Grzegorz: Tak i była jeszcze jedna wpadka związana z programem kosmicznym. Była taka sonda, która miała lecieć na Wenus. To było dawno temu, nie wiem, czy nie w latach 90, i ona zaraz po starcie zaczęła krótko mówiąc świrować, jeden z silników chyba zaczął tam coś źle działać. Problemem był hajfen, czyli myślnik, jeśli dobrze tłumaczę. Problemem był myślnik, zły myślnik w kodzie. Możliwe, że dochodziło do złych obliczeń, które sterowały ciągiem czy dostarczaniem paliwa do tego silnika, i ona zaraz po starcie po prostu rozsypała się w drobny mak, doszło do wybuchu. Taka wpadka też była na pewno bardzo kosztowna. Oj, myślę, że bardzo, bo jednak takie przygotowanie, taki program kosmiczny, to są niewyobrażalne kwoty. Jeden myślnik po prostu tyle kasy zaprzepaścił.

Krzysztof: No cóż. Grzegorz, a jakie są twoim zdaniem takie top 5 wpadek w IT, o których słyszałeś?

Grzegorz: Prócz tych, które wymieniłem, ten Terach czy ten program kosmiczny. Wiesz co? Powiem tak, wspomnę o tych, z którymi sam miałem styczność. Których sam byłem świadkiem. Kojarzysz pewnie tzw. pluskwę milenijną, czyli słynny rok 2000, kiedy to na kilka miesięcy przed, wybuchła panika, bo nagle wszyscy sobie uzmysłowili: „Hej my tylko interpretujemy rok tylko po dwóch ostatnich jego cyfrach, czyli 91, 95, 97, a tu nagle dostajemy 00. I zaczęła się panika, zaczęły się audyty oprogramowania na całym świecie, a co się stanie z serwerami, jak to wszystko będzie funkcjonować, a oprogramowanie w szpitalach, a oprogramowanie na giełdach. Suma sumarum, nic poważnego się nie wydarzyło, ale całe te przygotowania, całe to ogarnięcie tej paniki, tych audytów i sprawdzenia tych systemów, przetestowania, pochłonęło chyba 300, teraz nie pamiętam milionów czy bilionów dolarów, bardzo dużą sumę. Niewyobrażalnie dużą dla nas, więc tak, pluskwa milenijna to było coś takiego bardzo ciekawego można powiedzieć, co też wszystkie stacje telewizyjne mówiły o tym, co teraz z tym naszym softwarem będzie. Czy kurcze piekarniki nie przestaną nam działać, bo koniec świata wisi w powietrzu. To taka pierwsza. Druga, Flashplayer jako jeden z najgorszych softów jakikolwiek ujrzał światło dzienne, najbardziej badziewne coś, co wrzuciliśmy do przeglądarki. Spojrzałem w raporcie, jest taki raport na stronie CIV, który odnotowuje w oprogramowaniu ilość dziur. Tam jest taka skala od 0 do 9, jeśli chodzi o krytyczność i ile na przestrzeni czasów było tego typu dziur. Wyobraź sobie, że Flashplayer jest rekordzistą. W całym cyklu życia jego, odnotowano 887 dziur na poziomie 9+, czyli takich najbardziej krytycznych. Także cieszę się, że już tego nie ma z nami i nie mamy już Flashplayera i, że przeglądarki po prostu nie wspierają tego, bo to było po prostu coś strasznego. Nie było tygodnia, żeby nie było informacji, że coś jest we Flashplayeru i trzeba to łatać. Trzecia, MPM, czyli te, w skrócie MPMy, zdalne repozytoria, ale tu nie wpadka dla tych repozytoriów, które ktoś to wymyślił itd., tylko dla developerów. Daje tutaj minusa developerom, którzy korzystają z tego, tak sobie czerpią jak z takiego woreczka. Wyjmują, wyjmują, bierzemy i to jest fajne. A! I jeszcze jedna przyszła mi do głowy, Polski system do głosowania, nie pamiętam jak ten program się nazywał, trochę mi przykro, że był napisany w Dot Net, ale jako Dot Netowiec, to było straszne. Jak się po prostu dobrali do tego kodu i zobaczyli co tam działa, to jest wpadka, nie wieszał bym tutaj psów na programiście, który to pisał, pewnie działali pod presją czasu, za niską kasę, ale, że ktoś wyżej to zlecał, nie czuwał nad tym. No caman?! Na pewno mamy dobrych programistów, dobre firmy, dobre zespoły, trafiło to do jakiegoś janusza. To była tragedia. Tak samo jak tragedią trochę jest informatyzacja ZUS. W tym nie siedzę, ale jak widzę w obecnych latach, że ZUS zleca przetarg i oni chcą mieć dyskietki, które już dawno nie są używane, to sobie myślę „Ej, hello?! Gdzie wy w ogóle jesteście?! Co tam się dzieje?”. Także to takie rzeczy które przychodzą mi na myśl. Nie tykam tych takich za granicą, gdzie gdzieś tam coś się wydarzyło, że jakieś serwery komuś padły na dzień. Właśnie w AWS’ie tak jak było. To też była duża wpadka. Taka spora. Taka giełdowa kiedyś była wpadka. Firma straciła bardzo dużo kasy, to było podczas debagowania. Trochę się rozgadałem. Mogę jeszcze kontynuować, bo tak mi tu idzie?

Krzysztof: Jasne, pewnie śmiało.

Grzegorz: Była taka wpadka z firmą Night, nie wiem jak się nazywa, nie będę teraz googlował. Night coś tam. Programista, oni mieli jakiś tam algorytm tradingowy i tam po prostu był problem z konfiguracją, oni zaczęli pisać nowe oprogramowanie, ale to nowe oprogramowanie korzystało ze starych ustawień i teraz jak to poszło na produkcję, ktoś przestawił jedno ustawienie i okazało się, że na powiedzmy 8 serwerach był nowa wersja oprogramowania i to działało ok, a na jednym serwerze zostało stare oprogramowanie i to samo ustawienie, ale przełączone, spowodowało, że on zaczął mówiąc kolokwialnie świrować. I w bardzo krótkim czasie, chyba w 45 minut, wygenerował bardzo dużo zleceń na giełdzie, i jak to na giełdzie, zaczęły się dziwne roszady dziać, firma straciła bardzo dużo kasy, chyba ponad 450 milionów dolarów i jeszcze sprzątanie po tym, jej akcje poleciały, jeszcze sprzątanie po tym wzięło kolejne miliony dolarów, to była taka pamiętam spora wpadka giełdowa. Takie moje top 5, może nie top 5, bo mówię, tego można wymieniać dużo.

Krzysztof: Sporo tego, Powiedzieliśmy o różnych wpadkach w IT i teraz będzie pytanie z gatunku jak żyć. Czy da się tym wpadkom jakoś zaradzić według ciebie?

Grzegorz: Nie da się. Nie będę ukrywał, że wszystkiego nie jesteśmy w stanie załatać, nie jesteśmy w stanie wszystkiego wykryć, mówi się, że nie ma idealnego oprogramowania, jest tylko źle przetestowane i myślę, że tak długo jak to ludzie, podkreślam to słowo ludzie, będą wytwarzać oprogramowanie, sprzęt, to będą się te wpadki pojawiały. Albo inaczej, one też będą wychodziły może na światło dzienne, bo one już są. Intel, Spectre Meltdown, coś co istnieje od wielu lat, ale dopiero teraz się o tym dowiedzieliśmy. Dopiero teraz naukowcy zaczęli to badać i te podatności ujrzały światło dzienne, co gorsza, dwa dni temu przeczytałem, że tego się nie da załatać. Prawdopodobnie potrzebna jest nowa generacja procesorów, żeby całkowicie usunąć wszystkie podatności Te typu Spectre i Meltdown. Nie jesteśmy w stanie tego wszystkiego wyrzucić z oprogramowania. My też nie znamy tej drugiej strony, czyli tych osób o niecnych zamiarach. Po prostu ta ich wyobraźnia nie ma granic i oni często będą doszukiwać, będą takie tworzyć use casy, o których nam się nie śniło w najczarniejszych przypadkach, scenariuszach testowych.

Krzysztof: Dokładnie, Czyli wiemy już, że rozwój technologiczny przyspiesza. Wiemy już, że nie da się wpadkom w IT zaradzić. Czy znaczy to, że tych wpadek będzie co raz więcej, a może tak jak mówiłeś, będą jakieś nowe typy, nowe rodzaje?

Grzegorz: Myślę, że będzie ich, nie wiem czy więcej, bo nikt tego chyba nie liczy, nie robi żadnych takich statystyk, ale myślę, że będą się pojawiały nowe. Na pewno zostaną te z obszaru security. Tom Owas prowadzi taki ranking i jedyna chyba taka najbardziej znacząca wpadka, czyli Cross Site Request Forgery , czyli coś co było przez wiele lat na pierwszym miejscu, czy w pierwszej trójce, spadło na odległe miejsca, bo frameworki z których korzystamy nam w tym pomogły. Nie musieliśmy my sami trochę nad tym trochę czuwać, tylko już ktoś, czy tam w Dot Net Core’ze czy w jakichś bibliotekach pomogli nam z tym walczyć. Mówiąc o nowych obszarach, mam na myśli IOT, czyli wszystkie te małe urządzonka, które mają w sobie wbudowaną komunikację. To jest coś nowego. Nie do końca zbadanego pod kątem bezpieczeństwa, nie wiemy czego się tu spodziewać, kiedy tak naprawdę to się jeszcze bardziej rozchula. Już teraz jest dużo sprzętów. Tak naprawdę, kurcze, patrząc u mnie w domu, telewizor podłączony do Internetu, sprzęt audio, wiele urządzeń, zegarki, może taki na rękę, ale zaraz będzie ten ścienny coś tam będzie brał z Internetu. Ciekaw jestem, jakiego rodzaju tutaj ataków czy też wpadek możemy się spodziewać. Podobnie rzecz ma się z chmurą, która nie jest na chwilę obecną, nie można powiedzieć, że jest to młody produkt, bo przecież co raz bardziej, jest już dawno na salonach. Firmy teraz intensywnie się migrują i myślę, że tam takich speców od bezpieczeństwa w chmurze nie tylko tych takich, którzy pomogą w migracji, wskażą te kierunku, składniki z których należy skorzystać, jakie to są benefity z tej chmury, ale takich inżynierów bezpieczeństwa tam będziemy potrzebować. Lecąc dalej, pojazdy autonomiczne. To jest duży problem, nie pod kątem technologicznym, ale też takim etycznym. Tam jest autonomia, tam jest sztuczna inteligencja. Jak zapanować nad rozwojem AI? W Stanach tam się tworzą takie, nie wiem jak to nazwać, ale takie grupy, czy takie firmy przystępują do jednego projektu, żeby czuwać nad tym rozwojem AI. Mieliśmy kilka chyba już takich chyba już crashy, że jakiś samochód coś tam się rozwalił, taki chyba był popularny przypadek. Z kolei ten AI, to będą takie wpadki też na poziomie trochę etycznym. Takim, że oprócz uszkodzeń, że do niej w ogóle doszło jak rozwiązać ten problem odpowiedzialności za to. Takie rzeczy mam na myśli. Jeszcze bym tutaj wspomniał o nas programistach, bo to my nad tym czuwamy, więc ja się cieszę, że trochę nasze narzędzia programistyczne się rozwijają. Mamy oprócz takich statycznych analizatorów kodu, które powiedzą nam „o, tu jest taki błąd, mogłeś skrócić trochę ifa, może za długa metoda”, to wszystko rzutuje, żeby takiej wpadki było mniej, żeby kod był bardziej testowalny, ale myślę o tym rozwoju AI i czy w przyszłości nie doczekamy czegoś takiego, że „słuchaj ty tutaj napisałeś taką, tak obrazuję, metodę, która, ja już ją widziałem wcześniej i to doprowadziło do wpadki, albo ten rodzaj podejścia jest obarczony ryzykiem, czyli programista pisząc będzie miał takie wsparcie, jakieś takie bardziej inteligentne, zapewnione ze strony sztucznej inteligencji.

Krzysztof: Tak przyszłość jeszcze na pewno nie raz nas zaskoczy. A właśnie a propos przyszłości, czy planujesz kontynuację swojej serii o wpadkach w swoim podcaście
The Session i skąd ty czerpiesz informację o tych nowych fakapach w IT?

Grzegorz: Chciałby, to kontynuować, bo całe to The Session i te newsy ciepło się przyjęły. Nie ukrywam, że to mi zabiera sporo czasu, którego mam bardzo mało, bo praca na etacie, rodzina, nie sprzyja trochę temu, ale chciałbym to kontynuować, bo wydaje mi się, że ważne jest to, tak jak wielokrotnie już wspomniałem w tym podcaście dzisiaj. Ważne jest to, żebyśmy o tym mówili. A jeśli chodzi o czerpanie informacji skąd ja to biorę, przeglądając po prostu prasę, Read It, Twitter, Haker News, Google Alerts, bardzo pomocne. Można ustawić sobie alerty na określone frazy. Bardzo doceniam tutaj też pracę naszych rodzimych portali, taki jak Niebezpiecznik i Securac, które one tak trochę tym ludziom mniej technicznym mówią o wpadkach i potencjalnych zagrożeniach, czyli zabezpieczają, Mogę powiedzieć: „Ojciec, słuchaj, weź sobie to przejrzyj, zobacz to, to jest tak dla ciebie napisane jak się zabezpieczyć przed czymś”, bo to jest spory problem, więc też śledzę te takie od strony mniej technicznej, właśnie jak ten Niebezpiecznik czy Securac. CV Details, stronka, gdzie są odnotowane wszystkie podatności. Tak jak wspomniałem, najczęściej to użytkownicy w Internecie, gdzie na Twitterze czy na Read It, Haker News, po prostu informują też o takich rzeczach, więc wystarczy po prostu przeglądać tego typu rzeczy. To nie są żadne wiesz takie dark netowe portale, ja w tym nie siedzę. Także wszystko dostępne.

Krzysztof: Ok zrobiłem sobie listę. Wyczerpałem swoje pytania na dzisiaj. Wierzę, że nasza rozmowa nie będzie wpadką, bo temat myślę oryginalny, sporo przykładów z życia, mam nadzieję, że się będzie dobrze słuchało. Jeszcze raz ci bardzo dziękuję, a teraz proszę zareklamuj się trochę i powiedz, gdzie cię można znaleźć w Internecie?

Grzegorz: A więc tak, słuchaliście Grzegorza Kotfisa w podcaście Porozmawiajmy o IT, odcinek o wpadkach. Możecie mnie śledzić przede wszystkim na stronie Thesession.pl, na Twitterze pod nickiem gkotfis, w podcaście The Session, a myślę, że już niedługo również osobiście będziecie mogli mnie spotkać na różnego rodzaju wydarzeniach IT w Polsce. Chciałbym trochę wystartować z takim projektem robienia krótkich reportaży, recenzji, pojawiając się na jakichś wydarzeniach przeprowadzać wywiady z uczestnikami. Takie relacje z wydarzeń, ale w postaci podcastów, więc nie wykluczone, że będzie można ze mną przybić piątkę osobiście w różnych miejscach Polski. Zobaczymy jak to wyjdzie.

Krzysztof: Zapraszamy. Trzymam kciuki za twoje inicjatywy. Jeszcze raz bardzo ci dziękuję i do usłyszenia. Cześć!

Grzegorz: Dzięki Krzysztof. Do usłyszenia. Hej!

Krzysztof: I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Tak jak rozmawialiśmy z Grzegorzem, błędów IT nie da się uniknąć. Trzeba jednak o nich mówić, aby nie tylko wyjść z twarzą, ale i by unikać podobnych wpadek w przyszłości. Przypominam Ci o konferencji Data Workshop, organizowanej 13.10.2018 roku w Warszawie przez Vladimira Alekseichenko, który mówił o sztucznej inteligencji w 17 odcinku podcastu. Do 29.10.2018 roku obowiązuje 20% rabat na kurs Vladimira na promocode PorozmawiajmyoIT. Bardzo Ci dziękuję za wysłuchanie. Dziękuję za kolejne oceny i recenzje w iTunes. Pozwolę sobie przeczytać tą ostatnią, recenzję napisał wujas LM, a brzmi tak: „Słucham z przyjemnością i polecam. Dobry dobór tematów i gości. Tak trzymać.” Dzięki wielkie. Jeżeli masz jakieś pytania, komentarze, propozycje, co do kolejnych odcinków, a może czujesz się na siłach, żeby wystąpić w jednym z kolejnych odcinków, zapraszam do kontaktu ze mną pod adresem krzysztof@porozmawiajmyoit.pl. Ten podcast otrzymałeś ode mnie bezpłatnie, ale nie jest on tak do końca darmowy, poproszę Cię o polubienie Fanpage na Facebooku lub gwiazdki i recenzje na iTunes, Spriker, SoundCloud.lub innej aplikacji z której korzystasz do słuchania podcastów. Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o wpadkach, błędach i fakapach w IT. Zapraszam na kolejne odcinki. Cześć!