Strona główna » Blog » Nieracjonalni i zabobonni informatycy

Nieracjonalni i zabobonni informatycy

Ten wpis jest kopią archiwalną z moich postów i komentarzy na pewnym wyjątkowym forum dla społeczności IT, na którym publikuję żarty, urządzam prowokacje, dzielę się refleksjami. Generalnie dokuczam kolegom i koleżankom z branży, inspiruję dyskusje i kłótnie.

#1

Wiele razy o tym wspominałem, ale chyba nikt tego nie brał na poważne: informatycy są BARDZO zabobonnymi ludźmi którzy dodatkowo mają skłonności do mocnego konformizmu. Jakby tego było mało, świat tworzenia oprogramowania takiego konformizmu oczekuje i go wspiera i buduje się na mitach, zabobonach, dziwacznych poglądach. Wręcz podstawowa różnica między seniorem a juniorem jest taka, że ten pierwszy posiadł zdolność odnalezienia się w każdym dziwnym zestawie mitów i na bagnistym podłożu irracjonalności jest w stanie skutecznie budować software. Istotny jest konformizm, bo ten zapewnia sukces teamu. Jeżeli team ma wspólne bożki technologiczne, rytuały, konwencje, to odniesie sukces choćby nawet miał pisać w BASICu używając polecenia COME FROM. No i gdy dodamy do tego wysokie zarobki to informatycy zaczynają wierzyć, że oni posiedli jakąś zdolność „wygrywania życia” i że można rozciągać to ich wadliwe postrzeganie na wszystko, na całe życie i całą ludzkość. Otoczenie często to widzi zupełnie jasno, że to jakiś rodzaj zwichrowania osobowości, którego jednak lepiej nie leczyć bo przynosi złote jaja do domu.

To komiczne, gdy spotyka się takiego buńczucznego informatyka, że co to nie on i w ogóle indywidualista i wszystko zna i wie, a tu nagle zaczyna gadać głupoty że tylko taki standard, taka konwencja, uznane praktyki, jedynie słuszne rozumienie xD a potem w tym samym duchu zacznie mówić o polityce, życiu, sporcie, diecie xD najgorsi są chyba fizycy-informatycy, moje zdanie na ich temat niektórzy mogli poznać z komentarzy z ostatniego tygodnia.

#2

Intro: (…) wszyscy się boją napisać cokolwiek nietypowego bo że niby ktoś się na nich się krzywo spojrzy. Ale jak trzeba się kłócić o zabobony typu SOLID, DRY, KISS, jakieś konwencje i pseudo-standardy to do gardła by się rzucili.

Intro 2: (…) branża IT to jest takiego, co każdemu może namieszać w głowie. Spójrz na programistów – niektórzy zaczynają wierzyć w zupełnie irracjonalne zabobony tylu SOLID, DRY, KISS i inne. Albo przedkładają jakieś języczki programowania typu Pajton, Rdzewiej czy Idź ponad inne. No jak dzieci po prostu. No więc IT ma w sobie cos takiego, co ludziom w głowach po prostu miesza i zatracają rzeczywistość. Nie trzeba się wówczas złościć tylko delikatnie, empatycznie takie osób wysłuchać, rozmawiać z nimi, pomóc im odnaleźć prawdziwe przyczyny ich odczuć, wierzeń, skłonności. Nie należy odrzucać albo traktować złością, albo traktować suchą racjonalnością. Rozmowy warto zacząć od wyrażenia tego jak bardzo doceniamy wrażliwość drugiej osoby, jej zapał, jej zaangażowanie, przejęcie.

Intro 3: (…) niektórzy ludzie zamiast akceptować lub odrzucać jakieś zjawiska w sposób irracjonalny – jak Ty to robisz – wolą wykonywać eksperymenty, pomiary itp. Nie każdy opiera się na zdaniu innych czy kieruje konformizmem. Naturalnie, takie cechy nie są pożądane w IT, więc nie jestem zaskoczony, że ich nie posiadasz. IT to siedlisko wielu zabobonów: SOLID, DRY, KISS, separation of concerns i wiele, wiele innych, które nigdy nie przeszły rygorystycznych eksperymentów. Liczy się jednakże nie to, co jest prawdą, ale to, co jest spójne z działaniem danego programistycznego teamu. Zgrany team zrealizuje projekty informatycznie sprawnie choćby nie wiem jak dziwaczne przyjął konwencje i kultywował poglądy.

Otóż te moje odwołania do SOLID, KISS, DRY oraz innych praktyk w wielu moich komentarzach dotyczą tego, że pewne standardy, dobre praktyki i konwencje egzystują w informatyce od lat a czasami dekad, lecz nie wynikają one z niczego innego niż wiary. Nigdy nie udowodniono ich skuteczności w sensie rygorystyczno-naukowym. Dopiero ostatnie lata sprawiły, że zaczęto robić rygorystyczne eksperymenty, prowadzić pomiary i inne takie, aby zrobić z software developmentu dyscyplinę naukową opartą o dowody, evidence-based. I okazało się, że nic nie trzyma się kupy. Wedle mojej wiedzy nie udało się konkluzywnie potwierdzić skuteczności ŻADNEGO z informatycznych przekonań. Gdy piszę „konkluzywnie” to mam na myśli, że kolejne badania przynosiły sprzeczne rezultaty. Czasami eksperyment wykazał, że jakaś praktyka jest super-skuteczna, aby po chwili ten sam eksperyment przeprowadzony gdzie indziej wykazał, że ona w ogóle nie działa. Zaczęto to analizować, w wielu przypadkach zaproponowano interesujące hipotezy. No ale jeżeli jesteś tego ciekawy to punktem wyjścia jest Google Scholar a najlepiej dostęp do płatnych naukowych baz danych.

Wiem, że to co opisuje, może szokować. Ja sam byłem tym ogromnie zaskoczony, w ogóle się tego nie spodziewałem. W swojej osobistej praktyce programistycznej stosuje rozmaite podejścia, których się wyuczyłem przez lata, które weszły mi w krew i miałem je dobrze zracjonalizowane, wyjaśnione, cały światopogląd ułożony od A do Z. Jestem przy tym dosyć skutecznym programistą, więc mógłbym zapytać: czy byłbym tak skuteczny gdyby nie to, że stosuje te skuteczne podejścia?

Jeżeli badania były do czegoś zgodne, to do tego, że cechą charakterystyczną doświadczonych programistów w odróżnieniu od początkujących jest to, że przez lata nauczyli się był skuteczni niezależnie od swoich przekonań, praktyk, konwencji. Czasami nawet wtedy, gdy cos jest niezgodne z tym jak funkcjonuje mózg – przykładem jest stosowanie konwencji nazewniczej camelCase. Ona aktualnie UTRUDNIA sprawne działanie mózgu, co można bardzo obrazowo i łatwo wykazać w eksperymentach z eye trackingiem, nie trzeba do tego robić żadnych wielkich teorii. Okazuje się jednak, że mózgi seniorów programowania dostosowały się do pracy w takich warunkach i są równie skuteczni jak juniorzy na zgodnej z działaniem mózgu konwencji snake_case.

Takich dziwnych doniesień trochę jest i będzie więcej, bo dopiero teraz się rozwija ten obszar badań i stosowane są coraz lepsze narzędzia pomiarowe.

Albo weźmy DRY. Częstą miarą jakości kodu jest istnienie w nim najmniejszej ilości duplikatów. Kod, który ma ich wiele nazywany jest WET i od dekad zaleca się walkę z nim poprzez stosowanie zasady DRY podając szereg powodów dla których tak jest lepiej. Badania jednakże nie wykazały tego, aby było „lepiej” cokolwiek to „lepiej” miałoby znaczyć. Badano gigantyczne zbiory kodu, wielkie repozytoria, wieloletnie historie commitów i nie wykazano jakoby DRY przynosiło mniej bugów, mniej modyfikacji, podnosiło jakość czegokolwiek. Za to zwiększało liczbę późniejszych działań odwrotnych: duplikowania kodu, aby tworzyć jego specjalizowane warianty. Czyli że DRY tak naprawdę bywa zwodniczą przedwczesną optymalizacją i stratą czasu. Badano też repozytoria osób, które nie stosowały DRY i nie odnaleziono niczego, co by wskazywało, że tam było gorzej lub lepiej niż z DRY. Zaproponowano wiele hipotez czemu tak jest, polecam szukać w literaturze.

Ten motyw powtarza się. Badacze biorą pod lupę praktykę X i okazuje się zazwyczaj, że:

  1. To w ogóle działa ALBO
  2. To działa, ale w 95% tylko wtedy gdy stosuje to senior, którego mózg przez lata na przekór wszystkiemu się sam przeprogramował ALBO
  3. To działa, ale tylko w mikroprojekcikach o niewielkim albo żadnym skomplikowaniu.

Ale bardziej istotne jest co innego. Sukcesy ZESPOŁÓW programistów okazują się w ogóle nie zależeć od przyjętych przez nich praktyk i konwencji a jedynie od zgrania i lojalności wobec tych praktyk. Zwycięstwo nie jest więc w prawdziwości tego w co wierzycie, ale w tym, że wierzycie razem, co czyni Wam skuteczną platformę współdziałania umysłów.

Zmierzam do tego, że deweloperzy często gorliwie wyznają fałszywe bożki i paradoksalnie największe mohery-seniory są skuteczni MIMO trwania w fałszu. Można przejść na życie w prawdzie i rozpoznać, że bożki to tylko fikcja, która może być użyteczna jako pewien fundament komunikacyjny, ale nic ponadto. I coraz więcej osób tak robi.

Prawda o skutecznym software developmencie prawdopodobnie do nas dopiero nadejdzie wraz z rozwojem inżynierii oprogramowania bazowanej na dowodach. Najpewniej z jej zdobyczy najmocniej skorzystają nasze dzieci, które nie będą musiały sobie wykrzywiać mózgu, ale będą programować w zgodzie z jego naturalnym ukształtowaniem. Na tę chwilę jednak społeczność IT generalnie brodzi w ciemnocie, którą ma za oświecenie.