Kiedy przestać kopać? Po czym poznać, że poruszamy się w złym kierunku? Czterdzieści lat temu powstałą pewna prosta acz podstępna gra - "licytacja o dolara".Jej zasady są dosyć przejrzyste :
- Przedmiotem licytacji jest jeden dolar
- Wygrywa osoba, która zalicytuje największa sumę
- Osoba, która licytowała drugą w kolejności stawkę również musi ponieść opłatę ale nie otrzymuje nic w zamian!
Licytacja zaczyna się od jednego centa, wydaje się więc ze wszech miar logiczne aby wziąć udział w tejże aukcji. Pierwsza osoba daje jednego centa, druga osoba chce zarobić 98 centów wiec podbija do dwóch centów i tak dalej. Okoliczności ulegają zmianie gdy stawka dochodzi do 1 dolara. OD tego momentu obydwie osoby tak naprawdę będą starać się nie zarobić a zminimalizować straty.
Gra jak i eksperymentu są opisane w internecie (Można zacząć szukać od frazy "Martin Shubik").
Podobno w jednym przypadku dolar został sprzedany za 25 dolarów plus drobne. Przeanalizujmy to jeszcze raz - zestaw jakże racjonalnych kroków doprowadza do sytuacji, która z racjonalnością ma tyle wspólnego co politycy ze szczerością : Zwycięzca płaci za dolara 25 dolarów a druga osoba płaci 24 dolary za niezbędne do życia lecz dostępne pod dostatkiem powietrze.
A teraz czas na obserwację poprzez analogię.
Licytacja o implementację
Sytuacja z implementacją nie jest w stu procentach analogiczna acz bardzo podobna.
Jakiś czas temu mieliśmy do zrealizowania prostą funkcjonalność wyświetlania statusów procesów działajacych się po stronie serwera. Wybór wydawał się logiczny - prosta funkcja JavaScriptu odpytująca się asynchronicznie serwer o listę wyników do wyświetlenia. Wydawało się, że jeden dolar został kupiony za 50 centów. Drugim graczem, który cały czas podbija stawkę jest oczywiście "zmiana" a dokładniej "zmiana w samej funkcjonalności". Tak więc licytacja toczy się dalej a my dokładamy do już wyłożonej sumy kodu. I chociaż za każdego kolejnego dolara płacimy coraz większymi sumami implementacji to pozornie logicznym wydaje się brnięcie dalej w ten proces gdyż przecież nie wyrzucimy od tak sobie kodu, który został już stworzony i już działa.
Gdy już babraliśmy się w oceanie coraz mniej czytelnych funkcji JavaScriptu nastała ta magiczna chwila gdy racjonalność wzięła górę na racjonalnością pozorną i przepisaliśmy całe rozwiązanie uzyskując efekt, który ograniczył "dopłacanie" do kolejnych funkcjonalności. Nie należy tej sytuacji mylić ze zwykłym refaktoringiem , bo chociaż narzędzia są podobne to jednak procesy inne. Podobnych sytuacji w ostatnim roku było więcej i za każdym razem stajemy przed tym samym pytaniem: czy to już czas przestać kopać? W opisie eksperymentu z dolarem możemy przecztać, iż nie ma prostego kryterium decydującego o zakończeniu licytacji, podobnie jak nie ma prostej obiektywnej zasady kiedy przestać brnąć w daną implementację. Z drugiej strony istnieje bardzo prosta subiektywna zasada...
Możemy mianowicie wykorzystać samoobserwację brzmiącą Dlaczego czuję, że to kurwa nie powinno wymagać tyle pracy?. Mamy w swoim mózgu zwoje odpowiedzialne za wykrywanie przekombinowanych rozwiązań. Mamy niestety coś jeszcze. Spuściznę pojaskiniową nakazująca nam brnąć dalej, gonić małego zwierza zamiast ryzykować pościgu za większym. Dlatego niestety, gdy z jednej strony czujemy, że trzeba skończyć to z drugiej strony jesteśmy bombardowani cała kolekcją pseudo racjonalizacji. Czasami dochodzi do tego takie Romatyczne utożsamienie się programisty ze swoim dziełem, które jest nawet przydatne gdy chodzi o jakość kodu lecz może przeszkadzać w trzeźwiejszej ocenie sytuacji.
Stwierdzenie, że wypadałoby zapanować nad tymi uczuciami ma taki sam sens jak apelowania do palacza aby zapanował nad usilną chęcią kolejnego strzała w płuco czy też jak apelowanie do przepełnionej frustracją i kompleksami młodzieży o zapanowanie nad chęcią szukania nieustannej akceptacji na facebooku. To wszystko odbywa się w zwojach poza kontrolą świadomości ale może być sterowane pośrednio. Oto kilka przykładowych ćwiczeń, które powinny pomóc przezwyciężyć lęk przed zmiana źle dokonanych inwestycji:
Na turystę
To w zasadzie technika prosta do wykonania a trudna do zaaranżowania. Wystarczy wyjść radośnie na jakąś ładna trasę turystyczną i po jakimś czasie zorientować się, że idziemy w przeciwną stronę. Ponieważ kontynuowanie tej wycieczki byłoby (zazwyczaj) przejawem debilizmu toteż pozostawiamy kierunek ale zwrot zmieniamy na przeciwny. I nagle ku swej radości (jak tylko opanujemy wewnętrzną złość) przekonamy się iż nie dość, że koniec świata nie nastąpił to do tego (najprawdopodobniej) kierujemy się w dobrą stronę. Do ćwiczenia polecam ściągnąć aplikację "kompas" na Androida która pokazuje kierunki w sposób losowy.
Na gracza
W tym przypadku wybierz sobie jedną z tych gier, w których ludzie kompensują swoje porażki życiowe rozwijaniem jakiejś postaci.Najpierw zacznij rozwijać postać w jakimś mało przydatnym kierunku aby później zmienić klasę na coś przydatniejszego. Np. z pijącego woźnego 7 poziomu zacznij się rozwijać jako właściciel firmy sprzątającej. Polecana jest także wariacja tego ćwiczenia polegająca na tym aby po osiągnięciu danego poziomu swoją postacią wyjebać grę i zająć się czymś pożytecznym w życiu.
Na pakernie
Na pakernie chodzi się aby zdrowo żyć i przez kompleksy albo przez kompleksy i aby zdrowo żyć. Tak czy inaczej aby zbudować mięśnie trzeba jeść a jak się je to rośnie też tłuszcz. A jak rośnie tłuszcz to trzeba go potem zrzucić - i tutaj meritum ćwiczenia - ów tłuszcz się zrzuca z częścią mięśni. Jeśli podobnie jak ja cierpicie na kompleks małego samochodu to łatwiej wam będzie wyobrazić sobie, jakie to bolesne rozstawać się z mięśniem ale jeśli nie chce się być grubym knurem trzeba pójść w kierunku redukcji. Mechanizm ćwiczenia jest dobry.
A ponieważ dodatkowo żyjemy w społeczeństwie a większość społeczeństwa lubi masowo uczestniczyć w alkoholowym procesie samokastracjach to też i ta sytuacja pomaga we wspomnianej kategorii ćwiczeń.
PS.
Powyższy tekst (broń Boże) nie miał na celu ukazania programistów jako ludzi z problemami emocjonalnymi, którzy nie mogą poradzic sobie z rzeczywistością wymagającą zmian. Nie może również służyć na potrzeby przerzucenia odpowiedzialności za ogarnięcie zmian tylko na programistów. Otóż obok "pragmatycznego podejścia do racjonalnej zmiany" występuje coś co można określić jako "emocjonalne podejście do debilnej zmiany". Ma ono miejsce wtedy gdy osoba o wątpliwych zdolnościach analitycznych bierze na siebie definiowanie wymagań co powoduje wyrzucanie do śmieci kolejnych to kawałków kodu. Aby to dobrze zrozumieć należy odróżnić sytuację gdy będąc świadkami wypadku podejmujemy próbę udzielenia pierwszej pomocy, z sytuacją gdy po obejrzeniu "Było sobie życie" obwieszczamy się chirurgiem i wbiegamy na sale operacyjną operować. Czasami ktoś musi udzielić pierwszej pomocy i zebrać wymagania ale chyba nie ma bardziej wkurwiającej rzeczy dla programisty niż wyrzucanie w błoto krwi, potu i łez "bo ktoś się nie dogadał".
http://pl.wikipedia.org/wiki/Aukcja_o_dolara
Brak komentarzy:
Prześlij komentarz