To jest 107. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o kierunkach rozwoju w software developmencie. Przypominam, że w poprzednim odcinku rozmawiałem user experience w IT. 

Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/107. 

Ocena lub recenzja podcastu w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut. 

Sponsorem dzisiejszego odcinka jest platforma rekrutacyjna SOLID.Jobs. Jeśli szukasz pracy w IT, koniecznie odwiedź adres https://solid.jobs/

Znajdziesz tam tylko oferty pracy z widełkami wynagrodzeń. 

Jeśli aktualnie nie myślisz o znalezieniu nowej pracy, to koniecznie zapisz się na jobalert. Nie częściej niż raz w tygodniu otrzymasz wiadomość e-mail z zestawieniem ofert, które mogą cię zainteresować. SOLID. Jobs to więcej niż job board – na stronie znajdziesz nie tylko oferty pracy, ale również poszerzysz swoje kompetencje. Odwiedź zakładkę „prasówka”, czyli agregator polskich blogów i podcastów, gdzie z jednego miejsca dotrzesz do solidnej dawki informacji i newsów ze świata IT i nie tylko.

Jeśli w swojej pracy nadal korzystasz z SVN-a, to koniecznie odwiedź SOLID. Jobs.

 

Partnerem odcinka jest firma cyber_Folks, oferująca szybki i bezpieczny hosting, jak również domeny oraz certyfikaty SSL.

cyber_Folks podobnie jak ja uwielbia dzielić się wiedzą. Warto odwiedzić ich blog, uczestniczyć w organizowanych webinarach czy skorzystać z narzędzia do szybkiego audytu strony. Sprawdź oferty na cyberfolks.pl

 

Nazywam się Krzysztof Kempiński a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego jest między innymi ten m.in. podcast. 

Zostając patronem na platformie Patronite możesz mi w tym pomóc już dziś. Wejdź na porozmawiajmyoit.pl/wspieram i sprawdź szczegóły! 

Jednocześnie z tego miejsca bardzo dziękuję moim obecnym patronom. 

Teraz życzę Ci już miłego słuchania! 

Odpalamy! 

 

Cześć! Mój dzisiejszy gość to CEO Altkom Software & Consulting wykładowca akademicki na Politechnice Warszawskiej, programista Javy i pierwszy w Polsce certyfikowany trener Javy. 

Do 2006 roku zajmował stanowisko dyrektora w dziale Enterprise Risk Services Deloitte, odpowiadał za projekty realizowane dla sektora bankowego. Od marca 2006 roku nieprzerwanie na czele software house’u Altkom Software & Consulting , najpierw w roli dyrektora operacyjnego, obecnie prezesa zarządu. 

Od 2019 zarządza również spółką Altkom Experts, zajmującą się outsourcingiem specjalistów i zespołów IT. 

Moim i Waszym gościem jest dzisiaj Adam Lejman. 

Cześć, Adam! Bardzo mi miło gościć cię w podcaście. 

 

Cześć, Krzysztof! Jest mi również niezmiernie miło, że możemy dziś porozmawiać. 

 

Mój plan na tę rozmowę to wyciągnąć z Adama jego doświadczenie w branży i porozmawiać o kierunkach rozwoju software developmentu, także cieszę się niezmiernie! 

Zapytam standardowo: czy słuchasz podcastów, jeśli tak, to może masz swoje ulubione audycje?

 

Oczywiście, słucham – uważam, że podcasty to znakomita forma rozwoju i dowiedzenia się co się dzieje na rynku, przy czym ostatnio tak właśnie stwierdziłem, że chyba najwięcej słucham podcastów związanych z zarządzaniem i ciekawymi osobami, które osiągnęły coś w biznesie, więc takie moje ulubione podcasty z ostatnich miesięcy to na pewno podcast Macieja Witkowskiego Zaprojektuj swoje życie czy też dużo słuchałem Mariusz Chrapko Menedżer Plus, ale również te podcasty stricte IT. 

Twój podcast jest jednym z moich ulubionych, także polecam wszystkim do słuchania, szczególnie w czasach dojeżdżania do pracy czy długich podróży. Znakomita forma, żeby się rozwijać. 

 

Super. Dzięki wielkie za polecenie! 

Tak jak mówiłem na początku, masz ponad 25 komercyjnego doświadczenia w tworzeniu oprogramowania dla małych, dla dużych firm. Może nawet częściej dla tych większych przedsiębiorstw. Czy według ciebie patrząc z perspektywy tego czasu jest sens mówienia o kierunkach rozwoju software developmentu? Czy w tak szybko rozwijającej się, prężnej branży silenie się na jakieś predykcje co do przyszłości ma w ogóle sens? 

 

Z jednej strony branża się rozwija, a z drugiej strony mam takie poczucie, że potrzeba tworzenia programowania od zawsze była i dając się perspektywie, na którą mamy wpływ, ona zawsze będzie. 

Chyba mniej więcej 20 lat temu jeden z szefów IT dużego telekoma powiedział mi „Adam, kończy się software na zamówienie, powinniście zmienić profil na firmę wdrożeniową”. Odpowiedziałem: „Moim zdaniem zawsze będzie potrzeba budowania zindywidualizowanych rozwiązań” i z perspektywy czasu widać, że ta potrzeba jest i ona nie zanika, wręcz rośnie, więc oczywiście moim zdaniem cały czas software house’y mają rację bytu na rynku i patrząc na to ile software house’ów mamy w Polsce, to idzie już prawie w kilkaset podmiotów, które dzisiaj aktywnie działają na rynku polskim. 

Z drugiej strony moim zdaniem nie ma sensu silić się na jakieś długoterminowe przewidywania, w jakich kierunkach to się będzie rozwijało, bo mam takie wrażenie, że rynek polski mimo tego, że bardzo jest na bieżąco z narzędziami, które są stosowane, to jednak z perspektywy polskich klientów obserwuję, że pewne trendy, które gdzieś się wydarzają na zachodzie, do nas trafiają z pewnym opóźnieniem. Wystarczy śledzić to, co się dzieje na rynkach dojrzalszych, bardziej rozwiniętych, chętnie adaptujących nowe rozwiązania i do nas, do Polski to w ciągu 2-3 lat przyjdzie. 

Trochę zgodnie z powiedzeniem, że przyszłość już się wydarzyła, tylko jest nierównomiernie rozdystrybuowana. Wystarczy patrzeć gdzie ta przyszłość jest dalej w stosunku do naszego regionu i wystarczy patrzeć, co tam się dzieje, jakie frameworki, jakie narzędzia, jakie architektury, jakie paradygmaty są stosowane i pod to się przygotowywać. Wtedy na pewno będziemy w stanie skutecznie oferować naszym klientom to, czego oczekują. 

 

Trochę zgodnie z powiedzeniem, że przyszłość już się wydarzyła, tylko jest nierównomiernie rozdystrybuowana. Wystarczy patrzeć gdzie ta przyszłość jest dalej w stosunku do naszego regionu i wystarczy patrzeć, co tam się dzieje, jakie frameworki, jakie narzędzia, jakie architektury, jakie paradygmaty są stosowane i pod to się przygotowywać. 

 

Okej, to zanim zaczniemy rozmawiać o przyszłości, o tym, co może za chwilę do nas zapuka, to zastanówmy się chwilkę nad tym, gdzie obecnie jesteśmy. Chciałbym wyjść od takiego pytania związanego z rozwiązaniami korporacyjnymi, właściwie z architekturami tych rozwiązań. Bo z jednej strony tak jak obserwuję sobie zwłaszcza to, co się dzieje w takim trochę posta pandemicznym świecie, to taka tendencja do bycia agile, bycia zwinnym, ale z drugiej strony jednak ta druga strona mocno stoi w chęci stabilności, jeśli chodzi o korporacje. 

Teraz przyjrzyjmy się tym architekturom wykorzystywanym w tych rozwiązaniach. Czy one są w Twojej opinii mocno stabilne i trochę z tyłu, za szybkim postępem? W którym kierunku się rozwijają? Z jakimi problemami obecnie te architektury się w ogóle mierzą?

 

Myślę, że to bardzo różni się od rynku, z jakim się pracuje. My akurat pracujemy w dużej mierze z sektorem finansowym, który z jednej strony jest dosyć aktywny, jeżeli chodzi o adopcję nowych rozwiązań, ale ponieważ tu są żywe korporacje, to te nowinki trochę dłużej się przebijają w szczególności do tych dużych rozwiązań – mają trochę dłuższą drogę. 

To, co na pewno dzisiaj wyraźnie szykuje się jako taki trend uwzględnienia w architekturach w dużych przedsiębiorstwach, to jest kilka paradygmatów, które należy uwzględnić. Z jednej strony robiąc rozwiązania dla dużych korporacji zawsze to rozwiązanie jest elementem jakiegoś większego ekosystemu.

Nie mam na myśli ekosystemu danego przedsiębiorstwa, gdzie często mamy do czynienia z potrzebą integracji z kilkunastoma czy wręcz kilkudziesięcioma różnymi systemami, ale to jest też kwestia, że duże przedsiębiorstwa coraz bardziej chcą i muszą się otwierać na swoich partnerów, dostawców, klientów z perspektywy właśnie różnego rodzaju API do podmiotów zewnętrznych. 

Czyli tak naprawdę produkując architekturę dla korporacji musimy uwzględnić również otoczenie tej korporacji. To znaczy – w jaki sposób dana firma wystawi interfejsy do swoich systemów, do partnerów. Czy mówimy o takich aspektach jak standard P2 w bankowości, dla płatności, czy mówimy o agregatorach ubezpieczeń, gdzie każde towarzystwo ubezpieczeniowe musi wystawić jakieś API do tego, żeby można było czytać ich produkty, cenić i w jakiś sposób to porównywać. 

To jest na pewno taki ważny aspekt do uwzględnienia. Innym dosyć istotnym trendem, który od paru lat się zaznacza to jest kwestia dużych systemów korporacyjnych, które z jednej strony są drogie do wdrożenia i czasochłonne, a z drugiej strony wymagają też ciągłej aktualizacji. 

My nazywamy to wewnętrznie pojęciem decaplingu starych systemów, to znaczy, że bardzo trudno jest korporacji wymienić system centralny, core’owy, taki główny jednorazowo i właściwie coraz mniej jest takich projektów, że dana firma decyduje się na wymianę swojego rozwiązania. 

Tutaj wchodzi właśnie takie pojęcie rozłożenia głównego systemu na części, to znaczy zastanowienia się, które elementy z dużego systemu można w jakiś sposób zastąpić nowszymi elementami, jak wyciągnąć pewne procesy czy funkcjonalności, które wymagają szybkich aktualizacji na zewnątrz tego core’owego systemu i robić je w innych technologiach, w których możemy tę szybką zmienność zapewnić. 

Cała koncepcja mikro serwisu wchodzi jako pewien element, który pozwala nam takie potrzeby realizować. Kwestia wdrażania różnych frameworków VPN-owych jest elementem, który pozwala takie duże systemy uelastycznić i nadać im nowy czas życia, ale też musimy cały czas pamiętać o tym, że jednym z kluczowych wyzwań w korporacjach, szczególnie jeżeli mamy wiele różnych systemów o różnym stanie życia, zbudowanych w różnych technologiach, to zapewnienie również ciągłości funkcjonowania procesów jest niezwykle ważne. 

To, co się szczególnie ostatnio wydarzyło w czasach pandemicznych, gdzie wszyscy przeszli do online, to też percepcja użytkowników systemów jest taka, że właściwie każdy system powinien być cały czas dostępny. Teraz, jeżeli mamy podejście sprzed czasów pandemii, gdzie wdrożenie aktualizacji, rozwiązań trwały dwa razy w roku, raz na kwartał się wprowadziło i wtedy takie okna serwisowe wyłączały pewne dostępności, to właśnie dzisiaj jest to nieakceptowalne z perspektywy użytkowników, którzy siedząc z telefonem komórkowym właściwe w każdej chwili chce mieć dostęp do banku czy do informacji o swojej polisie czy swoim procesie, który przetwarzają z daną korporacją, więc zapewnienie ciągłości działania jest kolejnym aspektem, który też musimy uwzględniać i tutaj te wszystkie automatyzacje, które są związane z dostarczaniem poprawek są aspektem do uwzględnienia. 

Tych zagadnień jest cała masa i w zależności do tego, z czym się mierzymy, to tych pomysłów i doświadczeń do wykorzystania jest też bardzo dużo, żeby zapewnić korporacjom dostarczenie wartości dla klientów na koniec dnia. 

 

Tak, to jest na koniec dnia najistotniejsze. Powiedziałeś o mikroserwiach – to jest czy też była poradzenia sobie z  wielkim monolitem z dużym couplingiem i z problemem rozwoju aplikacji, rozwoju oprogramowania na pewnym etapie.

Nie było pewnie w pewnym momencie żadnej konferencji, na której jakiegoś tematu związanego z mikro serwisami by nie było, stał się duży hype na mikroserwisy. Po jakimś czasie jako branża zauważyliśmy też pewne limity czy problemy wynikające ze stosowania mikroserwisów.

Mam wrażenie, że trochę mniej już się mówi o mikro serwisach jako takim złotym leku. Oczywiście tak jak to zawsze w software developmencie – są obszary zastosowania, gdzie mikroserwisy się świetnie sprawdzają, w innych niekoniecznie. Ale chciałbym cię zapytać, czy z tego co obserwujesz rynek, to mikroserwisy ciągle jeszcze są kierunkiem rozwoju, czymś co wyznacza trend, czy te może już okrzepłą technologią?

 

Trochę okrzepłą, w takim znaczeniu, ze się przyzwyczailiśmy, że to jest jedna z podstawowych architektur. Teraz nikt nie emocjonuje się tym, że będzie robił system w oparciu o mikroserwisy, bo to jest taki no-brainer. Po prostu tak się robi. Oczywiście mikroserwisy nie są rozwiązaniem na każde zło i ciągle jeszcze monolity czy takie modularne monolity też są w wielu przypadkach dobrym rozwiązaniem, bo jednak mikroserwisy są obarczone pewnym nakładem dodatkowej pracy czy też złożoności architektonicznej. Nie jest to więc lek na każde zło, aczkolwiek jest to dominujący trend, tym bardziej że biorąc pod uwagę coraz większą adopcję chmury również w Polsce, chociaż Polska jest trochę w tyle w porównaniu do świata zachodniego, ale widać znaczne przyspieszenie w ostatnim czasie.

Ten proces jest naturalnym elementem, który wykorzystuje cały potencjał chmury i tez wydaje mi się, że mając architekturę podzieloną na mikroserwisy dużo łatwiej  jest poszczególnymi obszarami funkcjonalnymi, różnymi technologiami gospodarować. Bo jak możemy te architektury podzielić, no to w tym momencie też wchodzą w miejsca, gdzie nie trzeba budować rozwiązania od zera możliwości, skorzystania z platform low-code jako pewien element rozwiązania funkcjonalnego, czy też właśnie wykorzystywanie rozwiązań czy takich bardziej zaawansowanych typu server-less w jakimś obszarze, także mikroserwisy na pewno otworzyły wiele nowych możliwości, natomiast to nie jest tak, że teraz każdy system musimy zawsze robić mikroserwisów, bo wiadomo, że i nakład na pracę zespołu, zarządzanie zespołem tez jest dużo większy, chociaż ma to mnóstwo zalet, które warto wykorzystywać.

 

Jak obserwuję teraz to co się dzieje na rynku obserwując to, jakie firmy, jacy giganci technologiczni próbują wejść na rynek chmury, to myślę sobie, że chmura obliczeniowa i transformacja cyfrowa to jest coś takiego, co bardzo mocno zmieniło i zmienia software development.

Czy znajomość tych zagadnień związanych z cloud computingiem to jest według ciebie już coś takiego, co każdy programista praktycznie powinien gdzieś w swoim toolboxie mieć? Bo z jednej strony myślimy o chmurze jako o środowisku uruchomieniowym, jako o deploymencie apliakcji, ale jakby spojrzeć od strony architektury, to przecież to, że dana aplikacja będzie w chmurze może mieć wpływ na pewne decyzje architektoniczne, które podejmujemy – schodzimy dosyć blisko kodu.

Jak to więc jest – czy programiści będą ablo muszą obecnie być obeznani w chmurze? Czy to ciągle jest obszar, który jest kolejnym obszarem kierunku DevOpsowym, niekoniecznie programiści muszą sobie zdawać sprawę z tego, w jaki sposób aplikacje będą uruchamiane?

 

Oczywiście jest tak, że u programisty przede wszystkim liczy się umiejętność dobrego programowania i to jest kluczowe, szczególnie gdy mówimy o młodych osobach. Przede wszystkim musi być dobrym programistą – od tego zacznijmy. Natomiast oczywiście bez względu na to jakie umiejętności dana osoba posiada, to jednym z kluczowych aspektów tych umiejętności jest również rozpoznanie środowisk chmurowych i wzięcie pod uwagę tego, że tworzymy rozwiązanie, które będzie oparte o chmurę.

Absolutnie konieczne jest, żeby osoby, zajmujące się projektowaniem czy architekturą miały te kompetencje chmurowe rozwinięte i to jest element, który też widzę na rynku i u nas w firmie, który bardzo dynamicznie podlega rozwojowi, zadaniom edukacyjnym. Zdobywanie certyfikatów providerów chmurowych jest jak najbardziej w cenie i patrząc też na wycenę potem osób na rynku, to sooba, któr aposiada odpowiednie certyfikaty jest rozchwytywana dzisiaj przez rynek, więc absolutnie tak.

Natomiast też istotne jest to, żeby ciągle śledzić jak rozwijają się poszczególne usługi chmurowe, ponieważ to co obserwujemy, to co w środowiskach chmurowych się bardzo szybko zmienia i nawet rozwiązanie zrobione w chmurze rok temu dzisiaj może być bardzo optymalizowane pod kątem tego, jakie nowe usługi w chmurze się pojawiły u danego providera.

Warto nie zatrzymywać się i zdobycie jednego czy drugiego certyfikatu u danego providera nie kończy naszej ścieżki chmurowej, tylko trzeba cały czas to zaktualizować.

Przede wszystkim z perspektywy programisty, taki kierunek, który wydaje się być bardzo obiecującym, też biznesowo, to jest takie podejście server-lessowe, gdzie możemy dosyć łatwo konwertować płacę programisty na wartość biznesową, jaką dostarczamy.

W serverlessie jednak mamy takie podejście, że nie budujemy tego kodu infrastrukturalnego, który jest niezbędny żeby budować funkcję biznesową, bo to nam właśnie dostarcza chmura. W tym momencie możemy się fajnie skupić na budowaniu czystej wartości biznesowej, więc z mojej perspektywy, tak jak patrzę na branże, jak się zmieniała, to o ile kiedyś, lata temu rzeczywiście dosyć łatwo budowało się rozwiązania funkcjonalne dla biznesu i kodu, takiego narzutu na tę całą infrastrukturę nie było tak dużo, potem mieliśmy wyzwania związane z tym, że zanim zaprogramuje się jakaś wartość biznesową trzeba było tworzyć tego kodu infrastrukturalnego strasznie dużo, osadzać to w tych różnych środowiskach, zanim się przysłowiową pierwszą funkcję biznesową zbudowano, no to teraz serverless daje nam znowu taką szansę powrotu do szybkiej konwersji pracy programisty na wartość biznesową.

To jest taki kierunek, który jeszcze nie jest szeroko stosowany szczególnie w dużych korporacjach, o ile łatwiej to w prostszych aplikacjach mobilnych czy webowych stosować, to już zauważamy, że coraz chętniej duże przedsiębiorstwa też patrzą na rozwiązania server-lessowe i to na pewno jest taki kierunek, który zachęcamy wszystkich chcących się rozwijać w obszarze developmentu, żeby uważnie śledzili możliwości tutaj.

 

To jest taki kierunek, który jeszcze nie jest szeroko stosowany szczególnie w dużych korporacjach, o ile łatwiej to w prostszych aplikacjach mobilnych czy webowych stosować, to już zauważamy, że coraz chętniej duże przedsiębiorstwa też patrzą na rozwiązania server-lessowe i to na pewno jest taki kierunek, który zachęcamy wszystkich chcących się rozwijać w obszarze developmentu, żeby uważnie śledzili możliwości tutaj. 

 

Dokładnie tak. Gdzie w tym krajobrazie widzisz DevOps? Metodologię, podejście – zależy jak kto ot definiuje. Z jednej strony można powiedzieć, że nie jest to stricte kierunek rozwoju software developmentu, ale mocno z tym związane jest to podejście.

Czy oceniasz z punktu widzenia kilku lat, kiedy ten ruch nam się rozwija, że faktycznie ta obietnica DevOpsowa połączenia dwóch działów, operacji i developmentu została zrealizowana? Czy to faktycznie jest ulepszenie?

Jestem ciekaw, jaką masz opinię na temat tego podejścia.

 

Z DevOpsem zawsze było trudno, bo to jest połączenie dwóch, osobnych kompetencji, zarówno operacyjnej i developerskiej. Albo ktoś jest developerem i nie bardzo chce tę perspektywę operacyjną brać na siebie, albo ktoś jest operacyjny i nie bardzo chce developerską kwestię brać na siebie. Natomiast dla mnie jest to bardzo kluczowy i krytyczny wręcz aspekt szczególnie budowania aplikacji dla dużych przedsiębiorstw, tutaj w dużej mierze chodzi o to co DevOps nam daje, czyli pełną automatyzację dostarczania kolejnych ewolucji i rozwiązań, które mamy. budowanie właśnie pipeline’u CI/CD, który pozwala nam bardzo szybko dostarczać rozwiązania bez tej potrzeby czekania na kolejne tzw. releasy dużych systemów jest wyzwaniem i jak patrzę z perspektywy naszych klientów, to tutaj szczególnie energia idzie na to, żeby jak najbardziej usprawnić te okresy, kiedy systemy nie ą dostępne i do tego jak najbardziej DevOps jest rozwiązaniem.

Istotne jest też to, żeby te elementy, które są poddawane automatyzacji coraz szerzej czerpały od tych rozwiązań, które nie były budowane w czasach, kiedy podejście DevOps było dostępne, więc tutaj też sztuką jest, żeby odpowiednio interfejsować te rozwiązania starsze, żeby też się mogły do tego pipeline’u CI/CD podłączyć i żebyśmy mogli w sposób ciągły dostarczać poprawki czy nowe rozwiązania funkcjonalne, także tutaj DevOps wydaje się być kluczowy.

 

Powiedziałeś już kilka ciepłych słów o serverless, czyli o takim ciekawym rozwiązaniu, które pozwala myśleć o programowaniu jako takim zestawie małych funkcji, które są uruchamiane w takich sposób bestenowy na serwerze, który jest powoływany do celów wykonania tej funkcji.

Jak to od strony biznesowej z Twojego punktu widzenia? Nie wszystko da się super zrealizować za pomocą podejścia serverless, dla niektórych zastosowań jest to podejście idealne. Czy według ciebie jeszcze mocniej serverless przeniknie to do świadomości zwłaszcza większych, szerszych rozwiązań korporacyjnych?

 

Wydaje mi się, że tak, bo kluczową obietnicą serverlessa jest to – z jednej strony, opór, który zauważamy jest taki, że za każde wywołanie funkcji trzeba płacić, więc to powoduje trochę zniechęcenie, bo nie bardzo wiadomo ile na koniec dnia ktoś będzie płacił za takie rozwiązanie serverlessowe.

Natomiast jeżeli popatrzymy sobie na to z drugiej strony, że im bardziej rośnie nam liczba wywołań serverlessowych, to tym większy mamy ruch transakcyjny, to znaczy, że te wywołania przynoszą bezpośrednie korzyści dla przedsiębiorstwa, w którym te aplikacje mamy.

Tutaj z perspektywy rozwiązań serverlessowych ta nieprzewidywalność pozorna jest na początku, ale potem jak ją zestawimy z tym że każde kolejne wywołanie to są konkretne tzw. monety dla danego przedsiębiorstwa, to one zaczynają się bardzo dobrze opłacać.

Z drugiej strony też to, co widać i co kiedyś było przeszkodą w przypadku serverlessa to dosyć duża latencja, jeżeli chodzi o wywoływanie funkcji. To się znacznie poprawiło w ostatnim czasie, też do serverlessa poza Pythonem, który był popularny zaczynają wchodzić te tradycyjne języki programowania również z dobrą, niską latencją, więc coraz mniej barier pojawia się przed tym serverlessem i dla mnie to jest taki powrót do obietnicy, że bardzo szybko przekładamy efekt pracy programisty na wartość biznesową, ale to trochę jeszcze wymaga mentalnego oswojenia się z nowym modelem rozliczeniowym, a w szczególności w korporacji też trzeba sobie z góry założyć pewne budżety, TSO danych rozwiązań, to pojawia się jako dosyć nowy aspekt równania, który trzeba uwzględniać i jeszcze nie wszyscy do końca wiedzą jak to przewidywać, ale na pewno zachęcam, żeby takie ćwiczenia robić, tym bardziej że jak pokazują różne statystyki innych firm, to rozwiązanie oparte o serverlessa buduje się kilkukrotnie szybciej niż tradycyjne rozwiązanie. Co prawda trzeba mieć do tego odpowiednie kompetencje, ale na koniec dnia ta korzyść zarówno w czasie dostarczenia, jak i potem w koszcie posiadania takiego rozwiązania jest na tyle obiecująca, że warto w tę stronę pójść.

 

Tak jak powiedziałeś – wydaje mi się, że to już nie jest problem technologiczny, tylko raczej mentalny, przekroczenie pewnej bariery. Podobnie jak musieliśmy trochę oddać kontroli wyprowadzając aplikację do chmury, tak samo też musimy teraz trochę tej kontroli oddać, po części technologicznej, może po części finansowej, jeśli chodzi o serverless, ale to, co można uzyskać jest potencjalnie znacznie większe niż ta utrata kontroli, więc też wydaje mi się, że to podejście serverless będzie coraz częściej spotykane.

Pracuję od długiego czasu dla przeróżnych startupów i mam wrażenie, że coraz więcej nas otacza – czy takich projektów green field, gdzie programiści tworzą jakiś software szyty na miarę. Tak do początku do końca, tworzą jakiś produkt, który ma podbić rynek.

Jednak nie można zapomnieć, że obok tych startupów istnieje całe mnóstwo projektów oprogramowania tzw. legacy, które już zostały stworzone jakiś czas temu, które musi być utrzymywane, które też bardzo często musi być rozwijane. Wiem, że powoli taka nisza na rynku powstaje, związana z software house’ami, też się właśnie specjalizują w utrzymywaniu, w rozwoju, w maintenance takich aplikacji typu legacy.

Czy myślisz, że ta niszowa branża będzie się rozwijać, że to będzie jakiś kierunek rozwoju? Będziemy musieli coraz bardziej specjalizować się w utrzymywaniu starszych technologii?

 

Chyba tak. Szczególnie pracując z przedsiębiorstwem, które zainwestowało dużo pieniędzy w rozwiązanie czy też nawet ze startupem, który zbudował już sobie rozwiązanie, no to ono już po pierwszym wdrożeniu staje się rozwiązaniem legacy, które trzeba ciągle usprawniać, prawda?

Tutaj rozumiem, że nawiązujesz do takich rozwiązań, które mają już ładnych kilka lat, często 10-15 lat funkcjonują w danym przedsiębiorstwie i tak jak mówiłem wcześniej, wymiana ich jest absolutnie nieracjonalna albo zarówno z perspektywy finansowej, ale też z takiej, że nikt nie zatrzyma biznesu na dwa lata, żeby wdrożyć nowy system centralny, więc trzeba szukać różnych, innych ścieżek do tego, żeby te systemy uaktualniać jak i dawać możliwość korporacjom dostarczania coraz to nowszych rozwiązań.

Są software house’y, które specjalizują się w utrzymaniu, natomiast utrzymanie nie jest takim fancy zadaniem dla programistów. Każdy woli tworzyć nowy kod, zamiast poprawiać czyjś. Z pomocą przychodzi tutaj ta idea takiego smart decappingu, żeby popatrzeć na takie rozwiązania jako swojego rodzaju wyzwanie inżynierskie – w końcu jesteśmy inżynierami oprogramowania, więc popatrzmy na to jako pewne wyzwanie inżynierskie.

Jak rozłożyć taki stary system na czynniki pierwsze, to zastanowić się co z tego starego systemu warto zachować, co można przepisać lub zastąpić jakimś rozwiązaniem w miarę gotowym czy też dostosowywanym. To są takie bardzo ciekawe projekty, które pozwalają popatrzeć trochę na inżynierów oprogramowania ze strony innej niż tylko tworzenie od białej kartki. W szczególności t potrzeba zbudowania właśnie API do systemów wewnętrznych, partnerskich, budowania różnego rodzaju sound boxów, to z perspektywy startupów wiesz, że wiele przedsiębiorstw udostępnia dostęp do swoich systemów, taki bezpieczny sposób soundboxowy, gdzie można sobie potrenować pewne koncepcje, rozwiązania i potem jak one się sprawdzają, to wchodzić we współpracę z takim przedsiębiorstwem, ale właśnie też tworzenie tych soundboxów jest jakimś tam elementem ciekawych wyzwań dla programistów.

Innym aspektem w pracy nad systemami, które długo mają żyć jest aspekt, żebyśmy tak budowali architekturę i rozwiązania w tym systemie, żeby ten system mógł być utrzymywany przez coraz to nowe osoby. Wiadomo, że kilkunastoletni cykl życia systemu powoduje, że osoby, które pracują nad jego rozwojem też się zmieniają, więc z jednej strony dobrze udokumentowany w kodzie system, z drugiej strony jasna, przejrzysta architektura, z trzeciej – dosyć proste konstrukcje programistyczne, żeby osoba z zewnątrz mogła tę krzywą przemian mieć bardzo krótką są niezwykle ważne, żeby planować i projektować systemy, które mają mieć ten długi czas życia.

 

Wiadomo, że kilkunastoletni cykl życia systemu powoduje, że osoby, które pracują nad jego rozwojem też się zmieniają, więc z jednej strony dobrze udokumentowany w kodzie system, z drugiej strony jasna, przejrzysta architektura, z trzeciej – dosyć proste konstrukcje programistyczne, żeby osoba z zewnątrz mogła tę krzywą przemian mieć bardzo krótką są niezwykle ważne, żeby planować i projektować systemy, które mają mieć ten długi czas życia. 

 

To są aspekty, które warto uwzględniać, co nie zawsze w przypadku robienia rozwiązań dla startupów muszą być lekkie, często to są MVP, które muszą co chwilę pilotować w różne strony. Nie zawsze się to bierze pod uwagę, natomiast jak podchodzimy do współpracy z korporacjami, to trzeba ten aspekt długoterminowości życia danego systemu uwzględnić i to jest dosyć ważne wyzwanie.

 

Dokładnie – to jest inny zestaw problemów niż w takich projektach tworzonych zupełnie od zera. Jestem czasem zdania, żeby taki dobry software engineer powinien przepracować kilka lat w jednym projekcie legacy, bo wtedy spotyka się z takimi wyzwaniami trochę wydajnościowymi, trochę związanymi z refaktoringiem, których pewnie nie miałby okazji gdzieś tam spotkać rozpoczynając co pół roku nowy projekt.

To jest jakaś tam szkoła życia mimo wszystko!

 

Dokładnie. To jest coś, co my też przechodziliśmy parokrotnie, szczególnie osoby, które zaczynają pracę w systemach korporacyjnych, na początku często nie zdają sobie sprawy, że ten system będzie żył, że oni z tego systemu po jakimś czasie wyjdą, przyjdą nowi koledzy i oni muszą zmierzyć się z tym, co w tym kodzie zastają.

Często osoby, które chciały się wykazać i zrobiły dziwne konstrukcje, bardzo efektywne, tylko że mało zrozumiałe dla osoby nowo wchodzącej, potem się okazało, że musieliśmy strasznie upraszczać te systemy, żeby one były bardziej zrozumiałe, że takie ściganie się kto zrobi ciekawszą konstrukcję na koniec dnia okazywało się strasznym problemem w utrzymaniu, więc też tego trzeba się nauczyć, żeby tworzyć kod prosto, przejrzyście, czytelnie dla osób, które potem wchodzą i ten kod przejmują.

 

Mam wrażenie, że dotknęliśmy bardzo ważnego zagadnienia, jakim jest rola software house’ów w naszej branży. Z jednej strony można traktować je jako firmy będące podwykonawcami – realizują swoje zadanie i zapominają o tym projekcie, klient też realizuje to we własnym zakresie, gdzieś tam przechodzi i dalej projekt żyje własnym życiem.

Z drugiej strony mam wrażenie, że software house’y mają obecnie, zwłaszcza też taką dużą rolę w tym, żeby uświadamiać ten przysłowiowy biznes o możliwościach, o technologiach, o rozwiązaniach, które być może nie byłyby przez niego zauważone.

Jestem ciekaw jak ty odbierasz rolę software house’ów w branży IT?

 

Mam problem, co mamy na myśli, mówiąc „software house”. Jak popatrzymy sobie na kilkaset z nich w Polsce to one się bardzo między sobą różnią. Z jednej strony nazywamy software house’ami agencje, które wynajmują programistów do pracy u klientów i de facto nie biorą odpowiedzialności za to, co ten programista robi, bo on wchodzi jakby w zespół danego klienta i na drugim końcu skali mamy software house’y, które całkowicie przejmują na siebie kwestie zbudowania systemu, dzielą się swoim doświadczeniem, więc tutaj my się bardziej plasujemy po stronie takiego software house’u, który ma bardzo sprawdzone doświadczone procesy wytwórcze i wydaje mi się, że klienci mają szansę skorzystać właśnie z doświadczenia software house’u, który tworzy oprogramowanie w oparciu o swoje doświadczenia, swoje procesy trochę na zasadzie z jednej strony przerzucenia ryzyka, stworzenia rozwiązania na dostawcę, który ma tych doświadczeń dużo, trochę taka polisa ubezpieczeniowa na zasadzie nie do końca mam wystarczające doświadczenie, więc przerzucam tę potrzebę zrobienia specjaliście, a w razie, gdyby ten specjalista miał problemy, to mam jakieś tam zabezpieczenia umowne, żeby sobie zwindykować straty z tym związane.

Przede wszystkim chodzi o to, że software house’y, które pracują dla wielu klientów, w wielu projektach, w wielu architekturach, technologiach mają mnóstwo doświadczeń, które pojedynczy zespół w ramach danej korporacji nie jest w stanie sobie wytworzyć.

Czasem się podśmiewam, że my jesteśmy jak ta pszczoła, która lata z kwiatka na kwiatek zbierając nektar, jednocześnie przenosząc pyłek z kwiatka na kwiatek. To znaczy, że my przenosimy to doświadczenia, nie mówię o zdradzaniu tajemnic konkretnych klientów, ale przenosimy te doświadczenia, co się powiodło, które technologie się postarzają w długim terminie, jakie rozwiązania u jednego klienta się sprawdziły, więc warto je zastosować u drugiego, więc uważam, że oczywiście stoję tutaj po stronie software house’u, ale zachęcam klientów korporacyjnych nie tylko do wybierania pojedynczych programistów i uzupełniania swoich zespołów, chociaż to jest bardzo potrzebny i słuszny kierunek blendowania zespołów między własnymi i zewnętrznymi, ale też do coraz śmielszego, odważniejszego outsourcowania procesu tworzenia rozwiązania dla kogoś, kto ma doświadczenie, kto ma swój ustandaryzowany proces, kto jest w stanie zapewnić tę przewidywalność harmonogramu, przewidywalność rezultatów, także tutaj też to, co mówiłem wcześniej – że te software house’y budujące oprogramowanie myślą od razu o tym, jak potem będą to oprogramowanie utrzymywać, czy od razu optymalizują kod pod to, żeby potem też relatywnie niskokosztowo utrzymywać to oprogramowanie, więc mnóstwo zalet.

Oczywiście ze współpracy zewnętrznej z software house’em, ale też jest pewna trudność, bo trzeba w tym momencie z tym software house’em się dogadać co on ma zrobić, czyli kwestia zebrania wymagań, przekazania ich, zrozumienia wymagań przez software house, więc zaczynają się tutaj pojawiać pewne specjalizacje branżowe software house’ów, bo taki, który rozumie swoją branżę dużo łatwiej jest w stanie te wymagania zrozumieć w szerszym kontekście niż tylko to, co literalnie zostało zapisane w dokumentacji, back logu, gdziekolwiek, tylko software house mający do wdrożenia w danej branży sobie dopowie pewne aspekty niewypowiedziane i wtedy ta komunikacja w zespole też przebiega znacznie lepiej.

 

Rozmawiając o rozwoju czy kierunkach rozwoju software developmentu nie można też pominąć kwestii sztucznej inteligencji. Co prawda, gdzieniegdzie się jeszcze zdarza, że ktoś wieszczy, że ona po prostu zabierze pracę programistom, ale myślę, że już coraz bardziej rozumiemy, że to jest po prostu narzędzie, tak jak każde inne i można wykorzystać je w różnych zastosowaniach. Nie wiem, czy się zgodzisz ze mną czy uważasz, że AI będzie miało bardziej doniosły wpływ na wytwarzanie oprogramowania?

 

Nie wiem, jak będzie to wyglądało w długiej perspektywie, natomiast patrząc na to, jak można przy pomocy, chociażby demonstracji GPT-3, na podstawie przetwarzania tekstu naturalnego zaczyna tworzyć prototypy pewnych rozwiązań webowych, no to jest to jakiś kierunek, który będzie się rozwijał i do stworzenia prostych prototypów, prostych proof of konceptów, żeby coś klientowi zademonstrować, jak dana aplikacja mogłaby wyglądać, to tutaj widzę, że być może za jakiś czas będziemy mieli dużą pomoc w postaci sztucznej inteligencji.

Natomiast to, co na pewno już dzisiaj widać jako takie praktyczne zastosowanie, no to są wszelakiego rodzaju wsparcie, które daje AI, czy to przy poprawianiu składni, czy to przy wykrywaniu prostych konstrukcji błędnych w kodzie. Ale na pewno też cała kwestia związana też z automatyzacją testów czy dostarczania paczek, tutaj też są narzędzia, które pozwalają wspierać działania zespołów programistycznych.

Nie mówię już o tych aspektach związanych ze skalowaniem infrastruktury, rozkładaniem obciążenia, gdzie wszystkie tutaj wsparcia w postaci tzw. sztucznej inteligencji, bo też są różne poziomy stosowane, ale na pewno widać, że narzędzia oparte o AI zaczynają nam pomagać. To jest jeszcze w dużej mierze w zakresie obietnicy niż takiego realnego wsparcia, ale to realne wsparcie już zaczyna być po części widoczne i wykorzystywane.

 

Oprócz tych zastosowań sztucznej inteligencji mam wrażenie, że obserwujemy też wzrost działań hakerskich czy znajdowania różnych luk w oprogramowaniu. Tutaj wydaje mi się, że to znaczenie bezpieczeństwa kodu jakości, w ogóle projektu ogólnie będzie coraz mocniej nabierało na znaczeniu.

O jakich kierunkach rozwoju według ciebie można mówić w temacie bezpieczeństwa, w temacie działań hakerskich i oprogramowania? Czy tutaj też może jakąś pomoc ze strony AI jesteśmy w stanie uzyskać? Jak to wygląda?

 

Tutaj mamy kilka aspektów, które warto włączyć do takiej codziennej praktyki programistycznej. Z jednej strony pod kątem bezpieczeństwa przede wszystkim budowanie świadomości programisty na temat pewnych konstrukcji, które generują nam podatności w kodzie i są już na rynku dostępne narzędzia, które w sposób statyczny analizują kod i wykrywają takie konstrukcje, które należałoby zrefaktorować, ponieważ generują pewne luki. My z takich narzędzi też korzystamy i jest to niezwykle ważny aspekt w ostatnich latach, gdzie nie tylko skanery dynamiczne w trakcie działania aplikacji czy testy penetracyjne, ale już na poziomie tworzenia kodu, więc. w dwóch obszarach z jednej strony ciągła edukacja programistów o pewnych aspektach, które warto wziąć pod uwagę przy kodowaniu, a z drugiej strony właśnie narzędzia, które automatycznie w procesie CI/CD są w stanie w tym pipeline już weryfikować kod czy aby nie zostały w nim jakieś elementy podatne na włamania.

Innym elementem, który może nie jest tak związany z bezpieczeństwem, ale też z jakością pracy programistów to są różnego rodzaju analizatory kodu pod kątem wyszukiwania obszarów, które albo są obarczone długiem technologicznym, który warto zrefaktorować, albo obszary kodu, które są obarczone tym, że na przykład rozwijane przez jedną, dwie osoby, a nie przez cały zespół i one są podatne na to, że jeżeli ta osoba zniknie z projektu, to wtedy mamy też strasznie duży problem odtworzenia kompetencji, które pozwalają ten kod dalej rozwijać.

To są rzeczy, które warto na etapie tworzenia kodu włączać do procesu wytwórczego. Warto brać pod uwagę, jeżeli chodzi o bezpieczeństwo różnego rodzaju praktyki wskazywane przez regulatory, ponieważ pracujemy akurat w sektorze finansowym, no to nasz rodzimy KNF wydaje rekomendacje, które wskazują co trzeba wziąć pod uwagę, jeżeli chodzi o bezpieczeństwo.

Także ten aspekt jest dzisiaj jednym z kluczowych obszarów w praktyce programistycznej i zachęcam też wszystkich, żeby nie tylko cieszyć się z doskonałości programowania, ale również w rozpoznawaniu różnego rodzaju konstrukcji w kodzie, które właśnie takie podatności generują, a narzędzia, które są dostępne na rynku znakomicie ten proces nauki i wyszukiwania wspierają, także zalecam wszystkim.

 

Rozmawialiśmy do tej pory o kompetencjach twardych, umiejętnościach technicznych, ale do tej pory ciągle ten kod jest tworzony przez ludzi, programistów pracujących w zespołach i z racji na to znaczenie ma też zestaw umiejętności miękkich, nazywanych coraz częściej power skills.

Myślę, że te umiejętności twarde ciągle jednak będą miały swoje istotne miejsce i będą miały duże znaczenie, ale bez takiej dobrej komunikacji, bez umiejętności współpracy w zespole ta jakość wynikowa, prędkość dostarczania rozwiązań może nie być optymalna.

Jakie kompetencje są według ciebie ważne, jakie będą zyskiwały na znaczeniu we współczesnych zespołach deweloperskich?

 

Jest tak, że całe podejście agile’owe do pewnego stopnia w branży wymusiło potrzebę lepszej komunikacji w zespole i poza zespołem. Bardzo się cieszę, że podejście zwinne, szczególnie w branży IT przez ostatnie lata się bardzo mocno ugruntowuje i właściwie każdego programistę zmusza do wychodzenia ze strefy komfortu i do umiejętności budowania tych zdolności komunikacyjnych. Robienie regularnych retro w projekcie powoduje, że ta szczerość w zespole dzielenia się co wyszło, co nie wyszło, co możemy usprawnić jest coraz wyższa. Natomiast poza samą komunikacją w zespole – i zespoły, które się dobrze wewnętrznie dogadują są oczywiście bardziej efektywne – też liczy się to, żebyśmy umieli wyjść z tego swojego świata zespołu projektowego do świata zewnętrznego, czyli świata product ownera, sponsora, osób zarządzających i też umiejętnie komunikowali się z nimi umiejąc trzymać ich perspektywę. To znaczy – nie zarzucając ich żadnym żargonem technologicznym, który powoduje, że oni się natychmiast zamykają w komunikacji, czują się niedouczeni w komunikacji z nami, tak samo, jak my się czujemy niedouczeni w komunikacji biznesowej z nimi, więc tutaj dwie strony muszą wychodzić sobie naprzeciw.

Też liczy się to, żebyśmy umieli wyjść z tego swojego świata zespołu projektowego do świata zewnętrznego, czyli świata product ownera, sponsora, osób zarządzających i też umiejętnie komunikowali się z nimi umiejąc trzymać ich perspektywę. To znaczy – nie zarzucając ich żadnym żargonem technologicznym, który powoduje, że oni się natychmiast zamykają w komunikacji, czują się niedouczeni w komunikacji z nami, tak samo, jak my się czujemy niedouczeni w komunikacji biznesowej z nimi, więc tutaj dwie strony muszą wychodzić sobie naprzeciw.

Myślę, że dzisiaj osoby, które od strony deweloperskiej, które te kompetencje pozatechniczne widzą jako kluczowe i bardzo je rozwijają, jest takich osób coraz więcej, mają też znakomicie otwarte możliwości do zajmowania coraz ważniejszych ról w zespołach czy organizacjach. To jest prosta ścieżka, żeby zostać docelowo szefem deweloperów czy CTO, czy CEO danej firmy, bo jeżeli mamy te umiejętności komunikacyjne, leadershipowe rozwinięte, to jest klucz, żeby pracować mocno z zespołami.

Natomiast z drugiej strony, nawet jeżeli ktoś nie ma takich aspiracji, żeby iść w stronę zarządzania, to trend, który się mocno zarysowuje to bycie takim software engineer konsultantem. To znaczy, że jednak taka umiejętność szerszego spojrzenia jak dane możliwości technologiczne wpływają na wybranie, w którą stronę pójdziemy, czyli ewaluacja rozwiązań, ryzyk, mocnych, słabych stron, zaproponowanie temu decydentowi kilku wariantów podjęcia decyzji to jest taka umiejętność, która jest potrzebna, aczkolwiek trudno rozwijalna w środowisku technicznym, ale osoby, które mają rys consultingowy, doradczy, przeanalizowania różnych scenariuszy, podania pewnych rekomendacji, a jednocześnie wsłuchania się w tę drugą stronę, żeby dowiedzieć się dokładnie, co ona chce osiągnąć jest bardzo kluczowa.

My jako osoby techniczne mamy taką tendencję, które są często przekonane do pewnych konkretnych rozwiązań, bardzo chcemy je narzucać i zawsze jak mamy ten młotek, to wszędzie widzimy gwoździe. Czasem warto się rozejrzeć, bo druga strona być może chce osiągnąć swój cel i nie zawsze ten nasz młotek jest najlepszym narzędziem, żeby ten cel osiągnąć, więc ta umiejętność otwarcia się na wysłuchanie tej drugiej strony jest bardzo kluczowa i zalecam wszystkim programistom, osobom technicznym, żeby te umiejętności consultingowe w sobie rozwijały, wsłuchiwały się w tę drugą stronę, miały tę perspektywę, a nie tylko miały gotowe rozwiązania na wszystko.

 

Tak. Pełna zgoda! Na szczęście z tego, co ja obserwuję w branży, to widzę, że coraz bardziej zauważamy, że nie jesteśmy odosobnioną wyspą, ale mimo wszystko służymy. Biznesowi, klientom, użytkownikom końcowym.

Takie podejście, które zyskuje na popularności, domain driven design, taka ściślejsza praca z klientem, ta specjalizacja software house’ów, o których wspomniałeś. To jest wszystko dążenie do tego, żeby lepiej pomagać użytkownikom, żeby lepiej rozumieć ich domenę, żeby lepiej zbierać te wymagania – czy według ciebie dużo jako branża mamy do zrobienia? Czy idzie ku lepszemu?

 

Myślę, że cały czas mamy dużo do zrobienia. To znaczy – wydaje mi się, że z perspektywy zespołów deweloperskich, żeby jednak nie zapominać o tym aspekcie biznesowym, dla którego realizujemy dane oprogramowanie. Widziałem wiele projektów, które miały problemy z tym że klient musi pewne pojęcie, my je rozumiemy zupełnie inaczej, po czym się na testach okazuje, że dwie strony miały na myśli coś zupełnie innego.

 

Myślę, że cały czas mamy dużo do zrobienia. To znaczy – wydaje mi się, że z perspektywy zespołów deweloperskich, żeby jednak nie zapominać o tym aspekcie biznesowym, dla którego realizujemy dane oprogramowanie. Widziałem wiele projektów, które miały problemy z tym że klient musi pewne pojęcie, my je rozumiemy zupełnie inaczej, po czym się na testach okazuje, że dwie strony miały na myśli coś zupełnie innego. 

Mimo że słownikowo każdy dobrze rozumie słowa, które wypowiadamy, tylko szerszy kontekst perspektywy danej branży znakomicie jest w stanie uzupełnić to, co klient czy też zamawiający do nas mówi. Z jednej strony zalecam nie uczenia się biznesu, ale jednak korzystania ze swoich doświadczeń, że jeżeli zrobiliśmy coś dla sektora bankowego, to mamy jednak tę przewagę rozumienia środowiska bankowego, procesów bankowych i kolejny projekt w tej samej branży będzie dla nas dużo łatwiejszy do zrobienia i dużo łatwiej będzie się porozumieć z klientem.

Z drugiej strony fajnie jest też uzupełniać, szczególnie w procesie zbierania wymagań takimi narzędziami jak event storming, żeby sobie ujednolicić pewne pojęcia, procesy, nawet często się okazuje, że u danego klienta różne departamenty też różnie je rozumieją więc nawet my jako zewnętrzny dostawca uczymy się danej branży, ale też klient sobie uspójnia pewne pojęcia, które między różnymi departamentami były czasem różnie rozumiane, więc to jest na pewno ważna rzecz, żebyśmy korzystali z coraz to nowszych narzędzi analitycznych, które pozwalają daną domenę biznesową rozborować i ją dobrze poznać.

Zauważam też, że z perspektywy biznesu dużo łatwiej się z takimi biznesami rozmawia ze świadomym zespołem wytwórczym, znaczy zespołem, który łapie w lot pewne pojęcia, którymi się posługują, że jeżeli ktoś rzuci hasło „polisa”, to mniej więcej wiemy, co na tej polisie się znajduje, jakiego rodzaju dane są niezbędne, żeby taki obiekt zbudować i to są aspekty, które po pierwsze ułatwiają współpracę, a z drugiej strony współpraca ta dużo szybciej kończy się takim dobrym efektem końcowym, bez jakichś rozczarowań, niespodzianek potem na etapie testów, że jednak coś innego mamy na myśli. Także na pewno specjalizacja domenowa jest czymś, co też pomaga w robieniu dobrego software’u.

 

Cieszę się, że rozmawiając o rozwoju software developmentu mówimy nie tylko o technologiach, ale na koniec chciałem zapytać, czy są jakieś kierunki, które zauważasz, o których nie powiedzieliśmy, a które według ciebie są istotne albo będą w najbliższej przyszłości, jeśli chodzi o software development?

 

Tych kierunków jest pewnie bardzo dużo i w zależności od branży one są trochę różne. Być może to, o czym nie mówiliśmy, ale co warto zaakcentować, to są potrzeby związane z rozwiązaniami IoT, które się w wielu branżach zaczynają pojawiać, czy to w branży handlowej, przemysłowej, w telemedycynie, mamy coraz więcej tzw. programowania machine to machine, gdzie muszą się już nie z człowiekiem komunikować nasz interfejs, tylko z drugim oprogramowaniem czy też z urządzeniem sprzętowym, więc to są na pewno kierunki, które będą się fajnie rozwijały i to już widać, że jest ku temu w wielu branżach bardzo dużo inwestycji.

Pewnie też jakimś kierunkiem, być może jeszcze nie najbliżej nas są różne aspekty związane z tzw. augmentation, to znaczy zarówno wspieranie pracy człowieka, jak i wspieranie tej rzeczywistości poszerzonej, w której możemy funkcjonować, tutaj szczególnie w logistyce czy też telemedycynie, te aspekty się pojawiają. Aczkolwiek mam wrażenie, że to jest bardziej domena jeszcze ciągle startupów, niż takich rozwiązań korporacyjnych, chociaż w takich branżach, które gdzieś dotykają kontaktu ze sprzętem, czyli nie w takiej branży konsumenckiej, finansowej, ale tam, gdzie mamy przemysł, handel, logistykę, to te obszary bliżej dotykające sprzętu są bardzo aktywne. Jak patrzymy nawet na trendy popularności języków programowania, to mamy dzisiaj cały czas Javę i język C jako te dominujące. Python goni jako trzeci, być może będzie w czołówce, ale zastanawiające jest to, że programowanie w C wcale nie jest oprogramowaniem, które gdzieś tam zamiera, tylko ciągle jest to jedne z najbardziej popularnych języków, który jest w szerokiej branży software developmentu używany, także każdy by chciał programować w fajnych frameworkach, ale jednak takie twarde technologie ciągle są potrzebne.

 

Ciekawa przyszłość przed nami! Dziękuję ci za ciekawą rozmowę. Cieszę się, że podzieliłeś się swoimi doświadczeniami, opiniami, bardzo fajnie było tego słuchać i uczestniczyć w tej rozmowie, także z mojej strony jeszcze raz bardzo dziękuję i powiedz proszę na koniec, gdzie można znaleźć cię w internecie? W jaki sposób można do ciebie napisać? W jaki sposób zapytać cię o coś, gdyby ktoś ze słuchaczy zainteresowany był poszerzeniem tego tematu?

 

Dziękuję za zaproszenie i możliwość rozmowy. Zapraszam do mnie na profil LinkedIn, jestem dosyć aktywnym użytkownikiem, także zawsze można mnie tam złapać i ogólnie przez nasza stronę internetową https://altkomsoftware.pl też jestem dostępny, także zapraszam do kontaktu.

 

Świetnie. Wszystkie linki będą w notatce do odcinka. Bardzo jeszcze raz dziękuję. Do usłyszenia, cześć!

 

Dziękuję! Do usłyszenia, cześć!

 

To na tyle z tego, co przygotowałem dla ciebie na dzisiaj. Cieszę się, że miałem okazję porozmawiać z doświadczoną osobą o tym, jakie kierunki są obecnie widoczne w rozwoju oprogramowania. Jestem przekonany, że przyszłość nie raz nas jeszcze w tym temacie zaskoczy.

Jeśli ten odcinek był dla ciebie interesujący i przydatny, odwdzięcz się proszę recenzją, oceną lub komentarzem w social mediach. 

Jeśli masz jakieś pytania, zawsze możesz śmiało pisać na krzysztof@porozmawiajmyoit.pl. Zapraszam też do moich mediów społecznościowych.

Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o kierunkach rozwoju w software developmencie.

Zapraszam do kolejnego odcinka już za tydzień!  

Cześć!