Krzysztof Majdan, money.pl: Jak się żyje programistom? Wciąż tak dobrze, jak się o tym pisze?
Kamil Tarczyński, CTO havenocode.io: Tak. Choć ja nie jestem programistą.
Jak to nie jesteś? Przecież współzakładałeś softwarehouse.
No nie jestem. Całe zawodowe życie spędziłem w IT, wiedziałem, że będę w tej branży, odkąd dostałem pierwszy komputer na komunię, ale programistą nigdy nie byłem.
Nie no, to ja wychodzę. Mieliśmy przecież o programowaniu rozmawiać, a ty żarty sobie ze mnie stroisz.
Czekaj, w tym szaleństwie jest metoda. Nigdy nie byłem programistą w tradycyjnym sensie, jestem programistą no-code.
A co to znaczy "tradycyjny programista"?
Cóż, to po pierwsze ktoś, kto ma ogromną cierpliwość. Wyklikanie czegoś naprawdę sensownego zajmuje sporo czasu. Ja nie mam tej cechy, chcę efektu już teraz, zaraz. Sprawdzić kolejne iteracje, jak to działa. I tak trafiłem na pewne narzędzie.
Jakie?
Bubble - platformę no code/low code. Znalazłem narzędzie do stworzenia prawdziwego SaaS-a [oprogramowanie/usługa na abonament - red.]. Nie musiałem przejmować się infrastrukturą, to było tak łatwe. I to w momencie, gdy nikt na rynku nie chciał za bardzo się tym zajmować, w sensie inwestować w sprawdzenie i pokazanie klientowi, czy to działa. A działa, i to świetnie. I okazało się, że można w ten sposób budować superaplikacje, ruszyliśmy z całą firmą.
A czym jest ten no code i low code?
Całe oprogramowanie tworzy się w interfejsie graficznym przy minimalnej konieczności pisania linijek kodu. Dokładnie widzimy, co tworzymy i jak to wygląda. Od strony backendowej, czyli tego, co się dzieje pod spodem, pod maską aplikacji czy programu, sposób, w jaki użytkownicy wchodzą w interakcje z daną aplikacją, to układamy to, powiedzmy, jak klocki Lego. Na przykład, jeśli użytkownik kliknie przycisk X, to krok pierwszy ma go prowadzić do logowania. Krok drugi - przekierować na odpowiednią podstronę. Budowanie aplikacji z predefiniowanych, trzymajmy się analogii, klocków, znacznie usprawnia proces.
Czyli nie mam kontroli nad tym, co programuję. Albo ograniczoną kontrolę.
W pewnym uproszczeniu, jeśli mówimy o no code, to rzeczywiście nie masz dostępu do kodu, jak w nowym samochodzie, pod maską zobaczysz obudowę silnika i nic w nim sam nie zmienisz. Naturalnie masz szeroki wybór narzędzi, z których możesz zbudować aplikację, ale poszczególne moduły będą działać tak, jak zaprojektował to ich producent. W przypadku low code mamy możliwość dostosowywania ich, powiedzmy "dokręcania śrubek". Masz moduł do logowania, ale potrzebujesz w nim czegoś dodatkowego, dopisujesz dwie linijki kodu i masz rozwiązanie. Szybciej i prościej.
To jest jakaś nowinka? Czy etap w ewolucji programowania?
Dobre pytanie. W obu przypadkach powiedziałbym "tak".
Dlaczego ewolucja?
Jeśli spojrzymy na historię tworzenia oprogramowania, sięgając lat 40. czy 50. ubiegłego wieku, zaczynało się od kart perforowanych, to był taki pierwszy poziom styku z komputerem. Potem były assemblery, a po nich wyższe języki programowania, które mamy do dziś - C# Sharp, C++. Wniosek z tego taki, że coraz bardziej idziemy w tę stronę, by było to mniej abstrakcyjne, łatwiejsze do przeczytania przez człowieka. Programowanie na interfejsie graficznym jest kolejnym krokiem ewolucji kodowania.
A dlaczego to trend, skoro mówisz, że ewolucja?
Bo w Polsce to trend. Na Zachodzie cały kawał rynku. Gartner podaje, że 65 proc. aplikacji w 2024 r. będzie tworzona w podejściu no/low code. W innym raporcie twierdzi, że liczba citizen developerów jeszcze w tym roku będzie czterokrotnie większa niż tych tradycyjnych. Wspomniany Bubble przez pierwsze 10 lat funkcjonowania zbudował społeczność miliona deweloperów. W zeszłym roku doszedł następny milion; w tym roku mamy dopiero luty, a przybyło już pół miliona kolejnych. Twórcy zebrali 100 mln dol. finansowania, co oznacza, że to będzie rosło, a możliwości, już ogromne, będą jeszcze większe.
Czekaj, a czym jest citizen developer?
Osoba o nietechnicznym wykształceniu czy doświadczeniu, która samodzielnie może programować pewne rozwiązania przy użyciu no/low code, np. zwiększające automatyzację danego procesu w firmie czy optymalizację jakiegoś działu. Powstają nowe role związane z IT, gdzie znajomość języków programowania nie jest wymagana, ale umiejętność obsługi narzędzi no/low code i logicznego myślenia już jest atrakcyjnym dodatkiem, pozwala wnieść wartość dodaną firmy. To trochę tak, jak z magikami od Excela.
Magikami od Excela?
Tak, każdy takiego zna. Osobę, która tworzy niebywałe rzeczy, która tak dobrze zna to narzędzie, że predefiniuje określone ustawienia arkuszy, na których działają potem całe działy w firmach. Tu też mamy pewnego rodzaju oddolnych nie-programistów, którzy potrafią tworzyć programistyczne rozwiązania.
A gdzie w tym ci tradycyjni? Wróćmy do tych różnic.
Cierpliwość już wspomniałem, do tego dochodzi oczywiście znajomość semantyki języków programowania i doświadczenie, rozumienie abstrakcji programowania. Juniorzy i midzi to inny temat, ale seniorzy wśród tradycyjnych programistów potrafią tworzyć naprawdę wielkie i unikatowe rzeczy. To przykład tych ludzi, którzy zrobią coś niemożliwego, bo nikt im nie zdążył powiedzieć, że to niemożliwe. I za to biorą te słynne pensje, programista 30k czy nawet więcej. To rodzaj programisty do zadań specjalnych.
Brzmi jak dobry sposób na nadsypanie luki kompetencyjnej. Sektor IT wciąż zgłasza niedobory.
Dokładnie tak. Marc Andreessen powiedział kiedyś, że software zjada świat. Brakuje jednak ludzi, którzy potrafią go tworzyć. Tu dobrą analogią jest czytanie i pisanie. Gdy większość populacji nie miała tych umiejętności, nasz rozwój był powolny. Gdy je zdobyła, rozwój wystrzelił. I tak stanie się w przypadku programowania, gdy więcej ludzi będzie potrafiło tworzyć aplikacje i rozwiązania na jakimś poziomie. Istnieje ponadto szansa, że łatwiej wykształcimy sobie kolejną kadrę specjalistów. Ktoś, kto liźnie temat, zacznie tworzyć rozwiązania, dostanie ten efekt dopaminowy, że coś zrobiłem i to działa, być może wtedy zechce wejść głębiej, stworzyć coś naprawdę zaawansowanego.
A jak jest nietechniczny i myśli o wejściu na rynek IT? Przy czym nie wie jeszcze, co się z czym je.
I tu podejście no/low code ma zalety. Próg wejścia, jeśli chodzi o naukę, jest zdecydowanie niższy. Szkolenie na programistę trwa ok. 12 miesięcy. Tyle mija, zanim ta osoba będzie w miarę samodzielna i poradzi sobie z określonymi zadaniami w tradycyjnym podejściu. Kiedy ruszaliśmy z firmą, tych kompetencji, których szukaliśmy, nie było na rynku, więc sami szkoliliśmy pracowników. Zajmowało to jakieś 3,5 miesiąca, a w tym czasie rozwijali się na tyle, by realizować komercyjne projekty z klientami do dziś.
To jakieś rozwiązanie na problemy rynku. A problemy biznesu? Podejście no/low code jest droższe, skoro to nowość i ewolucja?
Nie, zupełnie nie. Nawet tańsze.
Dlaczego?
Bo programista poświęca na to mniej roboczogodzin, a więc koszt wytworzenia jest niższy. Stawki godzinowe dla programistów zależą od doświadczenia i stażu. Nie różnią się natomiast zbytnio, jeśli chodzi o tradycyjne podejście do kodowania lub nocodowe.
A czemu biznes miałby na to iść? Skoro coś było robione dotąd określoną metodą i działało?
Dla oszczędności. Załóżmy, że przychodzisz do mnie jako klient. Potrzebujesz takiej i takiej aplikacji do zautomatyzowania procesu w swojej firmie. Czy ciebie wtedy interesuje, czy ja to napiszę w C# Sharp albo metodą low code? Nie. Interesuje cię cena i optymalne działanie. Ma spełniać swoją rolę, nie zacinać się, nie pobierać miliona niepotrzebnych plików, ilekroć urządzenie się z nią łączy. Korzyści jest znacznie więcej.
Tak?
Zobacz, organizacje teraz często stoją przed dylematem. Mamy trzy fajne pomysły, ale pieniądze na przetestowanie tylko jednego. Bo realizacja, nie mówiąc już od A do Z, ale nawet do poziomu MVP [minimalnie opłacalny produkt, okrojona funkcjonalnie wersja testowa – red.] jest kosztowna. To wielka zaleta podejścia no/low code. W czasie, który zajmuje stworzenie aplikacji w tradycyjny sposób, deweloper no/low code stworzy dwie, albo może i trzy. Pewnie, będą wymagały dopracowania, niewykluczone, że w tradycyjny sposób, ale nagle organizacja może przetestować trzy MVP zamiast jednego. Dla firmy to dywersyfikacja ryzyka.
Brzmi pięknie. Nawet trochę zbyt pięknie. Jakie tu są wady? Jakie kompromisy zawieramy, gdy wchodzimy w no/low code?
Słuszna uwaga. To podejście, jak każde inne rozwiązanie, ma również swoje wady, ale te bardziej zależą od platformy i tego, co próbujemy zbudować, niż samego podejścia.
Rozwiniesz to?
Niektóre platformy nie pozwalają na rozszerzanie funkcji o dodatkowy, spersonalizowany pod klienta kod, ale też nie wszystkie rozwiązania tego potrzebują. Wtedy mamy do wyboru tylko te funkcje, które oferuje dana platforma. Nie nazwałbym tego wadą tak do końca, jeśli mamy świadomość, co wybieramy.
Co jeszcze?
Są platformy, które nie pozwalają na wybór regionu, w jakim nasze dane będą przechowywane. Dla części firm ma to znaczenie, dla innych żadnego. Niektóre platformy nie pozwalają na eksport kodu i umieszczanie go na własnych serwerach, ale nie zawsze jest to potrzebne. Wynika to z faktu, że niekiedy silnik "renderowania" aplikacji to autorski algorytm danej firmy, którym nie chce się dzielić lub dopuszczać do modyfikacji kodu na platformie, bo mogłoby to negatywnie wpłynąć na stabilność rozwiązania.
Jeśli mamy dostarczony z rozwiązaniem również hosting, to nie mamy wpływu na jego parametry i musimy poruszać się po cenniku abonamentowym - niekiedy jest to wada, jeśli mamy bardzo specyficzne wymagania co do tego, gdzie, jak i na czym powinny być hostowane nasze aplikacje, ale znów są to raczej jednostkowe przypadki i nie zawsze wiążące.
Krzysztof Majdan, money.pl
