niedziela, 29 stycznia 2012

Chybiona metafora

Niedawno internet obiegła poltka głosząca, iż po raz kolejny polski system stał się ofiarą ataku hakerskiego. Nie chodzi tutaj bynajmniej o ataki na strony premiera związane z wprowadzeniem ACTA ale "atak" na system prawny. Najnowszy hak to przerobienie samochodu na bankowóz tak aby móc odliczyć za niego VAT. I Chociaż o tym temacie specjalistą nie jestem to szukając informacji po necie natrafiłem na masę wpisów w stylu "jak wykorzystać luki w systemie na swoją korzyść".Coś dobudujemy,coś przystosujemy i odpowiednio zaksięgujemy.


No fajnie ale co ta informacja robi na blogu,który choć trochę, zajmuje się kwestiami programistycznymi?

Otóż :
Kroczą po tym świecie ludzie, którzy uważają, że programisci to debile.

Od murowania...





Co rusz na forach dyskusyjnych napotykam się na opinie głoszące : "programista jest jak murarz". Chciałbym w tym momencie móc zaznaczyć, że owe opinie tworzy jakaś określona - łatwo rozpoznawalny zbiór ludzi lecz niestety klasyfikacja ta nie jest taka prosta. Do tej grupy niestety zalicza się cały przekrój ról projektowych.

Na chwilę obecną dzielę owych osobników na dwie grupy :

  • ludzi dążących do zbytniego uproszczenia rzeczywistości

    Tutaj dosyć często pojawiają się programiści przemianowani na project managerów.Być może ze względu na zbyt małe doświadczenie w nowej roli a być może ze względu na jakieś introwertywne cechy charakteru próbują oni zredukować dynamiczne i nieliniowe prawa zachodzące w grupie do prostych zasad w stylu programista jest jak murarz i powinien słuchać a nie dyskutować.

  • ludzi posiadających jakieś nieuświadomione kompleksy wymagające ciągłej kompensacji.

    Wiem coś o tym bo sam to miałem. Polega to na deprecjonowaniu każdej odmiennej roli w projekcie. Taki rasizm projektowy. Manager będzie twierdził, że jego obowiązki są kluczowe dla projektu, i każdy musi się mu podporządkować, podobnie analityk, programista czy ktoś tam inny.
    A prawda jest taka, że nie ma roli "ważniejszej". ale o tym kiedy indziej


...do stanowienia prawa





Dlaczego wcielanie w życie projektu IT nie jest jak budowanie domu?

Weźmy kawałek kodu :

public class App 
{
    public static void main( String[] args )
    {
        System.out.println( "Dupa" );
    }
}

Pytanie : co sie właśnie stało?

Otóż nic się nie stało!! Ten kod tutaj nie zadziała podobnie jak wklejenie planów domu na stronę nie sprawi, że zbuduje się nagle dom. TAK!!! owe instrukcje to plany architektoniczne dla kompilatora jak ma zbudować wykonywalny kod maszynowy. Czy to jednak znaczy, że metafora jest dobra a programista jest jak architekt budynków?

No też nie. Każdy kto czyta tego bloga może sobie przekleić ów kod, (jeśli tylko ma zainstalowane JDK) skompilować i być świadkiem narodzin działającej funkcjonalności.
Gdybym umieścił tutaj plany budowy domu to również każdy mógłby je skopiować a później.., no właśnie co później. Trzeba by znaleźć jakąś firmę, która by owe plany wprowadziła w życie.


Cegła w IT jest ku*wa mać za darmo!!!!


W przeciwieństwie do budowy domu mogę zrobić prototyp, pokazać go klientowi a później wyrzucić. Mogę sobie robić refactoring (ta, jestem ciekaw czym w budowaniu domu miałby być refaktoring) i masę innych rzeczy, które po prostu nie miałyby miejsca przy budowaniu domu bo tam takie zabawy kosztują.


Gdzie jeszcze można tak swobodnie manipulować produktem?

BUG #16543 : Po zamontowaniu kratki w samochodzie użytkownicy mogą odliczyć podatek VAT.

Polskie prawo to jeden wielki kod źródłowy , bez żadnych testów jednostkowych, który jest non stop interpretowany przez przeróżne organy. Do czasu wypuszczenia produktu na produkcję można prototypować rozwiązania, robić przeróżne refactoringi czy hot fixy na znalezione bugi - buble prawne. Ostatnia sławna poprawka podegrana na produkcje zdaje się naprawiała bug z lekarzami i aptekarzami.

Podobieństw jest oczywiście więcej ale bynajmniej nie chodzi tutaj o to aby problemy w IT rozwiązywać poprzez analogie do systemu prawnego. Sądzę nawet, że wzór mógłby działać w przeciwną stronę. Jednak to co tutaj chcę uzyskać to skończyć ze stosowaniem zjebanych metafor projektów IT i wiążącym się z tym pewnym błędem logicznym :

Jeśli dziedzina A jest w jakimś stopniu taka jak dziedzina B to wtedy wszystkie problemy w A można rozwiązać poprzez analogiczne rozwiązania w B 


Także jeszcze raz dużymi literami : PROJEKT IT NIE JEST JAK BUDOWANIE DOMU A PROGRAMIŚCI TO NIE MURARZE !



EDYCJA:

Natrafiłem an ciekawą prezentację, która w pewnym stopniu porusza przedstawiony tutaj temat.Oto ona:

http://www.infoq.com/presentations/Questions-for-an-Enterprise-Architect

niedziela, 8 stycznia 2012

Gra o dolara

"Kiedy zorientujesz się, że jesteś w dołku, przestań kopać."

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 :

  1. Przedmiotem licytacji jest jeden dolar
  2. Wygrywa osoba, która zalicytuje największa sumę
  3. 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