Pragmatycznie o… zmianie paradygmatu wytwarzania oprogramowania.

Wstęp i kontekst historyczny

W dzisiejszym odcinku porozmawiamy pragmatycznie o tym, czy stoimy u progu kolejnej wielkiej zmiany paradygmatu wytwarzania oprogramowania. Czy ta zmiana już nadeszła, czy może dopiero jest przed nami? Porozmawiamy o tym, jak nowe technologie i nowe metody wpływają na sposób wytwarzania oprogramowania oraz na to, jak zmienia się nasza codzienna praca. Zapraszam do wysłuchania tego odcinka. Abym mógł lepiej przekazać Wam, co myślę na temat najbliższej przyszłości, a być może już nawet teraźniejszości w świecie wytwarzania oprogramowania, chciałbym najpierw sięgnąć do przeszłości, do tego, jak wytwarzanie oprogramowania wyglądało kilkadziesiąt lat temu.

Zacznijmy od początków, czyli od lat 60., kiedy powstawało pierwsze komercyjne oprogramowanie. Wtedy świat wytwarzania oprogramowania wyglądał zupełnie inaczej niż dzisiaj. Wtedy, aby wytworzyć oprogramowanie, trzeba było najpierw wszystko bardzo dokładnie zaplanować, zapisać w pseudokodzie, a później przenieść ten pseudokod na kod zaprogramowany w kartach perforowanych. Te karty perforowane zawoziło się do jakiegoś uniwersytetu bądź instytutu naukowego, gdzie były one wczytywane przez komputery, które zajmowały wielkie przestrzenie. Używano kart lub taśm, to też się wtedy zdarzało. I te komputery odtwarzały lub uruchamiały kod, który zaprogramowaliśmy, wykonywały obliczenia i po jakimś czasie dostawaliśmy ich rezultat. Często po dość długim czasie.

Wtedy głównym problemem w wytwarzaniu oprogramowania była moc obliczeniowa, dostęp do niej i tak naprawdę dostęp do czasu komputera. Jeśli popełniliśmy błąd w programie, to następna okazja, żeby go naprawić, pojawiała się często dopiero za kilka tygodni, a nawet miesięcy, kiedy znowu mogliśmy uzyskać dostęp do komputera, powtórzyć obliczenia i otrzymać wyniki. I to oczywiście powodowało, że sposób wytwarzania oprogramowania był zupełnie inny niż dzisiaj. Wtedy paradygmat wytwarzania oprogramowania opierał się na tym, aby wszystko bardzo dobrze przemyśleć i przetestować, jeszcze zanim kod zostanie wykonany. To oczywiście miało wpływ na to, w jaki sposób zarządzało się w tamtych czasach wytwarzaniem oprogramowania.

Era komputerów osobistych (lata 80. i 90.)

Pierwszy przełom w sposobie wytwarzania oprogramowania nastąpił w latach osiemdziesiątych i trwał mniej więcej do połowy lat dziewięćdziesiątych. Był to rozkwit komputerów osobistych, komputerów, które zaczęły się pojawiać najpierw w biurach, następnie na uniwersytetach i w szkołach, aż w końcu zaczęły trafiać też do naszych domów. Wtedy pojawiła się koncepcja tworzenia oprogramowania, z którego użytkownicy będą mogli korzystać w domu. Pojawiła się też koncepcja tego, że ludzie zaczęli tworzyć oprogramowanie samodzielnie, w domu. Tutaj problemem przestało być to, co było problemem w latach sześćdziesiątych, czyli dostęp do mocy obliczeniowej, dostęp do narzędzi, dostęp do komputera. Ponieważ te komputery były dostępne dla każdego, problemem stała się dystrybucja tego oprogramowania, gdyż w tamtych czasach to był czas jeszcze przed internetem.

W tamtych czasach, aby komuś dostarczyć oprogramowanie, które mógłby uruchomić na swoim komputerze, trzeba było to oprogramowanie na początku nagrać na dyskietkę, a później tę dyskietkę wysłać pocztą lub dostarczyć do sklepu, gdzie odbiorca mógł sobie tę dyskietkę zakupić. Oczywiście później zostało to zastąpione przez płyty CD, następnie płyty DVD i tak dalej. Problemem wtedy była dystrybucja. Natomiast to spowodowało, że zmienił się paradygmat wytwarzania oprogramowania oraz paradygmat zarządzania wytwarzaniem oprogramowania. Już nie było tak istotne zaplanowanie wszystkiego przed uruchomieniem kodu, ponieważ ten kod można było uruchomić na środowiskach testowych i przetestować na komputerach, zanim dostarczyło się go do dystrybucji, czyli wypaliło na płytach lub nagrało na dyskietkach i wysłało do sklepów.

To był moment, kiedy spopularyzowały się takie modele jak model V czy W wytwarzania oprogramowania, gdzie mamy zsynchronizowane poszczególne etapy testów z poszczególnymi etapami programowania, żeby przypadkiem nie doprowadzić do tego, że rozdystrybuujemy oprogramowanie, które później trzeba będzie naprawiać. Naprawa wiązała się z dystrybucją kolejnych płyt, kolejnych dyskietek, co oczywiście niosło ze sobą bardzo duże koszty. Myślę, że wielu z nas pamięta jeszcze, jak wydawane były nawet w Polsce czasopisma z demami gier, ale na tych płytach były też setki, a czasami nawet tysiące różnego rodzaju patchy. Był to właśnie sposób na dystrybucję poprawek do tych programów.

Era internetu i metody zwinne

Kolejna wielka zmiana paradygmatu wytwarzania oprogramowania nastąpiła w momencie, kiedy spopularyzował się internet, czyli w drugiej połowie lat dziewięćdziesiątych i na początku lat dwutysięcznych. Wtedy to okazało się, że problemem już nie jest dystrybucja. Rozkwit aplikacji webowych, rozkwit chmur obliczeniowych i sytuacja, w której mogliśmy w każdym momencie aktualizować nasze oprogramowanie na produkcji, wgrywając je nawet kilka razy dziennie. Nastąpił wzrost zainteresowania takimi tematami jak Continuous Integration czy Continuous Delivery. To wszystko sprawiło, że mogliśmy w zupełnie inny sposób wytwarzać oprogramowanie. Nasze stare metody, jak model kaskadowy, zaczęły powoli tracić na znaczeniu i przestawały być adekwatne do tego, jak rynek odbierał oprogramowanie i w jaki sposób było ono dystrybuowane.

Ograniczeniem przestała być dystrybucja, a stało się nim dopasowanie oprogramowania do potrzeb użytkownika oraz fakt, że największym kosztem w tamtym momencie wytwarzania oprogramowania było samo programowanie. Spopularyzowały się takie metody jak Agile, Scrum czy Lean, gdzie skupiano się nie tylko na tym, by wytwarzać oprogramowanie coraz wyższej jakości, ale także na tym, by ta jakość sprawiała, że tworzenie i modyfikowanie oprogramowania było coraz tańsze. Poprzednio, w latach 80. i 90., ta modyfikowalność nie miała aż tak dużego znaczenia. Gdy Microsoft wypuścił któryś z systemów Windows w tamtym czasie, łatano go przez kilka lat, ale w międzyczasie pracowano już nad zupełnie nowym Windowsem, który czasami wprowadzał bardzo duże, innowacyjne zmiany.

Pojęcie legacy code nie było wtedy jeszcze aż tak istotne. Za to już po roku 2000, gdy spopularyzował się internet i aplikacje webowe, legacy code był tematem na ustach większości programistów. Sposobem na radzenie sobie z tym były właśnie zwinne metody wytwarzania oprogramowania, czyli Scrum, Kanban, ale też Extreme Programming, podejście Test Driven Development i tym podobne. Powstała świetna książka Uncle Boba, „Clean Code”, która mówi o tym, jak wytwarzać oprogramowanie utrzymywalne w długim okresie, ponieważ wtedy ta utrzymywalność była największym kosztem w samym procesie wytwarzania oprogramowania. Gdyby nie internet, to prawdopodobnie zwinne metody wytwarzania oprogramowania nie miałyby większego sensu w czasach, gdy dystrybucja polegała na wypalaniu i rozsyłaniu płyt. Podejście to ewoluowało wraz z rozwojem dostępnych narzędzi.

Rozkwit product managementu i UX (po 2010 r.)

Rok 2010 i kolejne lata to rozkwit product managementu, UX designu i user researchu. Osoby wytwarzające oprogramowanie zorientowały się, że koszty jakości być może już nie są tak istotne, ponieważ wszyscy zaczynamy korzystać ze współczesnych metod, zapewniamy jakość, używamy Continuous Delivery, Continuous Integration, mamy testy automatyczne i stosujemy zasady Clean Code. Problem z utrzymaniem kodu przestał być naszym największym problemem. Stało się nim to, że wytwarzamy kod, który często nigdy nie zostaje użyty na produkcji. W okolicach 2014–2015 roku powtarzały się wyniki badań mówiące, że 80 procent funkcjonalności w naszych aplikacjach jest używanych rzadko, sporadycznie lub wcale.

Zatem 80 procent pracy włożonej w wytwarzanie oprogramowania w tamtym czasie było pracą zmarnowaną, ponieważ dotyczyło funkcjonalności, których nikt nie potrzebował. Marnowaliśmy przez to bardzo dużo czasu i pieniędzy, a dodatkowym kosztem było późniejsze utrzymywanie tych funkcjonalności. Stąd rozkwit product managementu, który skupiał się na wyborze właściwych funkcjonalności poprzez badania UX-owe z użytkownikami i badanie ich potrzeb. Celem było adresowanie tych potrzeb oraz limitowanie ilości niepotrzebnych rzeczy poprzez sprawny project management. Tworzono tylko te rzeczy, które odpowiadały na realne potrzeby użytkowników, co stanowiło kolejną zmianę paradygmatu.

Czasy obecne i wpływ AI (koniec 2024 r.)

I tak oto dotarliśmy do czasów obecnych; gdy to nagrywam, jest koniec 2024 roku. Przez ostatnie 3–4 lata mieliśmy do czynienia z wieloma innowacjami w podejściu do wytwarzania oprogramowania. Toczy się wiele dyskusji, czy sztuczna inteligencja zastąpi programistów lub scrum masterów. Nie da się ukryć, że sztuczna inteligencja wpływa na to, jak wytwarzamy oprogramowanie, jak nim zarządzamy i jak jest ono dostarczane do użytkowników. Ale zanim o AI, przez ostatnią dekadę miała miejsce ewolucja języków i frameworków.

Pamiętam, jak 10 lat temu budowaliśmy w Pragmatic Coders system fintechowy, co wymagało mniej więcej 20 inżynierów i prawie 2 lat pracy, aby zbudować pierwszą wersję na produkcję. Było to niezwykle czasochłonne i kosztowne. Ostatnio bardzo podobny system fintechowy udało nam się zbudować w dosłownie kilka miesięcy, w zasadzie w mniej niż pół roku, grupą czterech czy pięciu programistów. Koszt i czas potrzebny na wytworzenie podobnego oprogramowania zmniejszył się wielokrotnie. I to było jeszcze przed Copilotem i momentem, w którym AI wielokrotnie przyspieszyło sposób wytwarzania oprogramowania.

Zmiana paradygmatów zarządzania

Co to zmienia? Jeszcze 10 lat temu Scrum, Agile, Kanban, Lean czy Extreme Programming były adekwatne. Dzisiaj ciężko powiedzieć, czy te metody nadal są najbardziej właściwe i optymalne. Jeśli Agile opierał się na pracy zespołowej i interakcjach, a dzisiaj wytwarzanie oprogramowania opiera się na bardzo małych zespołach lub nawet na jednej–dwóch osobach współpracujących z kilkoma modelami AI, to ciężko tutaj mówić o zespole. Sposób zarządzania sprzed dekady powoli przestaje być adekwatny i będzie musiał zaadaptować się do nowych realiów. Myślę, że stoimy u progu kolejnej zmiany, dlatego zachęcam do eksperymentowania z nowymi podejściami do wytwarzania oprogramowania i budowania produktów cyfrowych.

Pojawiły się też zupełnie nowe możliwości, takie jak hiperpersonalizacja i dane o użytkownikach. Kiedyś musieliśmy decydować, którą grupę użytkowników zaspokoić. Dzisiaj, ponieważ wytwarzanie różnych wersji oprogramowania jest bardzo tanie, możemy dostarczyć ich wiele jednocześnie. Nie mówię tu tylko o testach A/B, ale o hiperpersonalizacji, gdzie każdy użytkownik może mieć inną wersję aplikacji, która sama się konfiguruje i dostosowuje do jego potrzeb. Nie musimy tego programować z góry – może to robić sztuczna inteligencja, co już się dzieje w przypadku takich narzędzi jak Gemini, wraz z konfiguracją przez Firebase.

Kolejną zmianą jest zaangażowanie AI do zarządzania wytwarzaniem oprogramowania, w tym decydowania o priorytetach wymagań. Dobrym przykładem są firmy Elona Muska, jak Tesla, gdzie decyzje operacyjne o tym, nad czym pracować i jakie eksperymenty przeprowadzać, są w większości podejmowane przez AI. Pracownicy w fabrykach dowiadują się od sztucznej inteligencji, nad czym będą pracować w danej zmianie. Robią to w bardzo krótkiej pętli zwrotnej (np. 12 godzin), aby szybko zweryfikować, czy kierunek był dobry. Jeśli tak, to kontynuują lub wiele grup pracuje nad tym samym kierunkiem, aby go zeksplorować na różnych płaszczyznach.

Przyszłość interfejsów i agentów AI

Kolejna rzecz na horyzoncie to zastępowanie tradycyjnych interfejsów mobilnych i webowych przez AI. Dzisiaj większość z nas korzysta z Google’a, przeglądając setki stron internetowych, aby znaleźć odpowiedź. Jednak coraz więcej osób korzysta z ChatGPT czy Gemini, które agregują wiedzę i podają gotową odpowiedź. Choć modele te czasem halucynują lub podają ograniczony wycinek informacji, kierunek zmian jest jasny. Za chwilę dojdzie do tego zlecanie konkretnych zadań przez agentów AI podłączonych do naszych systemów bankowych, kalendarzy czy e-maili.

Wyobrażam sobie sytuację, że chcąc pojechać na konferencję do Lizbony, po prostu powiem mojemu agentowi AI, żeby załatwił mi lot, hotel i dojazd. Za trzy minuty dostanę potwierdzenie na e-mail, a moja karta zostanie obciążona. Taka futurystyczna wizja czeka nas bardzo szybko, myślę, że jeszcze w tej dekadzie, a być może w najbliższych dwóch–trzech latach. Oprogramowanie, które dzisiaj budujemy, nie będzie takie samo. Sposób interakcji z komputerami się zmieni, więc specjalizacje takie jak front-end, back-end czy UX mogą przestać mieć tak duże znaczenie i będziemy musieli zaadaptować się do nowych możliwości, jakie daje technologia.

Zakończenie

Na zakończenie poruszę istotną kwestię: w tworzeniu podcastu, podobnie jak w wytwarzaniu oprogramowania, bardzo istotny jest feedback użytkowników. Dlatego proszę o komentarze na YouTubie lub bezpośredni kontakt. Wasz feedback pozwoli na dopasowanie treści do Waszych potrzeb, co pomoże Wam lepiej budować biznesy i produkty cyfrowe.