Archiwa

bookmark_borderScrum zabija

Posted on by kalkus
czaszka scrum

Z nadejściem Agile wiązały się duże nadzieje. Wszelkie szkolenia i manifesty obiecywały przysłowiowe złote góry. Waterfall miał być zły, dostarczać biznesowi coś, czego już nie chciał albo nigdy nie chciał, zaś metodyki zwinne wprowadzały nas w świat, w którym klienci są zadowoleni, a produkt powstaje przyrostowo…

W większości przypadków obietnice Agile okazały się kłamstwem.

Widziałem projekty. Wielkie projekty. Małe projekty. Długie i krótkie. Zabite przez Scrum.

Przed

Jak wspomniałem, w narracji Agile pojawia się omal zawsze manicheizm, czyli walka dobra ze złem. Dobry Agile przybywa nas zbawić od złego Waterfalla. Tyle tylko, że w projektach, w których pracowałem ja i moi współpracownicy nie było mitycznego Waterfalla. Zamiast niego były jakieś nieustrukturyzowane próby zarządzania projektami. Bez nazwy, bez dziesięciu przykazań jak działać, za to z doświadczeniem i mądrością organizacji, które te projekty organizowały. Co ciekawe te metodyki ad hoc działały. Nie były sformalizowane, ale przynosiły wartość przedsiębiorstwom.

walka dobra ze złem scrum

W żadnym „pre-Agile’owym” projekcie, o którym słyszałem nie była problemem nadmierna analiza, czy kurczowe trzymanie się planu, jakie rzekomo miało miejsce w Waterfallu. Być może obserwowałem już inny świat, niż twórcy metodyk zwinnych, może był to jakiś złoty środek, moment przejściowy – tego nie wiem.

Transformacja

Początek implementacji Agile w kraju, w mojej percepcji, zaczął się od szkoleń. Robiły wrażenie. Na warsztatach wszystko się udawało, teoria brzmiała rozsądnie. Wszyscy przecież chcieliśmy zadowolić klientów i dostarczać wartość biznesową od pierwszwego sprintu. To szlachetne pobudki.

Wykresy wyglądały ciekawie i idea oglądania postępu pracy w czasie rzeczywistym była kusząca – technokratyczna i nowoczesna. Estymacja nie czasu, a złożoności wydawała się odsuwać od nas odwieczną czarę goryczy – podawania czasu, jaki zajmie nam wykonanie zadania. Byliśmy dość entuzjastyczni.

Dodam, że w lokalnej, polskiej specyfice Agile oznaczał omal zawsze Scrum. Moje uwagi krytyczne dotyczą głównie, jeśli nie wyłącznie tej metodologii.

Efekty

Dość szybko okazało się, że Agile jest trochę jak komunizm – idee brzmią pięknie, ale w praktyce już tak cudownie nie jest. Co więcej zarzuty, że Scrum nie przynosi korzyści bywają również krytykowane na sposób sowiecki – „to nie był prawdziwy scrum”.

By nie pozostać gołosłownym, co do problemów, przejdę przez kolejne dysfunkcjonalne elementy…

Estymacja

Estymacja oderwana od czasu i ograniczona do liczb z ciągu Fibonacciego stała się rytuałem nużącym i w istocie bezużytecznym. W większości zespołów, z którymi pracowałem można było bez zastanowienia „wycenić” zadanie. W jednym z nich w zasadzie wyceny sprowadzały się do 3 i 5. Mimo tego poświęcało się zawsze mnóstwo czasu na wyjaśnianie natury zadań.

We wszystkich zespołach wyceny różnicowały się szybko do 3-5-8. Osiem zwykle zaś było rozbijane na mniejsze zadania. De facto zadania były małe albo duże, lub też za duże – i wtedy przekształcane w małe albo duże. Mnóstwo na to czasu zwykle było marnotrawione, a trafność estymacji “pojemności” sprintu i tak znikoma.

Wykres spalania i planowanie sprintu

Wykres spalania to chyba najbardziej zabawna rzecz w Scrumie. Prawdę mówiąc w żadnym zespole nie widziałem jeszcze, by wykres choć odrobinę przypominał to, jak wyglądać powinien. Albo nic nie jest „spalane” przez tydzień, a potem nagle spada. Albo rośnie, bo nowe zadania są dodawane do sprintu. Albo znów jest stałą, bo praca jest wykonywana, ale zadania nie są zamykane z powodu blokad.

Oczywiście powodem niewydolności jest binarność statusu zadań. Zadania nie mają natury „do zrobienia” albo „zrobione”. Jeśli w życiu zaplanujemy sobie w przyszłym roku kupić mieszkanie, stracić 10 kilo, zrobić kurs Vue.js i kupić psa, to o ile to ostatnie może odbyć się szybko, to kolejne zadania będą na rocznym wykresie nieustannie linią prostą – aż do momentu zakończenia. Co przecież przeczy celowi samego wykresu – ilustracji postępu.

Planowanie sprintu też z kolei nigdy się nie udaje. Jest to pochodna wadliwych estymat, ale też złożoności procesu wytwarzania oprogramowania, którą próbuje się kolanem dopchnąć i ukryć. Jacek robi średnio 12 story pointów na sprint, Marek 10, Łukasz 5, a Maks 6. Jacek poszedł na urlop na 2 tygodnie. Wszyscy zrobiliby 33. Zakładamy, że odpadnie 8.25, bo przecież nie będziemy wyliczać velocity każdemu z osobna. I co? 3.75, czyli małe zadanie nie zmieści się w sprincie, choć pozornie powinno. Nie mówiąc już o tym, że Łukasz jest praktykantem i bez Jacka robi 3 zamiast 5 story pointów, a Maks 4 zamiast 6, bo jest juniorem i też Jacka potrzebuje. Sprint nie dojedzie.

Bezmyślna zmienność

Klient powinien móc zmienić kierunek, w którym idzie projekt, jeśli istotne parametry biznesowe uległy zmianie. To bez wątpienia zaleta metodyk zwinnych, ich duża przewaga. Jednakże w wielu przypadkach pojawia się bezmyślna zmienność. Zamiast rozpocząć od prototypu, od rysunku, zaczyna się od pełnej implementacji, mając świadomość, że wszystko może być następnie zmienione, bo działamy zwinnie.

W jednym z projektów Agile coach tłumacząc ideę zwinności narysował zespołowi kolejno hulajnogę, skuter, motor i samochód. Narysował, popatrzył i powiedział – oto zwinność, oto iteracyjny rozwój. Cóż jednak, gdy od początku wiemy, że chcemy zbudować samochód? Czy naprawdę budowa hulajnogi na początku pomaga nam w budowie auta później? Czy nie jest wręcz przeciwnie? Czy nie będziemy próbowali wykorzystać amortyzatorów z motocykla do projektu samochodu, narażając użytkowników na niebezpieczeństwo?

Crisp's Blog » Making sense of MVP (Minimum Viable Product ...

Nie muszę chyba dodawać, że powoduje to marnotrawstwo zasobów i frustrację programistów, których praca jest wyrzucana do kosza przez kolejne miesiące i pory roku…

Trudne początki

Założenie, że będziemy dostarczać wartość biznesową od pierwszego sprintu jest całkowicie idealistyczne. Zawsze, ale to zawsze konieczne jest przygotowanie choćby pobieżnego planu, wykonanie pewnych czynności wstępnych i początkowa organizacja. Szczególnie naiwne jest twierdzenie, że da się „dostarczać od razu” w dzisiejszych czasach, gdy często konfiguracja infrastruktury na chmurze, konteneryzacja i projekt architektury średniej wielkości projektu może zająć tygodnie.

Spotkania

Czasami trzeba się spotkać. Przeważnie jednak trzeba się raczej skupić i zastanowić, niż spotkać. Spotkania są moim zdaniem przekleństwem Scrum. Widziałem spotkania, na których dwadzieścia osób obserwowało jedną, która wpisywała do Jiry zadanie. Widziałem spotkania, na których połowa zespołu milczała. Widziałem takie, gdzie dwadzieścia procent gapiło się w telefony.

Spotkania mają to do siebie, że często nie dotyczą bezpośrednio uczestników. Pojawia się wtedy nuda. Nuda oraz marnotrawstwo czasu. Dlaczego pracownik, który na spotkaniach spędza 20% swojego czasu, a z tego połowa jest marnowana, ma być efektywny po spotkaniu? Skoro nie szanuje się jego czasu, to czy nie zabija się jego nawyku szanowania czasu pracodawcy, klienta?

Oczywiście rozwiązaniem powyższego jest tworzenie spotkań w małych grupach. Ma to jednak miejsce rzadko i naturalna jest tendencja do gromadzenia dużej ilości osób.

O spotkaniach można by pisać wiele:

  • zabijają produktywność programistów wyrywając ich ze skupienia,
  • często stają się bezproduktywną dyskusją o niczym, o ile nie ma agendy i dobrego prowadzącego,
  • organizowane za wcześnie, za późno, zbyt długie, w okolicach obiadu – potrafią uczestnikom odebrać sen, radość i entuzjazm
  • zbyt częste – rujnują poczucie produktywności, sensu pracy, irytują

Rezultaty

Wbrew początkowemu entuzjazmowi na własne i cudze oczy przekonałem się, że implementacja Scrum w wielu, chyba nawet w większości przypadków, nie podniosła efektywności zespołów i zadowolenia klientów, a chaos przypudrowany rytuałami, spadek wydajności i opóźnienie w dostarczaniu produktów.

Nie chciałbym sprawić wrażenia, że odrzucam ideę zwinności, która nadal wydaje się bardzo sensowna i kusząca. Jednakże Scrum wydaje się zabijać – zabijać entuzjazm, zabijać zespoły, projekty. Moje przelotne doświadczenia z Kanban pokazują, że Scrum może być ślepą uliczką, a jednocześnie warto nie obrażać się na metodyki zwinne.

Więcej o metodyce Scrum w mojej książce – Programista. Przewodnik po zawodzie.

bookmark_borderMetoda Copy’ego Paste’a

Posted on by kalkus

Swego czasu znajomy programista wystosował do przełożonego nietypową prośbę. Zażyczył sobie pedałów wytnij-kopiuj-wklej. Argumentował, że jego praca bardzo przyspieszy.

Pomysł sam w sobie niegłupi. Szczególnie, gdyby połaczyć go ze skrzynią biegów schowka i zmieniać nią obiekty. Był to oczywiście jego szyderczy żart, ale rzeczywistość już tak śmieszna nie jest, bo wczoraj zmarł Larry Tesler.

Kto?

Twórca metody kopiuj-wklej!

Urodził się w 1945 i studiował na uniwersytecie Stanforda. Podczas pracy w PARC w Xerox w latach 70 pracował nad systemem do obróbki dokumentów – Gypsy. Wtedy i tam właśnie narodziła się idea wytnij-kopiuj-wklej, którą potem zaniósł do Apple, w którym pracował przez kolejne lata.

Nie wiem, jak wy, ale ja od dziś Metodę Copy’ego Paste’a nazywał będę Metodą Teslera.

bookmark_borderDaily na 9

Posted on by kalkus

Owocowe czwartki, game roomy, ubezpieczenia medyczne, elastyczne godziny pracy. Wszystko, byle tylko zwabić dewelopera do firmy. Żeby go zatrzymać, tego wybrednego, rozpieszczonego przez rynek pracy programistę.

Software house to nie Żabka na Bałutach i głodni, jak mawiał Himilsbach: bajkowego nastroju, klienci nie ustawiają się w kolejce od rana. Można zatem rozpocząć pracę wcześniej lub później. Ważne, by osoby pracujące razem mogły się porozumieć, spotkać, wymienić myśli. Benefit jest ważny, bo chronotyp jest ponoć jak wzrost – bez łamania kości nie da się go zmienić.

Czymże jest ten chronotyp? Jest byciem nocnym Markiem albo rannym ptaszkiem. Jest preferencją organizmu do wstawania rano lub do późnej, wieczornej aktywności. Podobno w tradycyjnie żyjących plemionach rozkłada się on tak, że około 25% populacji lubi nocny tryb życia, 25% poranny, a reszta coś pomiędzy. Miałoby to służyć przetrwaniu grupy, bo w każdym momencie nocy i dnia jest ktoś kto czuwa

Mamy więc Janusza, który wstaje z kurami i Mariusza, co zasypia z sowami. Teoretycznie obaj mają elastyczne godziny pracy i muszą się spotkać od czasu do czasu na callu.

I tu – cały na biało – wchodzi scrum master i ogłasza daily na 9.

Janusz spoko, przychodzi na 7, zje śniadanie, zrobi kupę, poogląda koty w internecie i jest gotowy i świeży na spowiedź z wczorajszych tasków.

Mariusz natomiast każdego dnia roboczego wstaje niewyspany, bo najchętniej przyszedłby na 12, a spać wcześniej nie może. Rośnie mu frustracja, spada IQ, wysypia się tylko w weekendy i wakacje. Każdy poranek spieszy się zaspany na to przeklęte daily. I w dodatku zespół patrzy na niego krzywo. Leń, spóźnia się, marudny, czarna owca, baran czarny.

Tymczasem badania sugerują, że nocne Marki są bardziej inteligentne, a nie leniwe: https://www.psychologytoday.com/us/blog/the-scientific-fundamentalist/201005/why-night-owls-are-more-intelligent-morning-larks

Ta drobna z pozoru kwestia organizacyjna, czyli daily o 9 rano, czyni z marszu nieefektywnym część zespołu. Jak dużą część to już zależy od szczęścia lub nieszczęścia, ale statystycznie około jednej czwartej. Nic nie stoi na przeszkodzie, by daily odbywać na koniec dnia lub w jego środku. Jest to zwyczajnie nawyk, rytuał, który się rozprzestrzenił i jest w nieprzemyślany sposób powielany.

Reasumując: podczas organizowania zespołu scrumowego warto zwrócić uwagę na preferencję jego członków co do godzin, w jakich spotkania mają się odbywać. Dotyczy to również spotkań w godzinach około-obiadowych, gdy część osób może po prostu umierać z głodu z powodu kilkugodzinnych dyskusji.

Zbyt poranne daily może obniżyć wydajność zespołu, o ile znajdują się w nim nocne Marki. Warto o tym pamiętać.

bookmark_borderProblem nazw w programowaniu

Posted on by kalkus

Czytanie kodu źródłowego jest trudniejsze, niż jego pisanie. Przyzna to każdy kto pracował z odziedziczonym repozytorium i próbował zrozumieć jego działanie. Przebijanie się przez tysiące linii kodu, przez setki definicji funkcji i zmiennych, w próbie zrozumienia co autorzy mieli na myśli jest ciężkim, męczącym, okrutnie wyczerpującym zadaniem.

Dlaczego tak jest?

Czy zrozumienie przepisu kuchennego jest trudne?

Czy jest trudniejsze od napisania go?

Czy zrozumienie przepisu kuchennego sprzed trzydziestu lat jest trudniejsze od zrozumienia przepisu sprzed tygodnia?

Nie sądzę.

Czemu więc czytanie kodu źródłowego staje się trudniejsze z każdym kolejnym miesiącem od jego powstania? Dlaczego nowy kod jest czytelny, a stary niezrozumiały? Jaka może być przyczyną “gnicia oprogramowania” i nienawiści do legacy code?

Zastanówmy się nad czynnością czytania kodu źródłowego. Co robimy próbując zrozumieć program, wgryźć się w kod?

Działamy jak komputery, tylko mniej wydajnie. Przeglądamy kod, czytamy go, napotykamy na zmienne i funkcje. Nie będąc maszynami nie jesteśmy w stanie spamiętać każdej wartości oraz ciągu konstrukcji. Próbujemy więc “zrozumieć” kod. Napotykając na nazwę zmiennej staramy się domyślić, co oznacza i w jakim kontekście jest używana. Nazwy funkcji lub procedur również próbujemy zrozumieć, najlepiej bez wnikania w ich treść.

Dokładnie tak samo działamy w świecie rzeczywistym. Gdy w przepisie napotykamy na słowo “marchew” wyobrażamy sobie marchew. Rozumiemy ideę marchewki bez zapoznawania się że szczegółami takimi jak jej masa, kolor, DNA, czy temperatura.

Kod źródłowy jednak – mimo starań obozu oprogramowania zorientowanego obiektowo – nie jest jak świat rzeczywisty. Odstaje od niego znacząco.

W świecie rzeczywistym dysponujemy ogromną, lecz ograniczoną ilością słów w naszych słownikach. Języki naturalne przetwarzane są przez ludzkie mózgi zupełnie inaczej niż kod źródłowy przez kompilatory. Krzesło na przykład to dla człowieka nie tylko konkretne krzesło, ale idea krzesła jako takiego. W większości przypadków zbędne nam są szczegółowe informacje na temat obiektów by przetwarzać i rozumieć język naturalny, w którego zdaniach te obiekty, reprezentowane przez słowa, występują. Tam z kolei gdzie jest nam potrzebna precyzja definicji (jak w prawie na przykład) napotykamy na spore problemy.

Świetnym przykładem ilustrującym, co by było gdybyśmy przetwarzali język naturalny tak jak komputery przetwarzają kod źródłowy jest ten filmik:

Wróćmy do czynności czytania kodu przez programistów. Cóż robi developer? Czyta nazwę zmiennej lub funkcji i próbuje zgadnąć, co ona oznacza. Póki kod jest “czysty” i niezbyt stary instynktowne zrozumienie jest stosunkowo poprawne. Czytanie idzie mu dobrze i praca z kodem jest sprawna.

Kłopot zaczyna się, gdy nie jest w stanie poprawnie domniemać znaczenia nazw.

Problem jest jednak znacznie poważniejszy. Jest to jedna z fundamentalnych trudności w rozwoju oprogramowania. Częściowo oddaje to poniższy cytat:

There are only two hard things in Computer Science: cache invalidation and naming things

Phil Karlton

Chodzi o nazewnictwo.

Nazewnictwo jest punktem styku pomiędzy światem maszyn i ludzi. Jest jednocześnie przepaścią między jednym, a drugim. W świecie rzeczywistym, gdzie język ludzki rozumiany jest przez mózgi, które są w stanie instynktownie zrozumieć klasy obiektów / idee przedmiotów rzadko tworzone są nowe słowa. W kodzie źródłowym nowe słowa tworzone są nieustannie.

Co dzieje się, gdy tworzymy nowe słowo w ludzkiej mowie? Uczymy się go. Powstaje nowe słowo – na przykład „komputer” – i wszyscy ludzie na świecie uczą się, że oznacza ono taką, a nie inną rzecz. Nie ma znaczenia, czy mowa o MacBooku, Dellu XPS, ENIACu, czy PC-cie. Nie tworzymy odrębnych słów opisujących komputery stojące w każdym z departamentów firmy, nie tworzymy innych słów na różne modele MacBooka mające inną wielkość pamięci RAM. Nie ma takiej potrzeby. Nowe słowa tworzymy rzadko. Za nowym słowem kryją się duże grupy obiektów. 

Inaczej jest w przypadku kodu źródłowego. „Użytkownik” znaczy co innego w każdym omal programie, jaki do tej pory napisano. W jednych jest to imię i nazwisko, w innych również data urodzenia, w jeszcze innych płeć. W niektórych imię i nazwisko może się składać tylko z liter łacińskich, w pewnych mieć maksymalnie 20 znaków. I tak dalej, etc.

Mówiąc krótko: w kodzie źródłowym niczego nie da się nazwać poprawnie. Żadna nazwa, jak dobrej byśmy nie wybrali, nie będzie odpowiadała znaczeniu słów wyjętych z języka naturalnego, ze świata ludzi.

Możemy być tylko zbyt precyzyjni („user”) lub zbyt ogólni („userWithNameAndSurnameAndSexAndDateOfBirth). Nigdy omal nie będziemy idealnie precyzyjni w nazywaniu zmiennych, czy funkcji. Nigdy te nazwy nie będą znaczyły tego, co nam się wydaje. Zawsze musimy nawigować się do definicji i czytać implementację. Za każdym razem, gdy dołączamy do istniejącego projektu musimy „nauczyć się jego języka”. Nauka nowego języka jest zawsze trudna, żmudna i męcząca. Dlatego właśnie, ze wszystkich wymienionych powyżej przyczyn, czytanie kodu źródłowego jest trudne.

bookmark_borderDlaczego programiści tak dużo zarabiają?

Posted on by kalkus
zarobki programistów

Zarobki programistów w Polsce obrosły legendą. Gazety rozpisują się o nich regularnie. Bywa, że w tonie chwalebnym, bywa, że w tonie nagannym. Jedni ich bronią, twierdząc, że programiści to pożyteczni specjaliści. Inni atakują – wyczekują pęknięcia „bańki” i zrównania zarobków z innymi zawodami. Wiele osób zadaje sobie jednak pytanie – dlaczego programiści zarabiają tak dużo?

O zarobkach programistów więcej w mojej książce – Programista. Przewodnik po zawodzie.

Sytuacja w Polsce

Zacząć by należało od tego, że sytuacja w Polsce jest dość specyficzna. Większość osób zajmujących się w naszym kraju oprogramowaniem pracuje dla zagranicznych klientów. Napływ kapitału (głównie z Europy zachodniej) wzmożył popyt na programistów i w naturalny sposób podniósł cenę ich pracy. Kwestią otwartą jest, jak długo sytuacja ta potrwa, ale na pewno jest korzystna dla Polskiej gospodarki w tym sensie, że eksportujemy nasz talent techniczny otrzymując w zamian, mówiąc językiem PRLu, dewizy – czyli zagraniczne waluty, a także przy okazji importujemy zachodnie praktyki zarządzania projektami, doświadczenie organizacyjne i nawiązujemy kontakty biznesowe z bogatszymi krajami wspólnoty europejskiej.

Często mówi się, że w przeciwieństwie do innych zawodów, programiści w Polsce, pracując dla zagranicznych klientów zarabiają „po zachodniemu”. Prawdę powiedziawszy jest nawet lepiej. Pensje programistów w Portugalii, czy Włoszech są wręcz niższe, niż w Warszawie, czy innych dużych miastach Polski. Z drugiej strony średnie wynagrodzenia są nadal niższe niż w Berlinie, Paryżu, czy – szczególnie – Zurychu lub Nowym Jorku.

Sukces Polski (oraz szerzej – Europy wschodniej) wynika z wysokiego poziomu edukacji, bliskości kulturowej z krajami zachodu, niewielkiej odległości geograficznej, niezłej znajomości angielskiego oraz oczywiście niższych wynagrodzeń. Na chwilę obecną sytuacja wygląda tak, że kluczowe projekty odbywają się w centrach korporacji, te mniej istotne w krajach takich jak Polska, czy Rumunia, a te najbardziej kosztowo zoptymalizowane w Indiach. Ulotki dla inwestorów prezentują Europę środkową jako kompromis między jakością i ceną.

Z drugiej strony istnieje w Polsce pokaźna grupa programistów, którzy pracują za kwoty co prawda wyższe od średniej krajowej, ale również dalekie od słynnych 20 000 PLN. Grupa ta nadal jest słabiej wynagradzana od kolegów z krajów zachodu. Lepiej rzecz jasna od wielu zawodów w Polsce, jednak ciężko ją uznać za realnie zamożną.

 Sytuacja w Europie

Programiści w Europie zarabiają bez wątpienia nieźle, jednak w stosunku do innych grup zawodowych ośmielę się stwierdzić, że nie odbiegają od średniej tak jak specjaliści w Polsce. W pewnej mierze wynika to z konkurencji środkowo-europejskiej. W pewnych krajach niemile widziane jest duże rozwarstwienie dochodów. W innych po prostu miejsc pracy dla programistów nie ma aż tak wielu, bo bardziej opłacalnym i „wygodnym” jest bycie zarządcą – a sporo krajów Europy zachodniej stoi wyżej w światowym podziale pracy.

Kraje, które w stosunku do kosztów życia płacą programistom najlepiej to Szwajcaria, Wielka Brytania, Niemcy i Francja. Kraje, w których być programista się nie opłaca to na przykład Włochy, czy Portugalia.

Sytuacja na świecie

Na dwa kraje warto zwrócić szczególnie baczną uwagę: USA i Chiny.

Na USA z uwagi na tzw. military-industrial complex, czyli nieformalny sojusz pomiędzy przemysłem zbrojeniowym, a armią. Na Chiny z podobnego powodu, ale o tym za chwilę.

stany Zjednoczone dysponują nowoczesną – w wielu obszarach najnowocześniejszą na świecie – armią. Jest to armia nieustannie modernizowana, przesiąknięta nowinkami technicznymi, wyposażona w sprzęt pełen elektroniki.

Dość powiedzieć, że GPS był opracowany na potrzeby armii USA. Dla pełni obrazu można wspomnieć o dronach oraz przypomnieć, że roboty Boston Dynamics budowane były na zamówienie DARPA – agencji zaawansowanych projektów badawczych w obszarze obronności.

Ma to niebagatelny wpływ na rynek pracy inżynierów oprogramowania w USA. Boston Dynamics, Lockheed Martin, Facebook – wszystkie te firmy i wiele innych, zatrudniających setki tysięcy programistów stanowi fundament obronności kraju. Od automatycznych systemów jak drony, czy roboty, po wywiad i cyberbezpieczeństwo, tworzą one ogromny popyt na programistów za oceanem.

Z wolna podobnie sytuacja zaczyna się kształtować w Państwie Środka. Wzrost Chin powodujący inflację ambicji chińskiego narodu sprawił, że przywództwo zaczęło stawiać śmiałe cele. Jednym z kluczowych obszarów w Chińskich planach jest sztuczna inteligencja. Innym, oczywistym, jest rozwój armii. Rzut oka na oferty pracy w Szanghaju, czy Shenzhen pokazuje, jak mocno Chiny stawiają na AI.

Wbrew powszechnej w Polsce opinii, że Chińczycy pracują „za miskę ryżu” wynagrodzenia programistów z ofert pracy w większym mieście posiadającym przedsiębiorstwa z branży militarnej (Chengdu) oscylują wokół 20 000 RMB miesięcznie (ok 11 200 PLN). Daleko im oczywiście do wynagrodzeń oferowanych w Stanach, ale z powodu tych samych czynników, co w USA, można się spodziewać wzrostu popytu.

Dlaczego to się opłaca?

– Nie rozumiem, czemu programista zarabia 15 000, kiedy ja zarabiam 4 000 – powie osoba spoza branży.

Tymczasem to proste.

Informatyzacja robi w zasadzie dwie rzeczy:

  1. automatyzuje pewne czynności sprawiając, że można zatrudnić mniej osób
  2. czyni możliwym rzeczy wcześniej nieosiągalne

Punkt pierwszy, przykład – swego czasu by sporządzić raport sprzedaży w jakimkolwiek sklepie, trzeba było usiąść przed stosem kartek i wykonać dziesiątki, setki operacji matematycznych. Dziś wystarczy kilka kliknięć i mamy wartości i wykresy, a to wszystko w kilka sekund. Jeśli w jakimś przedsiębiorstwie istniała osoba zajmująca się przygotowywaniem raportów (będących powtarzalnymi operacjami przetwarzania danych) można ją zwolnić. Raz opracowane narzędzie do generowania raportów posłuży tysiącom przedsiębiorstw, zaś wykonanie i aktualizacja tych narzędzi zajmuje o wiele mniej czasu i wymaga mniej etatów od tych, które dzięki owemu narzędziu stały się zbędne.

To tylko najbardziej prymitywny przykład automatyzacji. Dużo lepszym są choćby roboty spawające szkielety samochodów w fabrykach:

Zaprogramowany raz robot wykonuje pracę za darmo. Spawacz za każdą minutę bierze pieniądze.

Punkt drugi dotyczy nowych możliwości. Przykłady można mnożyć. Najlepszym bodaj będzie smartfon. Dzięki pracy między innymi programistów możemy dziś nawigować w terenie, słuchać muzyki, komunikować się ze światem i robić dziesiątki innych rzeczy na kilkuset gramowym urządzeniu wielkości połowy banana. Płacimy za nie producentom nieraz tysiące złotych. Dla wyprodukowania takiego cudeńka warto zatrudnić programistów.

Programowanie jest kluczowym narzędziem trzeciej rewolucji przemysłowej. Prawidłowo użyte, wykorzystane z głową potrafi podnieść produktywność przedsiębiorstwa o rzędy wielkości. Przykładem niech będzie Amazon. W porównaniu do tradycyjnego sklepu, Wal-Mart, generuje on dwukrotnie więcej dochodu na pracownika.

Najbardziej wydajną firmą, złożoną głównie z programistów, jest Apple. Jeden jej pracownik zarabia dla firmy prawie dwa miliony dolarów rocznie.

Źrodło: https://businessinsider.com.pl/international/these-tech-companies-make-the-most-revenue-per-employee/xh60rk9

Właśnie dlatego programiści mogą zarabiać dużo. Nie tylko nie ma ich nadmiaru na rynku pracy, lecz także są w stanie generować dla firm zysk o wiele większy, niż przedstawiciele pozostałych profesji.

bookmark_borderCzy programista potrzebuje matematyki?

Posted on by kalkus

Programowanie tradycyjnie kojarzone jest z matematyką. W Polsce wydziały informatyki są najczęściej połączone z wydziałami matematyki (np. Wydział Matematyki, Informatyki i Mechaniki Uniwersytetu Warszawskiego, Wydział Matematyki i Informatyki Uniwersytetu Jagiellońskiego, Instytut Informatyki Uniwersytetu Wrocławskiego). Czy jednak informatyka to aby na pewno dziedzina matematyki?

Uniwersytety takie jak Harvard podeszły do tematu nieco inaczej… Stanford ma osobny wydział: Stanford University – Computer Science Department. MIT łączy informatykę z elektrotechniką, ich wydział to: Electrical Engineering & Computer Science. W przypadku Harvardu mamy Harvard Computer Science department, tak samo zresztą UCLA. Być może nie wynika to z uznania informatyki za dziedzinę od matematyki odrębną, a ze skali i budżetów tych akademii. Może jednak coś jest na rzeczy z tym, że informatyka nie jest tylko matematyką stosowaną?

Multidyscyplinarna i praktyczna

Pierwsze co nasuwa się, kiedy pomyśleć o informatyce to, że jest dziedziną multidyscyplinarną. W dużej, w ogromnej mierze czerpie z matematyki, jednak nie tylko z niej. Przeplata się również z fizyką – bez maszyn, na których wykonywane są jej teoretyczne konstrukty jest niczym. Matematykę można uprawiać na kartce. Informatyka uprawiana na tablicy jest tym mniej więcej, co teoretyzowanie o produkcji tkanin bez budowania tkalni.

Sztuczna inteligencja czerpie inspirację z biologii. Można domniemywać, że aby przybliżyć się do ludzkiego poziomu sprytu i rozumu, będzie się ta dziedzina z neurobiologią i naukami kognitywnymi przelatać jeszcze bardziej.

Informatyka łączy się także z lingwistyką. Teoria automatów to języki i gramatyki formalne, a znaczący wkład w jej rozwój wniósł lingwistyk: Noam Chomsky.

Kreatywna, eksperymentalna, dynamiczna

Matematyka jest abstrakcyjną, intelektualną dziedziną. Myśli się w niej dużo oraz intensywnie, konieczne jest wysokie IQ, dobra pamięć, szczególnie krótkotrwała, by pomieścić wiele tymczasowych informacji w umyśle. Jest jednak matematyka nauką dość stabilną. Rewolucje, przełomy zdarzają się raczej rzadko. Nowe gałęzie pojawiają się, o ile mi wiadomo, nieczesto.

Tymczasem informatyka, choć podobna, w tym sensie, że posługująca się na poziomie teoretycznym aparatem matematycznym, jest jednak inna. Najpewniej z uwagi na swój młody wiek, jest dynamiczna. Nowe dziedziny rozkwitają w niej – by użyć grafomańskiego porównania – jak pąki na wiosennej łące. Nie pojawiły się w wielu miejscach rozstrzygnięcia ostateczne, a inżynieria oprogramowania szczególnie labilna jest jeśli chodzi o reguły i zasady, bo co dekadę niemal uczy się nas programować nieco inaczej, wedle innych zasad i prawideł…

Informatyka jest też o wiele bardziej eksperymentalna od innych dziedzin. W matematyce eksperymentu nie ma w ogóle, jest dowód. Rzecz trudna do wykonania, a do zweryfikowania kosztowna, przynajmniej intelektualnie. W fizyce eksperymenty są coraz droższe, spektakularne, niektóre już stają się (jak LHC choćby) przedsięwzięciami międzynarodowymi i rozpisanymi na dekady. Póki co natomiast informatyka jest polem eksperymentów dość prostych i raczej tanich. Dlatego też elektronik – jak sądzę – zastanowi się dziesięć razy zanim zacznie lutować, natomiast programista często szybciej napisze prototyp, niż zdołałby go w głowie obrócić i oszlifować (z tej cechy wyrastają zresztą w pewnym stopniu metodyki zwinne).

Co programista musi?

Programista musi być cierpliwy i dość bystry, musi lubić się uczyć i mieć umysł otwarty na nowe rozwiązania. Powinien być kreatywny. Koniecznie musi znać angielski. Jeśli chodzi o inteligencję nie trzeba mu IQ matematyka, czy fizyka teoretycznego, ale potrzebna jest jednak jasność umysłu, pewien zmysł logiki. Dobrze jest, gdy programista jest pragmatykiem, a nie idealistą – w programowaniu często trzeba iść na kompromisy.

Matematyka, czy fizyka – przynajmniej teoretyczne – potrzebne są programiście najczęściej na studiach, rzadko natomiast w praktyce zawodowej.

Wbrew pozorom – programista powinien umieć rozmawiać z ludźmi. Programowanie nie polega jedynie na pisaniu kodu i wymyślaniu rozwiązań technicznych, ale również na zrozumieniu potrzeb biznesu, przyszłych użytkowników. Co więcej skala projektów rozrosła się na tyle, że tworzy się je zespołowo, a bycie samotnym geniuszem nie jest już receptą na sukces w branży.

Reasumując – programista nie jest jedynie matematykiem stosowanym. W pewnym stopniu matematyki potrzebuje, ale raczej matematycznego, logicznego stylu myślenia, umiejętności pracy nad abstrakcyjnymi strukturami, niż aparatu matematycznego i znajomości konkretnych działów królowej nauk.

bookmark_borderStudenckie nawyki

Posted on by kalkus

Pewnych nawyków ciężko się pozbyć. Mówi się często o tym, jak ważne są pierwsze odruchy, jakich nabieramy podczas nauki gry na instrumencie. Samoucy natrafiają często na trudności na późniejszym etapie, gdy zmuszeni są oduczyć się błędnych zachowań. Dlatego wynajmujemy dzieciom nauczycieli lub posyłamy je do szkół muzycznych…

Programowanie jest niezwykle dynamiczną dziedziną, z którą jako kraj przez wiele lat nie mieliśmy styczności. Choć na poziomie akademickim pewne techniki i rozwiązania mają już swoje lata i niektórzy twierdzą, że nihil novi sub sole, to jednak wciąż rodzą się nowe strategie radzenia sobie z problemami, nowe pomysły, technologie i języki.

Większość programistów w Polsce nauczyła się programować na studiach. I choć brzmi to niebywale – w większości z nas wciąż tkwią nawyki z tamtego okresu. Nie są to nawyki chlubne. Krajowe uczelnie jak można się dowiedzieć z dowolnego rankingu nie są najlepszymi uniwersytetami świata, a realia wydziałów informatycznych są chyba jeszcze gorsze, niż polskich akademii ogólnie.

Oczywiście mówi się wiele o sukcesach naszych studentów, o wysokich pozycjach polskich programistów w rankingach i tak dalej, ale niestety odpowiedź na pytanie – jakie więc świetne produkty stworzyliśmy? – ogranicza się do gier CD Project oraz platform UXPin, Brand24, czy CodeWise. Oczywiście pod cudzymi markami piszemy o wiele więcej, ale wbrew tłumowi pozwolę sobie być sceptyczny, co do naszych umiejętności – nie u nas urodził się Torvalds, ani Stroustrup, Dijkstra, czy Knuth. Trzeba nam pokory i praktyki.

Uczelnie zatem wpoiły nam złe nawyki. Jakie konkretnie?

1. Przedwczesna optymalizacja

Jak rzekł wspomniany tu już Donald Knuth – przedwczesna optymalizacja jest źródłem wszelkiego zła. Tymczasem na nauce klasycznych algorytmów oraz progresji ku wydajności skupia się program nauczania informatyki na uczelniach. Uczy się studentów sortowania bąbelkowego, by potem pokazać im lepsze, wydajniejsze. Wiele przedmiotów dotyczy głównie na optymalizacji – uczymy się o drzewach BST, o algorytmach grafowych, niektórzy również o kompresji. Wpaja to w studentów przeświadczenie, że wydajność jest okrutnie ważna, najważniejsza. Tymczasem w projektach biznesowych rzadko tak jest.

2. Brak edukacji w zakresie planowania dużych projektów

Ze studiów pamiętam dziesiątki projektów małych, ani jednego wielkiego. Nie organizuje się grupy kilkunastu osób, by wykonały coś dużego, ale zleca pojedynczym studentom malutkie programiki do napisania w pojedynkę. Nie daje to szans na nabycie umiejętności zarządzania wielkim projektem, radzenia sobie z problemami większymi od pojedynczego programisty – a tylko takie projekty spotykamy później w firmach. Dzielenie projektów na etapy, estymacja zadań, ustalanie priorytetów – te kwestie są w edukacji akademickiej nieobecne.

3. Samotnictwo a.k.a. brak umiejętności pracy w grupie

Jak w poprzednim punkcie wspomniałem – projekty na polskich uczelniach są małe, przeznaczone dla jednego studenta na tydzień lub miesiąc, czy dwa. Pociąga to za sobą spore konsewkwencje nie tylko na płaszczyźnie zarządzania projektem. Programiści samotnicy nie mają szans nauczyć się pisać czystego kodu. Pisząc krótko i w pojedynkę nie mogą pojąć wykładu o czystym kodzie, jeśli taki się pojawi. Te problemy dopadną ich dopiero w pracy. Tak samo zresztą jak umiejętność kooperacji z kolegami. Na studiach widziałem wielu, nieraz świetnych, studentów, którzy kompletnie nie potrafili pracować we dwójkę, nie mówiąc o większej grupie. Narcystyczni, outsiderscy, z przerośniętym ego – tacy ludzie dopiero w pracy napotykają na olbrzymie trudności, przez studia przechodząc nieraz z wielkimi sukcesami.

4. Piśmienni, ale nie „czytelni”

Wiele, jeśli nie większość, projektów biznesowych posiada rozbudowane repozytoria istniejącego kodu. Rzadko zdarzają się greenfields, w których można sobie pozwolić na kreatywność i tworzenie z pominięciem lektury cudzego kodu. Czytania jednak studia nie uczą. Poza zrozumieniem algorytmów, gdzie raczej o zrozumienie konceptualne idzie, a nie o czytanie konkretnego zapisu w wybranym języku programowania, nie ma na akademiach przedmiotów związanych z czytaniem kodu źródłowego ze zrozumieniem. Jest to tymczasem kluczowa umiejętność w codziennej pracy każdego profesjonalnego programisty.

5. Dokumentacja? Komu to potrzebne?

Nie licząc pracy magisterskiej i kilku raportów – nigdy na uczelni nie musiałem dokumentować stworzonego oprogramowania. Oczywiście nie każdy aspekt projektu opisywać słownie należy, ale podejście, z jakim się spotkałem na uniwersytecie polegało na oczekiwaniu, by kod działał, niekoniecznie jednak na opisaniu go. Liczył się rezultat, wynik, wyjście, przy zadanym wejściu. Nigdy nie stawiano nacisku na to, co jest w oprogramowaniu niezwykle istotne i stanowi żywotny interes przedsiębiorstw – na utrzymywalność, dokumentację, na transfer wiedzy.

Co zatem robi świeżo upieczony junior magister, o ile jedyne czego się nauczył to program studiów? Nie dokumentuje, pisze bałaganiarski kod, nie wie jak estymować, nie ma pojęcia o ustalaniu priorytetów, nie wie jak się dogadać z kolegami, boi się deadline’ów i nie umie rozmawiać z biznesem, pisać kod potrafi, ale czyta z trudem.

Obyśmy dożyli czasów, gdy akademie zreflektują się, jak ułomne są efekty ich pracy i podejmą próby uzdrowienia sposobu w jaki uczą…

bookmark_borderZdania, które usłyszysz od złego programisty

Posted on by kalkus

1. Możliwe, że przesadziłem z wyceną

Wycofanie się programisty z wyceny, którą zrobił może oznaczać kilka rzeczy, a każda z nich jest zła… Po pierwsze możliwe, że programista jest leniwy i ją zawyżył. Druga opcja, to niestaranne jej przygotowanie. Trzecia wreszcie to, że programiście takiemu brak odwagi cywilnej i woli skłamać, niż powiedzieć gorzką prawdę.

2. Lepiej tego nie ruszajmy

Powyższe zdanie sygnalizuje przede wszystkim zły stan projektu. Jakaś jego część jest tak krucha, że strach ją zmieniać. Jednak jest to również symptom kiepskiej jakości programisty, bo osoba doświadczona powiedziałaby raczej – modyfikacja tego fragmentu projektu jest ryzykowna – po czym spróbowała sytuację naprawić.

3. To 10 minut roboty

Niewinne, ale jednak łgarstwo. Nawet niewielkie zmiany w kodzie, przy złożoności technologii i narzędzi, jakich używamy w rozwoju oprogramowania nie zajmują 10 minut. Jeśli programista obiecuje takie dziesięciominutowe rozwiązania, to najpewniej składa również inne obiecanki-cacanki.

4. Czysty kod to kwestia gustu

Znany z innych obszarów życia relatywizm – nie ma brzydoty, bo komuś coś się podoba. Cóż – czysty kod jest jak czyste miasto. Kiedy widzimy wybite szyby i opadające tynki; kiedy widzimy bełkotliwe nazwy zmiennych i rozwlekłe metody – wiemy, że jesteśmy w mieście, wiemy, że jesteśmy w kodzie brudnym, upadłym, gnijącym. Nie ma tu miejsca na relatywizm. I nie można bronić swojego niechlujstwa relatywizowaniem.

5. To tak było od zawsze

Konserwatyzm jest może dobry w pewnych dziedzinach życia, ale na pewno nie w rozwoju oprogramowania. Nasza branża premiuje dynamiczne zmiany i jeśli ktoś trzyma się starych rozwiązań bez rzeczowego uzasadnienia, a tylko na podstawie tego, że są stare – nie jest dobrym reprezentantem naszego zawodu.

6. Jest bałagan, ale nie mamy czasu na refaktor

O ile są zawody i branże wymagające działania tu i teraz, jak na przykład bycie strażakiem, o tyle – za wyjątkiem “gaszenia pożarów” na produkcji – rozwój oprogramowania nie jest tą branżą, a programowanie tym zawodem. Jeśli jest bałagan, to znaczy, że struktura kodu, projektu przeszkadza nam w pracy. Jeśli programista doprowadza do takiego stanu, to już jest sygnał alarmowy. Jeśli w dodatku tego stanu nie umie zakończyć – rozmawiając z biznesem, wygospodarowując czas, poświęcając wysiłek na uporządkowanie chaosu – to już oznacza, że jest po prostu bałaganiarzem szukającym wymówek, a nie efektywnym profesjonalistą.

7. Nie było czasu na testy

Jeśli nie było czasu na testy, to po co był czas na pisanie kodu? Kod bez testów jest gorszy niż brak kodu w ogóle, bo działanie szkodliwe jest gorsze od zaniechania działania. Co więcej – jeśli nie było czasu na testy, to najwidoczniej nie został on przez programistę uwzględniony na etapie planowania albo też pojawiły się problemy, które podczas implementacji przemilczał, podejmując bez wiedzy biznesu decyzję o obniżeniu jakości.

bookmark_borderDRY is dead

Posted on by kalkus

Reguła DRY jest obok YAGNI, SOLID, czy KISS jednym z najpopularniejszych akronimów pisanych wielkimi literami, które wypłynęły na sposób w jaki staramy się tworzyć oprogramowanie. Jest prosta, intuicyjna i przyswajana przez programistów na wczesnym etapie edukacji. Tyle, że zrodzona w zupełnie innych okolicznościach, niż te z którym dziś mamy do czynienia stała się martwa.

Jej truchło leży na środku sceny i zatruwa nas swoimi oparami.

Prosty pomysł

Nie jestem historykiem programowania i nie dysponuję pewnością co do genezy reguły DRY, ale wyobrażam sobie, że powstała w czasach programowania proceduralnego. W każdym razie proceduralnością pachnie, wręcz cuchnie.

Prosty to pomysł. Banalnie prosty. Mamy sobie kod. Kod należy organizować w procedury, czyli wycinać bloki kodu, które są używane wielokrotnie. Jeśli w jakimś bloku się powtarzamy, to działamy źle, powinniśmy wydzielić go i przekształcić w procedurę.

Ciągle mało

Od czasu programowania proceduralnego trochę się pozmieniało. Przede wszystkim nastąpiła wielka eksplozja paradygmatu obiektowego. Złożoność oprogramowania wzrosła. Biznes miał już swoje systemy automatyzujące księgowość, sumujące przychody, generujące raporty. Trzeba było pisać przeglądarki internetowe, komunikatory, systemy tradingowe dla giełd i snake’a na 3310. Poza ostatnim – były to coraz większe wyzwania.

Tyle tylko, że reguła DRY pasuje do programowania obiektowego jakby mniej. W zasadzie w ogóle nie pasuje, jak się dobrze zastanowić.

Co się dzieje, gdy próbujemy w obiektowym kodzie unikać powtarzania się? Pierwsze co przychodzi do głowy to dziedziczenie: piękny akademicki koncept, który załamał się pod ciężarem rzeczywistości. Pies się wabi, kot ma imię, zróbmy klasę zwierzę. Zrobiliśmy. Szybko okazuje się, że pies się wabi, ale jednak imiona ma inne niż kot, że wabi się, ale kot jakoś gorzej reaguje na własne imię, że zwierzę ma imię, ale nie do końca, bo tylko zwierzę domowe. Robimy klasę zwierzę domowe i dzikie. O cholera – przecież prawie nikt nie nazywa swoich rybek.

Drugie popularne rozwiązanie to żartobliwa oznaka senior developera. Co robi senior developer, gdy przychodzi do chaotycznego projektu? Tworzy folder utils.

Klasy gromadzące wspólne, niepasujące nigdzie indziej kawałki kodu znajdują się obecnie w większości projektów. W niektórych z nich widziałem nawet rozrosłe do 8-16 tysięcy linijek „commony”. Tych polipów da się uniknąć i tak naprawdę powinny zostać rozmasowane z głową na różne fragmenty projektu, ale ich głównym źródłem jest próba stosowania reguły DRY – wydzielenia gdzieś, gdziekolwiek, bo tak najłatwiej, kodu, który się powtarza.

Mikroserwisy – gwóźdź do trumny

Kiedy zapytałem kolegi, który odszedł z Amazona – firmy, która traktowana jest jako modelowa i pionierska, jeśli chodzi o stosowanie architektury mikroserwisów – jak organizują części wspólne, skąd wiedzą, że inny zespół nie napisał już czegoś podobnego, odparł:

 Nie szukamy. Piszemy swoje rozwiązanie. Przy tej skali jest to tańsze i szybsze.

Skala, ogrom systemów, z jakimi przychodzi nam się dzisiaj mierzyć sprawia, że konieczne staje się dzielenie ich na mniejsze. W zasadzie od zawsze było to jedną z podstaw programowania, ale w architekturze mikroserwisów oraz komponentowym podejściu do aplikacji webowych (Angular, React) trend ten uwyraźnia się i przybiera na sile.

I w gruncie rzeczy jest to dużo bardziej obiektowe oraz zgodne z naturą, niż dziedziczenie. Organizmy są do siebie podobne, ale ciężko powiedzieć, żeby były takie same. Oko człowieka nie jest tym samym okiem, co oko psa, czy sokoła. Tylko z pozoru i powierzchownie można zakładać, że jest możliwe współdzielenie. Nie jestem ekspertem z dziedziny genetyki, ale nie wydaje mi się, że gdyby wyciąć z człowieka fragmenty DNA, których nie współdzieli z małpą stałby się automatycznie orangutanem. Silne jest we mnie podejrzenie, że choć wiele w tym podobieństw, czy identycznych fragmentów kodu, to jednak subtelności, kilka „linijek” różnicy sprawia, że dziedziczenie trzeba wziąć w duży, znaczący cudzysłów.

Jak żyć?

Wygląda na to, że reguła DRY dobrymi intencjami wybrukowała nam piekiełko. Czy czas ją odrzucić? Być może. Na pewno warto ją jednak przemyśleć. Warto pamiętać, że w wielu scenariuszach nie powinna być dla nas rekomendacją, że nie jest uniwersalnym narzędziem. Powtarzalność kodu może sygnalizować problemy, a równie dobrze może być najlepszym możliwym rozwiązaniem.

Czy dwukrotne powtórzenie identycznego kodu jest złe? Jeśli w tej samej klasie, pewnie jest. Jeśli w tym samym module, być może. A jeśli w projekcie składającym się ze 100 000 linii kodu, w odległych od siebie modułach? Chyba nie.

Czy częściowe powtórzenie kodu jest złe? Cóż, może nie jest złe arbitralnie, a zależy to od tego, czy da się zbudować odpowiednią abstrakcję, która pozwoli tego uniknąć? Często stosujemy pewne zasady ortodoksyjnie. Dobrze jest jednak zostać centrystą. Wybrać złoty środek. Reguły w programowaniu to zwykle zaledwie sugestie. Nie kierujmy się nimi ślepo.

bookmark_borderKomunikacja asynchroniczna

Posted on by kalkus

Kiedy myślimy o zespole programistów, a konkretnie o jego wydajności – przychodzi nam na myśl zapewne jego doświadczenie, motywacja, czy uzdolnienia. Tymczasem sposób w jaki porozumiewają się członkowie zespołu może zaoszczędzić lub roztrwonić znaczące ilości czasu.

Komunikację w zespole można rozróżnić na synchroniczną i asynchroniczną. Pierwsza oznacza, że nadawca i odbiorca wiadomości muszą w tym samym czasie skupić swoją uwagę. Drugi rodzaj pozwala na odpowiedź po pewnym czasie.

Dominujący rodzaj komunikacji w zespole deweloperskim ma fundamentalne znaczenie dla jego wydajności.

Jeśli zespół komunikuje się synchronicznie, to każda rzecz wymagająca wyjaśnienia rozprasza programistów. Oderwanie dewelopera od kodu, choćby na pięć minut, rujnuje jego skupienie i obniża produktywność.

Przykłady komunikacji synchronicznej:

  • programista czegoś nie wie i potrzebuje zadać pytanie, wstaje, idzie do biurka kolegi i pyta
  • product owner odpowiada na pytania podczas regularnych spotkań, gdzie omawiane są po kolei wątpliwości różnych osób
  • tester nie wie jak przetestować zadanie, podchodzi do programisty i pyta
  • programista potrzebuje pomocy w debugowaniu, podchodzi do pierwszego z brzegu kolegi i prosi o pomoc

Marnujemy w ten sposób dużo czasu i energii. Z pozoru jest łatwiej – nie musimy czekać na pomoc, możemy omówić coś na żywo, wydawać by się mogło bardziej dogłębnie, a jednak… podczas spotkań głównie czekamy na swoją kolej, w trakcie pracy przy biurku współpracownicy przerywają nam flow.

Komunikacja asynchroniczna dla sporej ilości osób jest nieintuicyjna, ma jednak ma wiele zalet:

  • pozwala osiągać długie okresy skupienia
  • pozostawia pisemny ślad, do którego można się odwołać, który można przeszukiwać po jakimś czasie
  • pozwala udzielać bardziej przemyślanych, szczegółowych odpowiedzi na pytania

O ile dla pracowników “z biznesu” asynchroniczność może wydawać się dziwna, o tyle dla programistów powinna być oczywistością. Każdy przecież wie, że ponowne załadowanie kontekstu zajmuje czas, że czekanie na odpowiedź serwera blokuje wykonanie programu. Mimo to – w realnym życiu często zdarza nam się o tych zasadach zapominać.

Przykłady komunikacji asynchronicznej:

  • product owner odpowiada na pytania mailowo, nie natychmiast, ale sprawnie
  • tester zamiast pokazywać programistom problemy opisuje je słownie albo nagrywa filmy pokazujące błędy
  • programista mający pytanie zadaje je na slacku lub mailowo, a osoby z zespołu w momencie, gdy nie potrzebują skupienia odpowiadają mu

Najbardziej efektywne zespoły, w jakich miałem przyjemność pracować komunikowały się w dużym stopniu asynchronicznie. Analogicznie – najbardziej niewydajne, omawiały godzinami na spotkaniach w dużych grupach kwestie, które mogły zostać omówione w e-mailu.

Warto pochylić się nad sposobem w jaki organizujemy sobie pracę i dostrzec wzorce, a następnie zastanowić się, czy nie sabotujemy własnej produktywności złymi praktykami.