Tragedia wspólnego kodu

Scenka1

Facet idzie sobie przez las i napotyka gościa wycinającego siekierą choinki
- Panie co pan robisz! Dlaczego dewastujesz las?
- Nie dewastuję lasu tylko zaciągam dług leśny. Będą święta, na choince powieszę bombki to rodzina będzie zadowolona. No a później posadzę nowe choinki w to miejsce.
- A kiedy to zrobisz?
- no za trzy sprinty...

Scenka2

Facet idzie sobie przez osiedle i spotyka gościa, który wywala gruz do piaskownicy
- Dlaczego dewastujesz plac zabaw?
- Nie dewastuję placu zabaw tylko zaciągam dług osiedlowy. Kładę teraz nową boazerię na ścianę i musiałem skuć trochę. Ale jak już skończę to obiecuję, że ogarnę cały plac zabaw.
- a kiedy to zrobisz?
- no za trzy sprinty...

Scenka3

Facet idzie sobie po piętrze w firmie i patrzy a tu gościu piszę metodę na 500 linijek i 20 ifów
- Panie co pan robisz! Dlaczego dewastujesz kod?
- Nie dewastuję kodu tylko zaciągam dług techniczny. Jest koniec sprinta i trzeba domknąć velocity bo inaczej nam targety polecą. Ale jak już to ogarniemy to potem poprawię.
- a kiedy to zrobisz?
- no za trzy sprinty...

Obecna metafora

Obecnie panująca metafora długu technicznego jest na pewno lepsza od braku jakiekolwiek metafory jako, że przecież dzięki niej w końcu ludzie nie do końca techniczni obdarowani ogromną mocą decyzyjną mogą w pewnych ramach mentalnych zrozumieć, że czasami jak działa to nie znaczy, że jest dobrze (a być może jest dobrze ale dobrze nie będzie).

Jednak pojawia się jednocześnie korpo-zagwostka : bo jak tu pokazać na zebraniu rady wydziałowej, że zaciągnęło się dług pragmatycznie, zainwestowało go pragmatycznie , spłaciło pragmatycznie i liczy zyski również pragmatycznie?

Oczywiście istnieje klasyczny algorytm rozwiązywania tego typu problemów : zmierz cokolwiek co generuje jakiś wykres i jedziemy z targetami - może na początek 120% pokrycia kodu?

Najlepszy tekst jaki do tej pory słyszałem to target : "zmniejszyć dług techniczny o 50%". No i oczywiście programiści nie mogą się z tego głośno śmiać bo mają do spłacenia kredyty, dziecku trzeba zeszyty kupić i psa zaszczepić. No i leci kabarecik. Kilka lat temu sam pisałem testy jednostkowe do 500 linijkowych metod z 30 ifami, które to metody napisali "ludzie, którzy już tu nie pracują" - target spełniony, pokrycie kodu zwiększone do 60% - nieustające pasmo sukcesów trwało.

Gdyby to nie wynikało jasno z powyższych rozważań to model "długu technicznego" pomimo swoich nieocenionych walorów edukacyjnych wydaje się na pod pewnymi względami a może i na dłuższą metę zwyczajnie ku*wa lewy. Jednocześnie istnieje być może coś ciekawszego, coś z zupełnie innej beczki...

Jak to wyszło na wyspach wielkanocnych

Cała historia jest opisana szczegółowo tutaj : Zjebka na wyspach wielkanocnych - a tak w skrócie to:

1. Pomiędzy 400AD a 900AD na wyspy wielkanocne przybywają kontraktorzy z Polinezji i zaczynają nowy greenfield project
2. Z czasem dzielą się na 12 teamów i zaczynają projekty budowy zajebistych takich dużych pomników głów
3. Każdy z 12 managerów chce jebnąć najfajniejszą głowę z kamienia - bo generalnie im większa głowa wyrzeźbiona tym więcej respektu na wyspie,lepsze bonusy świąteczne i miejsce na parkingu bliżej wejścia.
4. Aby przytachać kamienie na plaże gdzie znajdują się stanowiska pracy - używano ściętych drzew jako rolek (taki framework).
5. Projekty idą zgodnie z planem - kolejne głowo-kamienie milowe są budowane
6. Mija kilka wieków i na wyspie nie ma już żadnych drzew a co za tym idzie cały ekosystem poooszedł w pizdu.
7. Na początku szesnastego wieku na wyspę przypływają Europejczycy i zastają garstkę ledwo żyjących mieszkańców (zdaje się, że około 3-10% populacji przetrwało)

A był to wstęp do szerszego zjawiska, które nazywa się..

Tragedia wspólnego pastwiska

Tutaj trzeba poruszać się ostrożnie bo powyższe zjawisko może być zbyt łatwo nad interpretowane "trzeba ludzi kontrolować bo się pozabijają" - co jak zobaczymy nie do końca o to tu chodzi

W 19 wieku angielski ekonomista zauważył, że jak chłopom dać wolną rękę to każdy maksymalizując swój zysk wprowadzi owce czy tam krowy na łąkę - a że każdy chce jak najbardziej nakarmić swoją zwierzynę to szybko wyeksploatują całe pole i będzie kicha dla wszystkich. Niby koleś miał trochę racji ale ważny jest tutaj kontekst sytuacji - otóż ci chłopi wcale nie byli właścicielami ziemi, z której korzystali. Lądem władał tzw. "Suweren" lub była zwyczajnie niczyja.

Własność prywatna - ale czyja?

Pod koniec 20 wieku kilku ekonomistów przypatrzyło się całej teorii i znaleźli pewną istotną zjebkę - otóż w orginale nie rozróżniano dwóch diametralnie różnych sytuacji : "korzystanie z ogólno dostępnego dobra" oraz "korzystanie z dobra będącego własnością wspólnoty". Okazuje się, że w tym drugim przypadku wspomniane wspólnoty ludzi jakoś same rozkminiały zasady korzystania z lasu,jeziora czy łąki. Rozwiązywali oni sami także tzw. "Efekt gapowicza": (Syndrom wesołego Cześka).

Jedna taka pani (Elinor Ostrom) przeprowadziła nawet dogłębne badania i obserwacje, w trakcie których zauważyła następujące niepokojące zjawisko :

• Jest sobie las a obok lasu wieś
• Mieszkańcy wsi korzystają z dóbr leśnych a jednocześnie jak ktoś przekombinuje to dostanie parę sęków gdyż mieszkańcy wsi tak po trochu uważają las za część wspólnoty
• W państwie brakuje kasy
• Las staje się tzw. "własnością publiczną"
• Ludziom narzuca się reguły i mają w zasadzie po trochu już w dupie czy ktoś je łamie - od tego momentu to już bardziej sprawa indywidualnej etyki aniżeli społecznego współużytkowania wspólnego dobra

I kilka cytacików :

Ostrom demonstrated that, within communities, rules and institutions of non-market and not resulting from public planning can emerge from the bottom up to ensure a sustainable, shared management of resources, as well as one that is efficient from an economical point of view. Besides the village of Törbel, Ostrom shows examples of common lands in the Japanese villages of Hirano and Nagaike, the huerta irrigation mechanism between Valencia, Murcia and Alicante in Spain, and the zanjera irrigation community in the Philippines.

The first condition for the institutional basis of the success of these mechanisms is the clarity of the law (Who can do what? What can one not do? Who punishes whom? And how?). In addition to being clear, the rules must be shared by the community. This is why another essential element of self-government is the establishment of methods of collective and democratic decision-making, able to involve all users of the resource.

Furthermore, the mechanisms of conflict resolution must be local and public, so as to be accessible to all individuals of a community. Besides mechanisms of graduated sanctions, a mutual control of the resource among the users themselves must be established.

Więcej tutaj : http://www.aei.org/article/economics/elinor-ostrom-and-the-solution-to-the-tragedy-of-the-commons/

Jak to się ma do jakości kodu

Kilka obserwacji z życia wziętych :

• Czasem - zwłaszcza na początku projektu - programista może skończyć prace nad taskiem szybciej implementując totalnie zjebany kod bez testów
• Niska jakość kodu jebnie w cały zespół w przyszłości
• Jeśli zespól jest poddany pseudonaukowym korpo-praktyką w stylu ocena performensu "risorsa" przez menadzera to pojawia się dodatnie sprzężenie zwrotne pomiędzy szybszym skończeniem taska a nagrodą
• Jeśli zespół (a czasami trudno mówić o zespole bo ludzie są oceniani indywidualnie) ma narzucone reguły kodu to tak mentalnie z założenia widzi właściciela tych reguł poza zespołem
• Jeśli właściciel kodu jest poza zespołem to można go traktować jako "dobro ogólno dostępne" z narzuconymi restrykcjami
• Jest jeden wyjątek gdzie takie narzucone restrykcje są dobre ale jednak w praktyce widzę, że tworzy się często "korporacyjne reguły kodu" i wali po całości unifikacją. To tak jakby każdemu w korpo kazać nosić ten sam rozmiar buta.

Zastanówmy się nad taką metaforą - kod projektu jako wspólne dobro - ale wspólne dobro czego konkretnie? W lesie są drzewa, w morzu są ryby a na łące trawa (dla krów) - co jest w kodzie? W kodzie są szybkie postępy pracy, sukcesy projektowe, potencjał awansu i abstrakcyjny banknot pieniężny. Teoretycznie ktoś waląc haka na kodzie zagarnia te wszystkie rzeczy dla siebie utrudniając jednocześnie osiągnięcie tych samych rzeczy innym. - i jeszcze raz - Syndrom wesołego Cześka

A teraz zastanówmy się co by się stało gdyby tak zespół stał się właścicielem kodu i żaden szczebel menadżerski się w to nie wpierdalał? Tutaj nawiążemy do tego tekstu pisanego italikiem kilka akapitów wyżej :

• Ostrom demonstrated that, within communities, rules and institutions of non-market and not resulting from public planning can emerge from the bottom up to ensure a sustainable, shared management of resources - czy zespół może "oddolnie" stworzyć reguły użytkowania kodu? Ano może
• The first condition for the institutional basis of the success of these mechanisms is the clarity of the law (Who can do what? What can one not do? Who punishes whom? And how?). In addition to being clear, the rules must be shared by the community. - wspólne reguły kodu na które każdy w zespole się godzi? Tutaj będzie zaraz jedno ALE
• Besides mechanisms of graduated sanctions, a mutual control of the resource among the users themselves must be established. - wypisz wymaluj code rewiu.

Ten model znacznie bardziej podoba mi się od porównywania pisania kodu do zaciągania "długu". Niby jest fajnie bo można do góry wysłać wiadomość, że teraz trzeba trochę posprzątać bo kilka placków gówna powstało z okazji dedlajnu. Z drugiej jednak zjawisko pracy z "długiem" raz, że sprawia, że niektórzy myślą, iż rozumieją z czym pracują a tak jest niekoniecznie. No a dwa to pomija ważne aspekty pracy grupowej jak choćby problem radzenia sobie z pasażerem an gapę - i po raz trzeci - Syndrom wesołego Cześka

Jedno małe duże ALE

Jest jedna taka sytuacja w życiu kiedy nawet najbardziej zagorzały przeciwnik wszelkich ograniczeń da się poprowadzić za rękę - jest to tzw "tutorial level" - kiedy nasza wiedza jest zerowa i zwyczajnie czujemy każdą komórką ciała, że czerpiemy wartość z wykonywania poleceń.

Tak jest oczywiście w teorii bo w praktyce działa też inny ciekawy efekt. Otóż np. taka Łódź do niedawna była głównie "maintenace city" i wiele osób siedziało po kilka lat wklejając tu i tam linijkę kodu aby zadziałało (R&D w Łodzi - Refactor and Deployment). Jak ktoś robi takie rzeczy kilka lat i widzi w ogłoszeniach o pracę "senior java developer wymagane 3 lata doświadczenia" to ma prawo pomyśleć , że on jest właśnie takim senior developerem i cały proces odbywa się raczej nieświadomie w ramach tzw. "warunkowania społecznego".

I teraz jak np. ktoś przychodzi do tego ludzika i próbuje go przekonać, że np trzy zagnieżdżone fory z piętnastoma ifami w środku nie są najlepszym pomysłem, to następuje wewnętrzny konflikt pojęciowy pomiędzy "uważam się za doświadczonego developera" a "okazało się, że moim kodem można straszyć dzieci jak nie będą chciały jeść zupki". Prowadzi to do tego, że wiedza o tym jak konkretne decyzja w kodzie wpływają na konkretne metryki i co tak naprawdę zyskujemy/tracimy poprzez stworzenie abstrakcji lub zagnieżdzenie ifa - ta wiedza niekiedy musi być wtłoczona w zespół lekko na siłę. Zakładając, że problem Cześka został wyeliminowany a reszta ludzi wykazuje "oświecony egoizm" -> http://en.wikipedia.org/wiki/Enlightened_self-interest - wtedy wszystko się ułoży. Oczywiście jestem świadom tego, że na mnie działają te same procesy - od czasu "funkcyjnego przebudzenia" staram się znajdować krytykę do każdego konceptu który badam.

To podobnie jak kiedyś miałem taką historię jak się dowiedziałem, że nie należy dokarmiać dzikich kaczek chlebem bo im puchnie to w brzuchy i implodują czy coś takiego. Czyli ludzie mogą chcieć dobrze ale z powodu braku wiedzy robią źle.

Także na dzień dzisiejszy : CZYSTY KOD=MODEL KODU JAKO DOBRA WSPÓLNOTY+ZESPÓŁ WŁAŚCICIELEM KODU + ODPOWIEDNIA ILOŚĆ NAPOMPOWANEJ WIEDZY O JAKOŚCI KODU

Epilog

Na pewno warto model kodu jako ograniczonego dobra wspólnego otwiera nowe ścieżki nazwijmy to "badań" aniżeli metafora "długu" i warto by się przyjrzeć schoćby temu : http://en.wikipedia.org/wiki/Socio-ecological_system - i przestać udawać, że problem jakości kodu sprowadza się do kilku metryk w sonarze i, że się poprawi po trzecim sprincie. A no i akurat na courserze zaczyna się kurs "social psychology" - https://class.coursera.org/socialpsychology-002

Trochę linków :

• http://www.aei.org/article/economics/elinor-ostrom-and-the-solution-to-the-tragedy-of-the-commons/
• http://en.wikipedia.org/wiki/Tragedy_of_the_commons
• http://pl.wikipedia.org/wiki/Efekt_gapowicza
• http://en.wikipedia.org/wiki/Elinor_Ostrom
• http://en.wikipedia.org/wiki/Comedy_of_the_commons
• http://en.wikipedia.org/wiki/Enlightened_self-interest
• http://pawelwlodarski.blogspot.com/2013/08/w-strone-kultury-wartosci-zrozumienie.html