Bajka o programującym durniu

W Krainie Szczęśliwych Projektów wróżka Marketingalia szepce menedżerom do ucha bajkę o cudownych narzędziach. O IDE, frameworkach, generatorach aplikacji albo językach programowania które pozwolą byle durniowi sprawnie pisać formatki, raporty czy ekrany, dopilnują, by nie robił błędów i pozwolą mu tworzyć to wszystko w deterministycznym czasie. A słuchacze - utrudzeni codzienną walką z opóźnieniami, wciąż nowymi trudnościami, chaosem w terminarzu, krnąbrnymi pracownikami - chciwie nadstawiają ucha.

Wiara w srebrną kulę

Legendarny już esej Brooksa No Silver Bullet ukazał się w 1986 roku. Temat był potem obracany w setkach książek, artykułów, badań, opracowań. Jego teza ciągle się potwierdza: nie ma sposobu, by nowa technologia, nowe narzędzie, radykalnie przyspieszyły pracę.

Czemu szefowie w to nie wierzą?

Pierwszy powód: programiści - często Ci sami, którzy przypominają o srebrnej kuli, gdy toczy się dyskusja o harmonogramach - notorycznie narzekają. Że w obecnie używanym języku wszystko jest tak męczące i wymaga tak wielkiej straty czasu na nieważne sprawy. Że IDE w niczym nie pomaga i niczego nie podpowiada. Że trzeba ręcznie pisać SQL czy formatować HTML. Że proces budowy kodu jest bardzo złożony i trwa za długo. Że platforma... Że middleware... Że... Najmądrzejszy szef po wysłuchaniu po raz setny takich uzasadnień opóźnienia projektu zacznie czuć, że coś z jego aktualnym toolkitem jest nie tak.

Druga sprawa to ta sama pokusa, która napędza wielokrotne przepisywanie aplikacji w coraz to innych językach czy frameworkach. Nie ma tak pięknego programu, jak jeszcze nie napisany. Nie ma tak świetnego narzędzia, jak jeszcze nie użyte. To, co już mamy, jest obciążone bagażem przeszłości. Nie tylko znamy wady samego narzędzia, przede wszystkim kojarzymy z nim cały brudny kod, wszystkie drogi na skróty, wszystkie zgniłe kompromisy, wszystkie nieudane elementy projektu, wszystkie niepoprawione błędy. Uciekając w nowe rozwiązania pozbywamy się ich. A o przyszłych błędach jeszcze nie myślimy - tym razem ich nie zrobimy!

Wreszcie: pozornie cuda czasem się zdarzają. Nowa firma z nowym frameworkiem objawia się na rynku i tworzy oprogramowanie w zaskakującym tempie i z bardzo dobrym skutkiem. Mówi się o niej, pisze się o niej, patrzy się na nią. Nie widać ani firm, które postępując podobnie poniosły klęskę, ani faktu, że sukces nie jest sprawą samego narzędzia, tylko zbioru skoordynowanych czynników (a przede wszystkim, dobrania się i właściwego ułożenia w zespół wartościowych ludzi). A trzeba jeszcze pamiętać o słowie nowa - znacznie więcej jest spektakularnych sukcesów nowych firm robiących nowe systemy, niż starych firm migrujących ludzi i projekty.

Problem ludzki

Nieraz mówi się nie tyle o przyspieszeniu projektów, co o umożliwieniu ich tworzenia mniej kosztownym, łatwiej dostępnym ludziom. Dobrze wykształceni specjaliści są drodzy, jakże irytujące jest, gdy tracą czas na głupoty. Czy nie mógłby tego robić przysłowiowy Jasiu po paromiesięcznym kursie doszkalającym? Tytułowy programujący dureń.

To jest zrozumiałe pragnienie.

Wartościowych ludzi nie jest łatwo znaleźć. Już są zatrudnieni. Pracują. Procesy rekrutacyjne oblegają głównie Ci mniej zdolni, a przynajmniej mniej doświadczeni.

Panowała jakiś czas moda, w myśl której firmy chwaliły się: zatrudniamy tylko najlepszych. Tylko najlepsze 2%, no - ostatecznie - 5%. Bardzo zrozumiała zachęta tak dla potencjalnych klientów (dobrzy ludzie stworzą dobre oprogramowanie) jak dla nowych pracowników (będę współpracował z ludźmi którzy pomogą a nie zepsują).

Brzmi ładnie dopóki nie uświadomimy sobie, że te odrzucone przy rekrutacji 98% po prostu idzie złożyć papiery do następnej firmy. I do kolejnej. I do kolejnej... Wiele z tych osób nie umie napisać nawet prostego programiku ale statystykę ładnie nabijają.

Ciekawa rzecz, jaką można zauważyć choćby patrząc na treść szkoleń, pytania zadawane przy wsparciu technicznym, wątpliwości zgłaszane przy realizacji zleconych zadań. Coraz trudniej jest zakładać, że człowiek zatrudniony jako informatyk cokolwiek konkretnego umie. Jeden zna biegle jakiś język programowania ale nie ma pojęcia jak zaprojektować bazę danych. Inny z tym sobie poradzi ale trafia w ścianę musząc oprogramować komunikację po sieci. Trzeci programuje sprawnie przy użyciu wielu technik ale w ogóle nie uświadamia sobie zagrożeń związanych z bezpieczeństwem. Czwarty jest specem od security ale nigdy nie słyszał o używalności. Piąty maluje fajne ekrany ale nie umie się zalogować po ssh na zdalną maszynę by zajrzeć do logów. Itd itp.

Teoretycznie można by przeprowadzić porządny egzamin przy rekrutacji, ale ani nie ma komu go przygotować i prowadzić, ani nie ma czasu na czekanie, aż się w końcu trafi kandydat, który go przejdzie.

Trochę (większych) firm próbuje. W USA znane jest już zjawisko krążenia pytań testowych konkretnych firm po sieci i kandydatów, którzy przychodzą na interview po wykuciu odpowiedzi na pamięć.

W efekcie firmy, chcąc móc cokolwiek planować, sprowadzają całość do wspólnego mianownika i zaczynają patrzeć na nowych pracowników jak na nic nie umiejących idiotów.

Gwiazdy i tłum

Jak to właściwie jest z dobrymi i złymi programistami?

Bardzo często jest powtarzany pogląd o ogromnej różnicy między dobrym, a złym programistą Dobry programista jest co najmniej dziesięciokrotnie lepszy od złego programisty. Nie stać nas na zatrudnianie złych programistów. Zły programista może mieć ujemny wpływ na projekt. Nie trzeba dodawać, że piszący lub mówiący takie słowa sam zawsze uważa się za dobrego. I - że bardzo trudno sprecyzować, co owa dobroć oznacza.

Są też ludzie, którzy twierdzą, że rola wybitnych programistów jest przeceniana, ważniejsza jest dobra organizacja niż konkretni ludzie, osoby z mniejszym talentem i wiedzą często wyrównują to większym zdyscyplinowaniem, wreszcie - nie każdy program musi być napisany optymalnie, nie każda aplikacja wymaga kreatywności.

Ja myślę, że prawda jest jeszcze trochę gdzie indziej, cała ta dyskusja oparta jest na przesadnie upraszczających założeniach.

Przede wszystkim, umiejętność programowania nie jest stała.

Nawet malarstwa czy pisania poezji można się nauczyć, programowania - które jest dziedziną inżynieryjną - tym bardziej. Po sobie samym widzę, jak ogromnie zmieniały się moja wiedza i umiejętności (odkopałem parę lat temu jakieś skrawki kodu z czasów studenckich - brrr). Znam też parę osób, które w początkach swej pracy robiły kiepskie wrażenie, a gdy okrzepły, okazały się zdolne do ciągnięcia sporych projektów. Bywają i przypadki odwrotne, gdy utalentowani ludzie zniechęcają się i zaczynają pracować byle jak.

Do tego, bycie wybitnym zależy od kontekstu.

Od zadań, jakimi się dana osoba zajmuje. Od tego, jak ma zorganizowaną pracę. Od motywacji. Od formalnej i nieformalnej roli w zespole. Nie chodzi tu tylko o oczywistości, jak skierowanie kogoś do zadań niezgodnych z jego umiejętnościami albo toksyczna postawa kierownika zespołu. Wybitni pracownicy są wybitni w konkretnej sytuacji, przeniesieni do innej firmy czy nawet innego projektu mogą wyglądać inaczej.

Wreszcie, oceny często oparte są o sytuacje ekstremalne, nie stałe.

Parę razy w życiu udało mi się zapunktować rozwiązując jakiś problem szybko (najpewniejsza metoda na zdobycie przez programistę poważania u managementu, ludzie liczący czas i pieniądze kodu nie czytają i jego formy nie oceniają). Ale to zawsze kosztuje. Kosztuje w wymiarze indywidualnym - po sprincie trzeba odpocząć, kosztuje też w wymiarze projektowym - powstałe na szybko rozwiązanie wymaga sporo nużącej pielęgnacji, nim naprawdę stanie się dojrzałe. Średnio efekt nie musi być lepszy od efektu zwykłej szarej pracy, a na pewno nie można tempa kryzysowych prac traktować jako normy.

Są metodyki prowadzenia projektów świadomie oparte o cykle sprint - opracowanie. To jest jak najbardziej OK.

Odwrotne skrzywienie to zachwyt jakością projektu czy algorytmu bez uwzględnienia czasu, jaki poświęcono na jego przygotowanie. Bardzo fajna biblioteczka do obsługi daty i czasu, ale czemu powstawała pół roku?

Podsumowując: Ci najlepsi programiści, to osoby trochę mityczne. Bardzo mało jest obiektywnych kryteriów pozwalających kogoś tak ocenić (co stanowi zresztą tylko jeden z odprysków ogólnych problemów z mierzeniem efektywności pracy informatyka), najczęściej jest to albo subiektywne wrażenie, albo po prostu efekt udziału w paru udanych projektach. Bardzo wiele gwiazd to tak naprawdę średniacy, tyle że wykorzystani zgodnie z swoimi kwalifikacjami, dobrze umotywowani, realizujący się w pracy.

Co jest - zresztą - optymistyczne.

Ci straszni, źli programiści

Skąd tak częste podkreślanie problemu złych programistów?

To nieraz naprawdę boli. Boli, gdy przychodzi rozwijać lub konserwować po kimś koszmarnie napisaną aplikację. Boli, gdy mój program zależy od niechlujnej, sypiącej się biblioteki - a to do mnie trafiają wszystkie zgłoszenia błędów. Boli, gdy sugestie elementarnych poprawek kończą się wielogodzinnymi debatami i potrzebą przebijania się przez sterty absurdalnych argumentów (jak można udowodnić, że pisanie pojedynczych funkcji na tysiące wierszy kodu nie jest dobre albo że wątpliwym pomysłem jest totalna denormalizacja bazy danych jeszcze przed jakimkolwiek benchmarkiem?). Boli, gdy cały system jest nagle psuty rozwiązaniami sprzecznymi z ideą z jaką był projektowany. Ogólnie - boli, gdy nie można mieć zaufania do sensowności decyzji podejmowanych przez współpracownika.

Ale to jest przecież ślad po usterce organizacyjnej - wsadzeniu kogoś na zbyt wysokiego konia i pozostawieniu tam bez wsparcia, narzucanych na siłę zadaniach, braku review kodu, strachu przed przyznaniem się do niepowodzenia, nieistnieniu procedury rozstrzygania konfliktów, nieczytelnym podziale kompetencyjnym, niedostatecznym obiegu informacji.

Bywają bardzo źli programiści ale liczniejsi są źle wykorzystani.

Ciąg dalszy nastąpi

Rozpisałem się o ludziach, będę chciał jeszcze wrócić do narzędzi. Bo to, że ich wymiana nie jest panaceum na problemy organizacyjne, zwłaszcza te ludzkie, nie oznacza, że nie powinny ewoluować.

Ale to już następnym razem.