W stronę żywej specyfikacji

Czytałem kiedyś bajkę o tym jak to Product Owner tworzy w notatniku wymagania prezentowane przez kilka linijek tekstu, później programiści tworzą z tego testy funkcjonalne i żyli długo oraz szczęśliwie. Bajka nazywała się "Agile coś tam" i miała niewiele obrazków.

Chociaż w głębi duszy wierzę, że wspomniana współpraca, harmonia i trendy słowo : "synergia", są teoretycznie możliwe pomiędzy tzw. "IT" i tzw. "Biznesem", to jednak w praktyce na chwilę obecną ograniczamy się głównie do aktywności ze strony zespołu programistycznego.

Tumbler

Krótko i na temat. Tumbler (tumbler home) pozwala zrobić coś takiego :




(Jeśli ktoś nie wie skąd się wzięły adnotację ---> Behavior Driven Development)

Później generujemy ładny raport :


I nawet to jako tako jest to użyteczne dopóki mamy mało "user stories". Gdy liczba scenariuszy zaczęła zbliżać się do 1500 zauważyliśmy, że już mało komu chce się to czytać.

Tumbler + Maven

W trakcie jednej z prezentacji na GeeCONie, prowadzący ją koleżka wyłożył proste acz idealne rozwiązanie tego problemu

- Jeśli testów jednostkowych nie trzymasz w jednym module to dlaczego masz robić inaczej z testami funkcjonalnymi?

I tak oto rozbijamy sobie projekt, który pełnił rolę worka testowego, na głównego POMa i podmoduły reprezentujące konkretne ficzery:



Teraz zostaje nam już tylko odpalić mvn clean test (czasem trzeba dać install na commonie) i w każdym pod module pojawi się ładny mini raport.

I już tylko pozostaje nam poskładać to wszystko do kupy...

+ Groovy

Zakreślony na czerwono pliczek odpalamy na sam koniec. Znajdzie on wszystkie raporty i sklei w całość:



A jak klikniemy w w nagłówek sekcji to zobaczymy raport szczegółowy z domeny danego ficzera:



I dalej schodzimy do poziomu pojedynczych user story.

Do szczęścia pozostaje już tylko dopracowanie tekstów w Given, When, Then tak aby ci biedni ludzie zza miedzy wiedzieli o co w tym wszystkim chodzi

Higiena psychologiczna

"Trzymaj się z dala od ludzi, którzy tłamszą twoje marzenia. Mali ludzie zawsze to robią. Jednak naprawdę wielcy sprawiają, że ty także możesz stać się wielki" Mark Twain

O Orle i Kurze

Zanim jeszcze Chiny zasłynęły z produkcji tanich podróbek, wytworzono tam całkiem ciekawy kawałek kultury zawierający następującą opowieść.

„Pewnego dnia (na potrzeby opowieści) do kurnika zostało podrzucone jajo orła. Orzeł wykluł się razem z innymi kurczakami, a że był przekonany, że jest kurą - żył jak kura, jadł jak kura, spał jak kura i myślał jak kura... Bo innego życia nie znał.

I kiedyś podczas jednej z tych kurzych czynności zobaczył na niebie pięknego ptaka, który z majestatem szybował w przestworzach. Z zachwytem wpatrywał się w sylwetkę ptaka i wydawała mu się tak piękna, że nie mógł oderwać od niej wzroku. Zapragnął jak ten ptak na niebie poczuć tę cudowną wolność. Zapytał stojącą obok kurę: co to jest tam na niebie? To jest orzeł, król przestworzy! Ale nie myśl o nim więcej ... Ty nigdy tak nie będziesz latał, jesteś przecież kurą. No tak, jestem tylko kurą - westchnął biedny orzeł.

I już nigdy więcej nie starał się spoglądać w górę. Żył jak kura i umarł jak kura W przekonaniu, że jest to wszystko co życie mogło mu dać ...”

Morał pierwszy :

• Jeśli chcesz aby twój ptak pokazał pełnię swoich możliwości to musisz dbać o swoje jajka

Morał drugi :

• Czy przypadkiem nie jesteś orłem, który po praniu mózgu udaje kurę?

Oczywiście na necie znajdziecie masę różnych tekstów o pozytywnym myśleniu, wierze w swoje siły i o przenoszeniu gór (tak jak za czasów Stalina przy budowie kanału Białomorsko-Bałtyckiego). Tutaj jednak chciałbym ograniczyć pitolenie i zejść na niższy poziom abstrakcji. Jak zwykle przyda się analogia.

Superpozycja neuronów

To co widzimy na obrazku obok nazywa się "Multiplekser". W zależności od tego jakie sygnały podamy na wejścia a to na wyjście y zostanie wypuszczony odpowiedni sygnał x. Analogia :

• sygnały x - nasze świadome zamierzenia
• sygnały a - nasze podświadome przekonania
• sygnały y - wynik naszych działań

Przeprowadzono masę eksperymentów potwierdzających wpływ przekonań na wyniki działań. Potwierdzają to wyniki studentów, którzy po założeniu białego kitla zaczęli "wierzyć", że są kompetentni niczym rasowi naukowcy, czy tez wyniki uczniów, którym wkręcono, że są zdolniejsi od rówieśników.
W praktyce mechanizm działa następująco : Na początek mam plan nauczyć się wygłaszać wystąpienia publiczne. Mój abstrakcyjny umysł wykształca zespół sygnałów (x) będący mieszanką euforii, zamiarów, planów ale także zwątpienia. Jeśli teraz przeszedłem standardowy społeczny proces prania mózgu to zapewne moja psychika jest domem dla wielu kompleksów emocjonalnych wytworzonych przez kapitalistyczny marketing poczucia braku ( o tym za chwilę). Ta mieszanka spowoduje przepuszczenie na wyjście y sygnału o znacznym zabarwieniu zwątpienia co poprzez specyficzne sprzężenie zwrotne będzie sabotować dalsze wysiłki - nie dam rady, nie nadaję się, to nie dla mnie - ewentualnie dalsze racjonalizacje - że do tego trzeba być niskim/wysokim, brzydkim/atrakcyjnym, mieć znajomości itd

Zespół czynników "a" (nasze przekonania) jest więc krytyczny dla ostatecznego sukcesu. Co więc powoduje jego zjebanie?

Od Jaskini do kapitalizmu czyli filozofia braku i wycofania

Można wyróżnić dwie najważniejsze przyczyny braku wiary w siebie: Starożytno-hormopnalną i Nowożytno-emocjonalną

Starożytna-hormonalna zwana także - "uczuciem wstydu" , wykształciła się przez miliony lat ewolucji kiedy to jeden niebezpieczny krok oznaczał śmierć. Czyli jeśli jesteśmy takim standardowym Cześkiem sprzed 50 tys lat to ani nie wypada nam wyskakiwać z inicjatywą bo jak się nie uda to starszyzna nas zajebie. Nie wypada mieć indywidualnych planów bo a nuż ucierpi na tym gromada i starszyzna nas zajebie. Nie wypada ryzykować bo wiadomo, nie uda się i starszyzna nas zajebie. A właściwie to wystarczyło by być wykluczonym z gromady co było zazwyczaj równoznaczne ze śmiercią. ( Ów model działa chyba nadal w niektórych korporacjach). Co już było nie raz powtarzane - niesiemy ze sobą tobół tych wszystkich lat ewolucji a co za tym idzie cały mechanizm kontrolny pod tytułem "nie wychylaj się" potocznie zwany "wstydem" (bo strach to jednak coś jeszcze innego). Jest to rozregulowany mechanizm ograniczający nasze zapędy na wszelki wypadek aby się nie ośmieszyć i nie stracić obecnej pozycji a być może i wylecieć z gromady.
Jednak za oknem nie ma już jaskini...

Za oknem mamy Nowożytno-emocjonalne pranie umysłów. Generalnie aby sprzedać jakiś produkt handlowiec musi pokazać, że ów produkt zaspokaja potrzebę. A co jeśli nie ma potrzeby, którą może zaspokoić? Wtedy taką potrzebę trzeba wymyślić. Zacznijmy od początku. Podobno na rozwój umysłu dziecka wpływ mają już doświadczenia i sygnały, które odbiera w łonie matki - to wtedy kształtuje się baza tego co później będzie zwane gustami. Po urodzeniu tak gdzieś do 8 roku życia podobno dziecko łyka bezkrytycznie wszystko co usłyszy i zobaczy. A co słyszy i widzi? Kazio ma mambę i jest szczęśliwy oraz akceptowany, Jolka ma mambę i jest szczęśliwa i akceptowana, ja nie mam mamby i kurwa stoję smutny jak kołek na tej reklamie dopóty dopóki mamby nie dostanę. Starszy brat Kazia- Rysio, właśnie pierdolnął sobie porcję tablicy Mendelejewa zwaną "zupką instant" i nagle kurde ni stad ni zowąd odwiedza go atrakcyjna sąsiadka o mile brzmiącym imieniu 90-60-90. Podoba się ona Rysiowi bo właśnie jebnęła sobie najnowszą tapetę firmy x, wysmarowała wszystkie zmarszczki najdroższymi maściami i w ogóle czuje się zajebiście bo łyka super tabletki na odchudzanie za jedyne 199 ( które maja w składzie głównie błonnik pokarmowy jak taka kalarepa za 1,99). Ale i tak z tego spotkania by nic nie wyszło gdyby Rysio nie zapodał wcześniej gumy do żucia, która sprawiła, że teraz napierdala chuchami nowe ślizgawki na przystanku. A w międzyczasie w mieszkaniu obok idealna rodzina z uśmiechniętym psem i wesołym kotem napierdala sobie jak niby nic najnowszą super margarynę (bezwartościowy tłuszcz przemysłowy).

Jak teraz ta biedna podświadomość ma nam pomagać gdy non stop dostaje sygnał, że jesteśmy pod każdym względem wybrakowani?

Higiena psychiczna i zarządzanie ryzykiem

Tutaj chciałem napisać, że o psychikę trzeba dbać tak jak dba się o zdrowie organizmu ale kurwa jednak mało kto dba o zdrowie organizmu :(. Z drugiej strony chyba jednak zęby wszyscy myją - może nie po każdy posiłku ale przynajmniej raz wieczorem. Podobnie musimy stworzyć sobie taką szczoteczkę, która zmyje cały ten syf i brud codziennie osiadający na psychice.

1. Podstawą będą techniki medytacyjne oraz wszelkie ćwiczenia, które można znaleźć pod (być może) źle rozumiana dziedziną zwaną NLP.
2. Najnowsze odkrycia naukowców (nie pamiętam już których) mówią, że nasz układ jelitowy posiada swój własny, raczej prymitywny układ nerwowy(!). Określenie "jesteś tym co jesz" nabiera teraz nowego wymiaru. Warto zainteresować się tym jak działają nasze organizmy i co na nie wpływa
3. Jak już hardware jest ogarnięty to czas na soft. Generalnie warto znać choćby podstawy budowy mózgu i działania psychiki. Był sobie kiedyś taki eksperyment, w którym udowodniono, że jeśli nieświadomy czynnik ulegnie uświadomieniu to nie wpływa już tak bardzo na nasze zachowanie - "zanim zaczniemy niech pan mi powie jaka pogoda jest za oknem..."
4. Generalnie większość manipulacji z jakimi się spotykamy pochodzi z książki Cialdiniego albo jakichś koślawych poradników handlowych. Wystarczy przeczytać kilka lektur by mieć całkiem solidną obronę przed technikami w stylu "nasza oferta jest ważna tylko do końca tygodnia (kolejna oferta ważna do końca tygodnia już w następnym tygodniu)

Do tego dochodzi jednak inteligentne zarządzanie ryzykiem. Jeśli będziemy największymi optymistami jakich ta planeta widziała to i tak po skoku z wieżowca spotka nas to samo co zagorzałych pesymistów. Generalnie funkcjonując w społeczeństwie warto poczytać jakie są podstawy działania tego społeczeństwa i jakie normy jednak (niezależnie od wiary w siebie) muszą być brane pod uwagę.

"A co jeśli nie urodziłem się z danym talentem?"

Wtedy polecam książkę "Poza schematem" Malcolma Gladwella. Nie licząc specyficznych przypadków kiedy to genetyka może trochę wpływać na sukcesy sportowe to jednak wspomniana książka tłumaczy dlaczego w reprezentacji Kanady grają głównie ludzie urodzeni w miesiącach styczeń-marzec, dlaczego Bill Gates byłby zwykłym szaraczkiem gdyby urodził się 5 lat wcześniej czy później, oraz masa innych przypadków, która raz na zawsze zmiecie mit o "talencie wrodzonym".

Management 3.0 w metaforze turystycznej

For every complex problem there is an answer that is clear, simple, and wrong.

H.L. Mencken, journalist, writer (1880–1956)

Gdyby dwa lata temu ktoś powiedział mi, że napiszę dzisiejszy tekst, to najprawdopodobniej odpowiedziałbym mu gromkim śmiechem (albo rozjebał butelkę na głowie bo wtedy dosyć dużo piłem). Otóż dwa lata temu, po kilkuletnim obcowaniu z upośledzonymi firmami jadącymi mieszanką wodospado-biurokracji, wszystko co kojarzyło mi się z Metodykami Zwinnymi było niczym głos mędrca w ciemności, śpiew skowronka po koncercie ich troje czy zapach oazy wśród pustynnych piasków. Dwa lata później okazało się, że korporacja jest w stanie zjebać nawet i to :(. Ale od początku...

Na początku był debilizm

Z czytanek, które w ostatnich latach przeleciały mi przez ręce wnioskuję, że wszystko zaczęło się w XIX wieku, kiedy to masa analfabetów pozbawionych zdolności analitycznych przyjechała za chlebem do wielkich miejskich fabryk. Poprzednie zdanie nie ma na celu deprecjacji czy ośmieszania grup społecznych ale proste stwierdzenie faktu. Czego by nie mówić o dzisiejszym szkolnictwie to 150 lat temu sytuacja była o wiele tragiczniejsza. Właściciele fabryk (czy też ktoś z ich otoczenia)zauważyli, iż owi szeregowi pracownicy nie kwapią się zbytnio do optymalizowania procesu wytwórczego (wtedy jeszcze nauka nie odkryła, że napierdalanie przy taśmie po 15 godzin 7 dni w tygodniu nie sprzyja auto-motywacji). Dlatego też cały proces był nadzorowany przez inżynierów (TAK TAK! Inżynierów a nie managerów!) . Później pojawia się Tayloryzm z całym gównem w tle, procesy stają się coraz bardziej skomplikowane i pojawia się potrzeba kogoś kto jest w stanie nadzorować nie tylko pracę przy maszynach ale abstrakcyjne procesy tworzone na papierze - tak rodzi się "management". W międzyczasie wszyscy na około zaczynają się napie*dalać co przyśpiesza rozwój maszyn liczących...

Później był trochę inny debilizm

Wielu pseudo-geniuszy na forach internetowych powie wam, że programista jest jak murarz. Powinien siedzieć cicho i skromnie napie*dalać co mu architekt przyśle (Tym panom oczywiście dedykujemy nowo niepowstały odcinek autostrady A2). Generalnie tak samo pomyśleli sobie pewni ludzie w połowie poprzedniego wieku. Jeśli jeden zasób typu programista tworzy dziennie 5000 linii to dwóch chyba stworzy 10000 no nie?! To teraz tylko oszacujmy ile linii ma dana funkcjonalności, ile mamy (kurwa) zasobów ludzkich, podzielmy i wio. Czas na metaforę! Zerknijmy dlaczego poniższy obrazek jest bez sensu.

Powiem wam dlaczego jest bez sensu (w kontekście naszej metafory) . Byłem w tamtym miejscu niecałe dwa tygodnie temu i ani po 3 godzinach ani do tej pory do Chęcin nie doszedłem... W ogóle co to jest to 2h 50? Szybkość z jaką przejdzie dziecko, dorosły czy emeryt? Poszukałem na necie i jest jakiś sztywny algorytm liczenia tych czasów, ale przy okazji znalazłem takie oto opinie :

" Fakt, ze czasy na drogowskazach po polskiej stronie Tatr sa chyba podawane dla emerytow niosacych 30kg plecaki i robiacych co 100m przerwy na podziwianie widoków :D "

" Inna sprawa, że już od dawna nie sugeruję siê czasami z przewodników czy drogowskazów, bo z nabytego doświadczenia dość łatwo przychodzi mi oszacowanie czy dana trasa jest możliwa (w normalnym tempie) do przejścia w ciągu dnia czy nie. "

Teraz jak to wszystko ma się do IT? Otóż niestety do tej pory istnieją firmy gdzie panuje tzw. Filozofia "Command and control". W tychże firmach tzw. Architekci i Managerowie szacują ile co ma trwać a później zrzucają na daną funkcjonalność ze spadochronem developerów. No niestety. Drogowskaz (architekt) mówił 2,5 godziny a tu się niestety okazało, że po pierwsze to ów developer za cholerę nie pokonuje odcinków drogi w obliczonym czasie to jeszcze zerwała się burza, trzeba było zmienić szlak i wracać do schroniska. Eh gdyby ci turyści byli jak murarze to wszystko by działało zajebiście...

Debilizm 2.0

Teraz zerknijmy na inny obrazek

Powyższe drogowskazy i wtedy i w tej chwili są w zasadzie poprawne. Bez względu na to jak szybko idę, jaka jest pogoda, co jadłem na śniadanie, jaki mam humor i co było wczoraj w telewizji to odległość z miejsca na obrazku do rezerwatu białogon wynosi około 4,4 km. Koncepcja z pozoru jest super zajebista. Mamy jakąś miarę odległości i teraz od indywidualnego przypadku zależy jak szybko zostanie ta odległość pokonana. Dla nieuważnych jest to nawiązanie do koncepcji prędkości ("velocity") w metodykach zwinnych.

Widzimy tutaj zdecydowany postęp - nie strzelamy już z dupy, że coś będzie skończone według jakichś dziwnych uśrednień i wróżb ale staramy się na podstawie obserwacji stwierdzić jaka jest prędkość developera i wtedy już faktycznie oszacować kiedy przejdzie on daną ilość kilometrów. A ponieważ w projektach IT nie ma kilometrów to używamy punktów funkcyjnych zaś "odległości" są mierzone przez jedynych ludzi, którzy wiedzą po czym stąpają czyli przez zespół. I właśnie 2 lata temu ta teoria wydawała się logiczna, zupełna i całkowita. Dzisiaj zaś...

Wyobraźmy sobie, że liczymy ile jako turysta jestem w stanie pokonać kilometrów w przeciągu dwóch tygodni (jeden sprint). Pierwszego dnia wyszedłem na świeżo, była ładna pogoda to pyknąłem około 20 km, następnego dnia pojawiły się odciski to już tylko 15 , trzeciego dnia musiałem ograniczyć się do wycieczki po mieście. Teraz teoria mówi, że pomimo tych różnic jeśli weźmie się kilka takich odcinków dwutygodniowych to jakoś auto-magicznie wszystko się ustabilizuje. Teraz jednak zamieńmy naszego turystę w turysto-komandosa (co bardziej przypomina realizm projektów IT), który jest co chwila rzucany po całym świecie. W trakcie pierwszego sprintu udało się przejść 150 kilometrów , i teraz nasz komandos jest przerzucony w tatry. Tutaj wspomniane 4,4 km niestety pokonuje się w 3 razy dłuższym czasie bo po skałach. Po dwóch tygodniach wracamy w góry świętokrzyskie.Ale tutaj widzimy, że zerwała się burza i w głębokim błocie wcześniej znany odcinek pokonaliśmy w 2 razy dłuższym czasie.

Oczywiście można dalej mnożyć przykłady jak nasz turystyczny komandos został wysłany Himalaje i nawet z samolotu (planning) odcinek wydawał się być krótki ale po wylądowaniu (napierdalanie) okazało się, że nie ma tlenu (wymagań) i ogólnie trzeba czekać. Dalej dla zabawy możemy pomnożyć listę turystów przez 10 , zróżnicować ich kulturowo i dorzucić wycieczki morskie. W tym momencie zostaje nam już tylko myślenie magiczne, że wszystko nam się "jakoś uśredni".

Teraz metafora staje się coraz trudniejsza bo dochodzimy do...

Korpodebilizm

Na początek pytanie retoryczne (nie wymagające ku*wa odpowiedzi) co dzieje się gdy zespół jest oceniany na podstawie ilość procentowej pokrycia kodu? ("o ten ma 100% to są profesjonaliści", " ten tylko 50% to tacy pół spece"). Zespół oczywiście znajdzie sposób aby zmaksymalizować ową metrykę ale cały proces niewiele będzie już miał wspólnego z pierwotnym założeniem. Dla przypomnienia - jeśli tworzymy poprawne testy jednostkowe to pokrycie kodu daje nam jako taką informacje o tym czy czegoś nie przeoczyliśmy. Jeśli mamy zaś mieć 100% pokrycia to jest kilka sztuczek aby to osiągnąć - na przykład testy bez asercji.
Podobnie jeśli jesteśmy oceniani według przewidywalnej ilości linii kodu to jeśli wyjdzie nam za mało danego dnia to robimy if(false) i tutaj jest miejsce na brakujące linie. Jeśli zaś wypełnimy normę do czternastej w sposób normalny to cóż sprawdzimy co tam słychać na onecie.

Dlaczego z velocity ma być inaczej? (znowu pytanie retoryczne). Jeśli profesjonalizm naszego turysty jest oceniany według tego czy może on tak zaplanować sobie wędrówkę aby w okresie dwutygodniowym pokonywać te same odcinki to jasne, że znajdzie sposób aby coś takiego zasymulować! Najlepiej wtedy obiecać , że przejdziemy drogę od domu do monopolowego i z powrotem. Oczywiście większym "profesjonalizmem" wykaże, się zespół donoszący cyklicznie tą samą drogą węgiel ze wsi A do wsi B niż zespół który zrzucono nad dziką dżunglą w Ameryce Południowej. Niestety obserwacje to potwierdzają gdyż na własne oczy widziałem jak priorytetem staje się takie wpisanie wartości do JIRY aby wykresy przecięły się w odpowiednim miejscu...

Jeśli nie velocity to co?

Na początku duże nadzieję wiązałem ze słabo jeszcze przeze mnie poznanym kanbanem ale w ostatnich dniach w ręce wpadła mi książka, która być może będzie przełomem

"Management 3.0 = Complexity The last few decades saw the birth and rise of complexity theory, first ap- plied to mathematics and biology and later to economics and sociology. It was a major breakthrough. Stephen Hawking thought it was so important that he called the 21st century the “century of complexity.“"

"Many of us already knew that “leadership” is just a trendy name for managers doing the right thing and doing things right. But complex- ity thinking adds a new dimension to our existing vocabulary. It makes us realize that we should see our organizations as living systems, not as machines."

Książkę zacząłem dopiero czytać ale już poruszyła tematy ,które mnie zdobyły. Zobaczymy co przyniesie dalsza lektura, być może pojawią się rzeczy , które przeczą dzisiejszemu tekstowi ;) W każdym razie to co mi się podoba to to, że propaguje ona podejście kompletne, zobaczmy :

• Na początku mamy kompletnie upośledzony sposób szacowania w ogóle pomijający jakikolwiek ludzki pierwiastek w projekcie
• Później wkracza agile i zespół developerski zostaje obdarowany należną mu rangą. Szacowanie nie bierze się już z dupy ale jego zbytnie uproszczenie (zwłaszcza w środowisku korporacyjnym) może prowadzić do wypaczeń
• Rozwiązanie kompleksowe ogarniające wpływ wielu czynników z należytym naciskiem na "człowieczeństwo" ludzi wykonujących pracę

Co może wpływać na pracę?

Masa czynników! Koncepcja Velocity zakłada, że developer ( w odróżnieniu od takiego Kmicica) jest bohaterem raczej statycznym - ewentualnie wszystko jakoś samo magicznie się uśredni. Ze swojego przykładu mogę powiedzieć, że jakiś czas temu miałem okres relatywnej hiperproduktywności kiedy to udało mi się zaimplementować ładny kawałek pojebanej logiki biznesowej. Oczywiście owa hiperproduktywność nie wytworzyła się sama. Była to mieszanka wiedzy psychologicznej, którą zdobywam od 15 lat ( kotwice , praca z submodalnościami czy techniki oddechowo-medytacyjne) ale także dużą rolę odegrała suplementacja! Otóż na przełomie lutego i marca jadłem t100 od olimpu (wśród skłądników resveratrol, różaniec górski, DAA) do tego ZMA (cynk,magnez B6) co podbiło testosteron chyba do granic naturalnych możliwości. Zaowocowało to niesamowitą energią i minimalnymi skokami agresji co skutecznie pozwoliło mi realizować odmianę techniki "pomodoro" - obrony przed przeszkadzaniem ( mówimy wtedy "pomidor" albo po prostu "wypierdalaj"). Do tego od początku stycznia do końca marca nie wypiłem nawet kropli alkoholu i dorzuciłem dodatkowe antyosydanty. Mogłem generalnie rozjebać dowolną funkcjonalność.

Oczywiście to tylko mój mały wycinek rzeczywistości. Nie jest tajemnicą stwierdzenie, że każdy chce czuć siłę swojego wpływu na rzeczywistość. Co by się stało gdyby w okresie gdy napierdalałem wyżej wspomniane suple manager postawił w kuchni miskę z jabłkami? Otóż pewnie bym się poczęstował bo jabłka generalnie lubię i owy manager mógłby z całej sytuacji wyciągnąć wniosek, że zajebiście motywują mnie właśnie jabłka. W teorii złożoności (przynajmniej w moim rozumieniu) nie ma miejsca na takie deklaracje. Nie możemy powiedzieć "coś zadziałało", poprawnym stwierdzeniem jest "po dodaniu jednego elementu cały skomplikowany kompleks oddziaływań zachował się tak a tak"

Jak skończę czytać książkę napiszę coś więcej

Umysł emocjonalny

Pierwszy obraz jaki widzisz w swojej głowie po usłyszeniu słów uczucia i emocje to obraz scalonego z klawiaturą programisty, który wykorzystuje odziedziczony i rozwijany od setek milionów lat mechanizm umysłowy aby stworzyć doskonały kod.

Nie. Widzisz zapewne coś przeciwnego : dynamiczne obrazy przedstawiające fascynujące przeżycia i wyraźne wspomnienia ekstremalnych momentów z twojego (lub cudzego) życia. Treść raczej rzadko kiedy ma cokolwiek wspólnego z programowaniem a raczej czerpie garściami z tematów nazywanych powszechnie "czysto ludzkimi".

Nie musi tak być...

Ukryta moc obliczeniowa

Eksperyment przebiegał następująco:

• Każdy z uczestników wybiera kartę z jednej z czterech kupek ("kupka" to chyba odpowiednie słowo)
• Każda wybrana karta to punkty dodatnie lub ujemne
• Jedyne informacje dostarczone uczestnikom mówią, że pewne kupki są "lepsze" od innych
• Faktycznie kupki zostały tak przygotowane, że dwie z nich w okresie długofalowym przynosiły więcej strat niż zysku
• Kolejność kart została tak przygotowana aby rozpoznanie "natury kupki" było w zasadzie niemożliwe (Odpowiednie programy komputerowe już o to zadbały).
• Przez cały czas trwania eksperymentu naukowcy monitorowali "odpowiedź czuciową" uczestników mierząc przewodność ich skóry (na podstawie założenia, iż przeżywając emocje ludzie (a dokładnie ich skóra) mają tendencję do wydzielania potu, który to zmniejsza opór elektryczny)

Wnioski

Po pewnym czasie trwania eksperymentu naukowcy zauważyli, że organizmy badanych niejako przygotowują się do odparcia ataku zaraz przed tym jak mieli wyciągnąć kartę ze "złej" kupki. (Dokładnie stwierdzono to na podstawie znacznego skoku przewodności skóry). Możemy z tej obserwacji wyciągnąć wniosek, że my - ludzie - a w zasadzie nasze umysły, są w stanie wykonywać niesamowicie skomplikowane obliczenia, których wyniki otrzymujemy w postaci działania czegoś co możemy nazwać INTUICJĄ lub INSTYNKTEM.

Wymagający czytelnik mógłby zauważyć, że powyższe wnioski być może zostały wyciągnięte zbyt pochopnie. Cóż, wspomniany eksperyment powtórzono i to powtórzono nie na byle kim. Na co dzień naukowcy zajmujący się neurobiologią muszą się "ograniczać" do eksperymentów na szczurach,świnkach morskich i amerykańskich studentach. Jednakże od czasu do czasu ktoś sobie coś uszkodzi i staje się tak długo oczekiwanym rekwizytem badawczym. Na scenę wchodzi...

Pacjent EVR

Pod tym pseudonimem kryje się nieszczęśliwa historia człowieka, któremu z powodu zmian rakotwórczych usunięto fragmentu kory czołowej (a konkretnie przedczołowy płat środkowy - czy coś takiego). Zaraz po operacji praktycznie każdy aspekt życia pacjenta EVR zaczął się rozpadać ze względu na niemożliwość dokonania szybkich wyborów. Każda decyzja - czy to zakup warzywa czy wybranie miejsca posiłku, musiała być poprzedzona najdrobniejszą analizą każdego detalu. Co i tak nie uratowało go przed utopieniem wszystkich swoich oszczędności w trefnych inwestycjach. Za straconą kasą poszła stracona miłość żony i w końcu pacjent EVR znalazł się w szpitalu

W szpitalu Został on poddany szczegółowym badaniom, które stwierdziły, że z punktu widzenia logiki nasz pacjent funkcjonuje znakomicie. Jednakże w trakcie badań badacze zauważyli coś dziwnego - bez względu na tematykę pytań i badań pacjent EVR przez cały czas wydawał się być pusty emocjonalnie. I faktycznie. Gdy przeprowadzono na nim eksperyment z kartami odczyty przewodności skóry (czyli "miernik odczuwania") nic nie wykazywały. Pacjent przez cały czas dokonywał błędnych wyborów przegrywając grę.

I ostatnia ciekawostka. Okazało się, inne osoby ze schorzeniami podobnymi do EVR potrafiły w pewnym stopniu przewidzieć logicznie, która kupka kart jest niebezpieczna ale ta wiedza nie wpłynęła absolutnie na ich decyzje!

Co z tego wynika dla informatyka

No, odpowiedź na to pytanie powinna być raczej oczywista. Jak by było zajebiście gdyby swędzenie lewego kciuka dało ci znać, że właśnie wprowadzasz poważnego buga do aplikacji? Ja sobie doskonale zdaje sprawę, że na świecie jest pełno innego typu "pacjentów", którym wydaje się, że można przeprowadzić gigantyczną analizę, wszystko zaplanować na 20 lat w przód a później wyniki tej analizy dać grupie "kodujących małpek". Złudzeniom i omamom poświecimy osobny odcinek. Dzisiaj skupmy się na rzeczywistości, w której to programista co chwila musi podejmować decyzje oddziałujące na niezwykle skomplikowane środowisko złożone z masy wymagań funkcjonalnych i multum zależności technicznych . W takich warunkach jest totalnym bezsensem oczekiwać, że nasz świadomy mechanizm umysłowy zapamięta i rozpracuje każdy problem, który ujrzy na swej drodze. Jeśli istnieje dodatkowa moc obliczeniowa to dlaczego jej nie użyć?

Jeśli ktoś czytał tego bloga od początku to pewnie wie, że ta cała "dodatkowa moc obliczeniowa" nie jest jakimś magicznym wynalazkiem. O tym czym jest umysł świadomy a czym nieświadomy można przeczytać choćby tutaj --> Model umysłu. Prawie, że pod naszym nosem, za zasłoną myślenia abstrakcyjnego działa prawdziwy "rozpierdalacz informacji", który interpretuje otaczającą cię rzeczywistość (Tak czy inaczej te przerobione informacje wpłyną na nasze decyzje, które później będziemy sobie racjonalizować). I tutaj pojawia się moment w którym ten cały mechanizm można użyć na naszą korzyść.

Generalnie ta nasza podświadoma maszynka łyka wszystko to co dostanie : nie ważne czy informacje dociera do mózgu przez oczy,uszy,dotyk czy też zostaje w nim bezpośrednio wytworzona . Dokładnie! Z tego co wiem sportowcy od dawna ćwiczą swój instynkt poprzez przeróżne wizualizacje.W zakresie tej tematyki pojawiło się wiele technik o różnym stopniu powodzenia. Temat rozwinę w następnych odcinkach jakkolwiek na dzień dzisiejszy kto chce może sobie poszukać informacji w necie lub zerknąć do książki :

Testy dla ludzi

Post zaczniemy od części multimedialnej - 29.03 na łódzkim JUGu miała miejsce prezentacja wykonana przez skromnego spikera w mojej jeszcze skromniejszej osobie. Głównym tematem były testy mutacyjne, o których wspomnę kiedy indziej. Dzisiaj będzie za to trochę herezji, ale najpierw seans.

Po co są zasady...

W niemal każdej książce, na niemal każdym blogu i chyba w każdym artykule poświęconym inżynierii obiektowej pojawia się zasada znana jako DRY - "Don't Repeat Yourself". Zasada jest dobra - nawet bardzo dobra - podobnie jak zasada jazdy prawym pasem. Przestrzeganie jej będzie ratować nam życie dopóki nie wyjedziemy zarabiać w Anglii na zmywaku - wtedy przestrzeganie jej może nas zabić...

Jedziemy na razie prawym pasem. Poniższy obrazek przypomni klasyczne zyski zastosowania zasady DRY. Wyobraźmy sobie, że to kawałek kodu sterującego robotem przemysłowym. Powyżej sexownej czerwonej kreski mamy powtarzający się kod, który nie wiele nam mówi. Stosujemy zasadę DRY - i BUM - poniżej czerwonej kreseczki widzimy, że tzw. "ektrakcja metody" nie dość, że usunęła nam powtórzenie to jeszcze wprowadziła aspekt samo-dokumentacji kodu.

Teraz czas zjechać na pas przeciwległy.

Jak najlepiej czytać dokumentację ?

Jak wyglądałaby idealna dokumentacja według zasady DRY? Poniżej chyba nic się nie powtarza a poszczególne koncepcje są wyciągnięte do osobnych punktów i paragrafów.

Teraz następuje krytyczny moment, gdyż aby zrozumieć konsekwencje takiego zapisu trzeba wysilić swoją wyobraźnie i zdolności empatyczne. W chwili obecnej czytelnik być może siedzi wygodnie w fotelu popijając kawę lub browara i pełen relaksu zerka na załączone fotografie zastanawiając się "co w tym takiego trudnego?"

Jak to mawiają trenerzy NLP : "czy masz na tyle odwagi aby wyobrazić sobie, że siedzisz po 6 godzinnym maratonie kodowania ( w firmach nastawionych na 'napierdalanie' gdzie przerwa obiadowa jest około godziny siedemnastej należy liczbę 6 zamienić na 13) , gonią cię terminy, manager non stop rozprasza pytaniami na kiedy TO będzie, a w domu chyba zostawiłeś włączone żelazko ale na szczęście nie będzie pożaru bo chyba nie zakręciłeś też wody"

I teraz za przeproszeniem ku*wa należy rozpocząć dyskusję czy taki biedny programista będzie mieć siłę skakać pomiędzy klasami czy co gorsza analizować konfiguracje w xmlach aby rozwikłać zagadkę dlaczego dany test nie działa? (pytanie jest retoryczne). Czy wygodniej nam czytać dokumentację na screenie powyżej czy też może skłonimy się ku propozycji zamieszczonej poniżej.

Pisałem już w poście : wyczerpywanie się energii psychicznej , o tym jak nasza siła psychiczna męczy się od "noszenia" cięższych i bardziej skomplikowanych koncepcji. Dokumentację na drugim slajdzie na pewno łatwiej się czyta ale powstaje pytanie : co gdy chcemy ją zmienić. w przypadku dokumentacji papierowej nie jest wtedy trudno o pomyłkę czy przeoczenie ALE... W przypadku dokumentacji w postaci testów sytuacja się obraca moim zdaniem o 180 stopni gdyż jeśli testy są napisane poprawnie to każde miejsce, które nie nadążyło za aplikacją zgłosi błąd. I teraz oczywiście musimy się do każdego takiego fragmentu z osobna udać aby go naprawić i chyba jest to najlepsza metoda aby upewnić się, że nasza zmiana nie wprowadziła skutków ubocznych.

Oczywiście są pewne granice w ramach których powyższe rozumowanie jest poprawne. Te granicę są określone przez minimalny poziom abstrakcji potrzebny do zrozumienia instrukcji. Dla jasności poniższy przykład pokazuje już przekombinowaną dokumentację :

No to jak nie DRY to co?

Tak jak pisałem na początku tego wywodu - metody DRY nie należy (według mnie) traktować jako jakiegoś świętego prawa, którego nieprzestrzeganie sprowadzi na nas apokalipsę (21 grudnia 2012) ale jako zwykłą zasadę. Co ciekawe wystarczy rozejrzeć się dookoła aby zobaczyć jak łamanie tej zasady ratuje nam codziennie życie. Z tego co mi wiadomo nasz organizm przechowuje wzorzec DNA w wielu kopiach dzięki czemu jeden mały wirusik nie jest w stanie jednym pyknięciem zamienić nas w jednego wielkiego raka.

Jak więc może nazywać się zasada przeciwna do DRY?

Przykład z pracy

Na ostatnim już obrazku w tym odcinku widzimy przykład cennika. Generalnie działa to tak, że jak kupi się odpowiednią ilość geokodowań (geokodowanie to w skrócie zapytanie o miejsce na ziemi ) to skaczemy do następnego poziomu z niższymi cenami. Według zasady DRY powinniśmy mieć jeden zestaw danych i jeden mechanizm tworzenia tych danych. Jednakże ze względu na lepszy obrazek zastosujmy zasadę WET co zaowocuje stworzeniem trzech odrębnych zestawów danych. I teraz :

• Funkcjonalność szukania poziomów w ogóle nie potrzebuje żadnych cen. Wywalamy ceny i dzięki temu jak przestanie nam działać test to mamy mniej rzeczy do analizy
• Funkcjonalność liczenia kasy musi mieć wszelkie nieprzyjemne i brzegowe wartości coby w czasach kryzysu żaden miedziak się nie zawieruszył. Ten zestaw danych jest najbardziej rozbudowany.
• Tutaj mamy zestaw pośredni. Musimy się upewnić, że da się edytować co trzeba edytować ale już nie musimy 1500 różnych przypadków rozważać jak przy liczeniu kasy.

Podsumowanie

Oczywiście należy pamiętać, że wnioski którymi się tutaj dzielę, zostały zebrane na podstawie obserwacji ograniczonej grupy ludzi a czasem nawet wyłącznie na podstawie auto-psychoanalizy. Generalnie zauważyliśmy (ja i koledzy w pracy), że im więcej musimy się napocić przy czytaniu testu tym bardziej podświadomość traktuje go jako zbędny wydatek energetyczny. Coraz bardziej jestem przekonany, że pisanie testów należy zaklasyfikować do kategorii wyzwań "odroczonej gratyfikacji". Do tej pory wydawało mi się, że taki działający test stanowi gratyfikację sam w sobie jednakże ostatnie analizy skłaniają mnie do zakwestionowania tego wniosku - ale to już w innym odcinku.

Główny wniosek jest taki aby wszelkie niezbędne dane do zrozumienia testu były w zasięgu klasy testowej - żadne metody statyczne, żadne springi czy inne konfiguracje zewnętrzne mocków. Raz, że będzie łatwiej ten test zrozumieć, a dwa że można potem te lokalne ustawienia zoptymalizować aby test był jeszcze łatwiejszy do zrozumienia.

I tutaj mały wyjątek odnoszący się do akapitu mówiącego o minimalnym poziomie abstrakcji pisanej dokumentacji. (akapit nad pustynią). Generalnie rozwalanie hashmapy na drobne aby sprawdzić czy jakieś tam struktury mają inne struktury niekoniecznie sprzyja czytelności testu. Tutaj lepiej użyć Hamcresta albo FESTa. Doświadczenie wykazało, że jak już się dobrze napisze " maczera" to zazwyczaj nie trzeba już do niego zaglądać.

"Teoria mostów" czyli dlaczego programiści mylą testy jednostkowe z integracyjnymi

Na początek quiz : po jakim czasie programiści zaczynają z coraz większą częstością stosować dobrze znane polecenie?

-Dmaven.test.skip=true

Prowadząc osobiste obserwacje zauważyłem, że jednym z czynników jaki ma wpływ na ów niechlubny krok jest czas wykonania się testów jednostkowych. Jeśli do kogoś bardziej przemawiają zapisy ścisłe to można powyższe stwierdzenie ująć TAK:

P(s)~Tc

gdzie:

• P(s) - prawdopodobieństwo przeskoczenia kroku testów
• Tc - czas wykonania się testów

lub TAK:

f(s)~Tc

gdzie:

• f(s) - częstotliwość olewania testów
• Tc - czas wykonania się testów

Wniosek jest oczywisty : wśród rzeczy które w naszym codziennym życiu chcemy sobie wydłużać nie powinno być testów jednostkowych!

Dlaczego programiści mylą testy jednostkowe z integracyjnymi

Oczywiście nie wszyscy programiści i na pewno nie ci którzy czytają tego bloga. Niestety świat zewnętrzny jest bezlitosny i nie raz widziałem jak coś co było w danej firmie nazywane "testami jednostkowymi" stawiało cały serwer aplikacji. Źródeł podobnych kroków dopatruję się w fakcie, iż tak naprawdę nie ma (niestety) ścisłej definicji testu jednostkowego. No i różni ludzie różnie rozumieją ową "jednostkę".

Zamiast ścisłej definicji zafundujmy sobie wolne i pozbawione ciśnień rozważania przy pomocy

prostego przykładu (z użyciem pseudo kodu)

 
 int countLines(pathToFile){
    File fileWithContent=new File(pathToFile);  
    String content=readContent( fileWithContent)  
    return countLines(content) 
 } 

Powyższy kod przedstawia kawałek logiki zliczającej ilość linii w pliku. Stworzenie testu jednostkowego dla tego kawałka kodu wydaje się proste.Niechże wygląda on tak:

 //given  
 pathToTestFile="..."  
 //when  
 int result=linesCounter.countLines(pathToTestFile)  
 //then  
 assertThat(result, is(tyleATyle))  

Dlaczego to nie jest test jednostkowy?

Aby odpowiedzieć na to pytanie wystarczy w dowolny sposób popsuć plik testowy. I tutaj niestety jest miejsce na filozoficzne dywagacje czy plik jest częścią testowanej jednostki czy też nie. Według mnie nie jest. Jako jednostkę rozumiem logikę znajdującą się w kontekście testowanego kawałka kodu. Usuwając plik testowy nie zmieniamy nic w samym komponencie ani w naszym teście a jednak jesteśmy w stanie zmienić kolor paska rezultatu w JUnicie. Moim zdaniem można śmiało powiedzieć, że nasz test poza liczeniem linii testuje integrację z systemem plików!

Mosty i "Kontektory"

Idea przedstawiona na rysunku jest chyba oczywista. Do każdego zewnętrznego systemu odwołujemy się poprzez specjalny zbiór łączników zwanych z angielska "connectorami" (chciałbym dożyć chwili gdy będąc w samym centrum tego pięknego kraju będę mógł ochoczo nazwać sobie klasę FileSystemŁącznik). Na początku używałem jednego kontektora dla jednego systemu ale skutkowało to rozrostem jednej ogromnej klasy. Najnowsza teoria grupuje kontektory w mosty.

Jak to może wyglądać w praktyce

Widok od strony pakietów

i przykładowy kod źródłowy

 public class TextResourcesConnector {  
      public String readTextResourceContent(String resourceName) {  
           InputSupplier<InputStream> contentSupplier = newInputStreamSupplier(getResource(resourceName));  
           return readContent(contentSupplier);  
      }  
      public String readTextFromFile(File file){  
           InputSupplier<? extends InputStream> contentSupplier =Files.newInputStreamSupplier(file);  
           return readContent(contentSupplier);  
      }  
      public String readTextFromFile(String filePath){  
           return readTextFromFile(new File(filePath));  
      }  
      private String readContent(InputSupplier<? extends InputStream> contentSupplier) {  
           try {  
                return CharStreams.toString(newReaderSupplier(contentSupplier, Charsets.UTF_8));  
           } catch (IOException e) {  
                throw new RuntimeException(e);  
           }  
      }  
 }  

Powyższy kod przedstawia wersję jednego z kontektorów w kształcie odpowiednim na chwilę obecną (co bardziej spotrzegawczy zauważą wykorzystanie Guavy). Koncepcja ewoluuje, więc nie wykluczone, że w przyszłość całość będzie wyglądać inaczej. Kod naszego "zliczacza linii" wyglądałby teraz następująco

 
 int countLines(pathToFile){ 
    String content=textResourcesConnector.readContent( fileWithContent)  
    return countLines(content) 
 } 

Zaś test :

 

 before(){
   textResourcesConnector=mock()
   linesCounter.wstrzyknijTakLubInaczej(textResourcesConnector)
 }

 (...)

 //given  
 pathToTestFile="..."
 content="..."
 given(textResourcesConnector.readContent(pathToTestFile)).willReturn(content);
 //when  
 int result=linesCounter.countLines(pathToTestFile)  
 //then  
 assertThat(result, is(tyleATyle))  

Test co prawda nam się powiększył objętościowy ale to dlatego, że teraz mamy pełną kontrolę nad tym co dzieje się na granicy systemu i z kontroli tej (a jakże) korzystamy. Oczywiście testowanie samych kontektorów to osobna sprawa - tutaj raczej przed testem integracyjnym się nie ucieknie.ALE!

Akapit-wniosek artykułu

Testy integracyjne poza tym, że są mniej przewidywalne to zazwyczaj trwają dłużej z powodu komunikacji dwóch systemów. Także aby ludzie nie "skipowali" testów to te integracyjne powinny być uruchamiane osobno od jednostkowych. W tej chwili osobiście używam mechanizmu Springowego

@IfProfileValue(name="test.type", value="integration")

Dzięki czemu owe testy integracyjne nie będą się uruchamiały razem z jednostkowymi. (Podobno maven 3 ma jakaś osobną fazę poświęconą testom integracyjnym ale ja jeszcze tego nie znaju.) Teraz gdy już mamy naszą annotację nad testami integracyjnymi to możemy stworzyć osobny job w jenkinsie, który raz na jakiś czas będzie je uruchamiał a programiści mogą radośnie delektować się (relatywnie) szybkim wykonaniem instukcji mvn clean install.

Ps. Do testowania operacji na systemie plików polecam w miarę młody mechanizm w JUnit

@Rule
public TemporaryFolder tmpFolder = new TemporaryFolder();

Umysł próżny

"Failure is perhaps the greates enemy of the Ego"

Z raportów policyjnych

• "Facet był na całej drodze i wiele razy próbowałem go wyminąć zanim uderzyłem w niego"
• "Wracając do domu podjechałem do złego domu i zderzyłem się z drzewem którego nie mam."
• "Przechodzień uderzył we mnie i przeszedł pod moim samochodem."
• "Ten pan jest bezstronnym świadkiem na moją korzyść."
  
• "Budka telefoniczna zbliżała się, kiedy próbowałem zjechać jej z drogi uderzyła w mój przód."
  
• "Zatrąbiłam na pieszego, ale on tylko się na mnie gapił, więc go przejechałam."
  
• "W pewnym momencie drzewo dostało się między kabinę ciężarówki i przyczepę."
  
• "Jechałem sobie spokojnie, a tu nagle zaatakowała mnie wysepka tramwajowa."
  

Czytając tych kilka śmiesznych ( i podobno prawdziwych) fragmentów z raportów policyjnych trudno nie oprzeć się wrażeniu, iż ich autorzy w niezwykle naiwny sposób próbują uciec przed odpowiedzialnością. A być może nie chodzi tutaj o odpowiedzialność a o pielęgnowanie wizji siebie jako doskonałego kierowcy?

Powrócę tutaj do tematu, który poruszyłem w odcinku Dlaczego się nie uczymy
Jeśli komuś nie chcę się (znowu) tego czytać to w skrócie chodziło o to, że w nauce dowolnej umiejętności najtrudniejszy jest krok przejścia od "niekompetencji nieświadomej" do "niekompetencji świadomej" czyli zwyczajny przebłysk zatytułowany "chyba ja tego ku*wa jednak nie umiem!".

Dziś nadszedł czas aby bliżej przyjrzeć się w jaki sposób nasz umysł buduje tarczę obronną przed świadomością iż "my jako ludzie jesteśmy jedynie kruchymi i przemijającymi istotami połączonymi we wspólnej walce o przetrwanie w bezcelowym wszechświecie jedynie po to aby umrzeć i przeminąć" ;)

"Self-candicapping"

"Self-candicapping" czy też z polska "samo upośledzanie"(?) można dosyć łatwo wytłumaczyć. Zapewne nie jeden z was słyszał w szkole opinię nauczycielki o sobie czy kimś znajomym "on jest zdolny ale leniwy". Self-candicapping upraszcza tę sytuację i usuwa z przykładu nauczycielkę : "Jestem zajebiście zdolny ale leniwy. Gdybym tylko chciał to bym wszystko rozjebał no ale mi się nie chce".
Ale żeby nie pie*dolić farmazonów przejdźmy do badań naukowych. Tam gdzie mi się będzie chciało będę podawał źródła.

Badanie - test na inteligencję

Studenci zostali podzieleni na dwie grupy. Eksperyment polegał na rozwiązaniu niezwykle trudnego dwuczęściowego testu na inteligencję. W trakcie przerwy pomiędzy pierwszą a drugą częścią studenci byli pytani o swój poziom zdenerwowania i o to jak duży wysiłek wkładają w rozwiązanie testu. I tutaj pojawia się meritum eksperymentu: otóż jednej z grup "zabrano" jedną z wymówek i zakomunikowano, iż test został tak przygotowany aby bez względu na poziom zdenerwowania dać właściwy obraz inteligencji studenta.

Wyniki:

Grupa która mogła wybrać sobie swój "handicap" postawiła na zdenerwowanie (być może jako bardziej naturalne) i określiła iż znajdowała się pod wysokim wpływem tego uczucia. Druga grupa nie mogła zgonić winy za złe wyniki na zdenerwowanie toteż w tej grupie okazało się, że studenci użyli drugiej metryki i określili swój wysiłek włożony w rozwiązanie testu jako niewielki.

Źródło : Smith T.W. 1982 On the self serving function of an academic wooden leg : Test anxiety as self-handicaping strategy.

"Self-Shifting"

Pamięć - największy sprzymierzeniec EGO. Kiedy twoja, czy też dla bezpieczeństwa "czyjaś" wizja siebie przestaje pokrywać się z aktualnymi potrzebami pamięć zaczyna tasować wspomnieniami tak aby znaleźć coś wygodniejszego.

Badanie - cecha prowadząca do sukcesu

Znowu mamy dwie grupy losowo wybranych studentów. Jedna grupa dostaje artykuł twierdzący, że osoby ekstrawertyczne odnoszą większe sukcesy po zakończeniu szkoły, druga grupa zaś dla przeciwieństwa dostaje artykuł chwalący introwertyzm.

Wyniki:

Bez niespodzianek - u studentów pierwszej grupy mózg zamówił z magazynu pamięci wspomnienia potwierdzające, że są ekstrawertykami zaś w przypadku drugiej grypy potrzebne były wspomnienia świadczące o czymś przeciwnym.

Źródło : Kunda Z. and R. Sanitioso 1989 Motivated changes in the self-concept .

Trust (próżnych) mózgów

Istnieje ciekawa metafora naszego umysłu. Jest to prawnik, który nie szuka prawdy ale dowodów na obronę swojego klienta czyli nas. Ma on do pomocy naszą pamięć czyli sekretarkę, która pomaga mu filtrować wszystkie dowody w poszukiwaniu tego, który dowiedzie niewinności klienta. Jak to w sądzie mamy także świadków. A najlepsi świadkowie to oczywiście ci "bezstronni na naszą korzyść". Istnieje badanie pokazujące jak bardzo nasz umysł dąży do tego aby przebywać w towarzystwie ludzi, którzy będą pielęgnować nasze złudzenia.

Dam tutaj nawet linka do tych badań ze względu na swojsko brzmiące nazwisko :
In Search of Information That Confirms a Desired Self-Perception: Motivated Processing of Social Feedback and Choice of Social Interactions by Wlodarski and Sanitioso

Przypomina mi to anegdotke, którą przeczytałem w jednej z książek Bandlera (współtwórcy NLP - podobno). W trakcie lekcji pierwszej nauczył studentów rozpoznawać ludzkie fobie i słabości. Lekcja druga polegała na tym aby nie robić tego u swoich znajomych...

Jeszcze jeden ciekawy przykład

Miało miejsce jeszcze jedno ciekawe badanie, które pokazało, iż nasz umysł jest w stanie nawet zmienić fizyczną tolerancję na chłód. Standardowo jak to w takich badaniach podzielono studentów na dwie grupy gdzie jednej wkręcono istnienie badań dowodzących, że oznaką długowieczności jest odporność na zimno - zaś grupie drugiej coś przeciwnego. Łatwo chyba przewidzieć, uczestnicy której grupy byli w stanie dłużej trzymać rękę w kuble wypełnionym lodem.

Czy ten mechanizm jest opłacalny

Nie w dzisiejszych czasach. Znowu jest eksperyment i znowu dwie grupy ale tym razem maklerów giełdowych grających na wirtualnej wersji giełdy z losowymi zmianami. Maklerzy, którzy wkręcili sobie, iż posiadają wpływ na symulację zarabiali średnio 100 000$ mniej od tych skromniejszych. (Fenton - O'creny Trading on illusions Unrealistic perceptions of control and trading performance.)

Okno rzeczywistości

Według badaczy mózg posiada jedną technikę obrony przed nim samym. Tzw. "Okno rzeczywistości". NA chwilę przed podjęciem decyzji - niech będzie to zakup samochodu - załącza się u nas bardziej profesjonalne zarządzanie ryzykiem i przygasa trochę omnipotencja. Jednakże chwilę po podjęciu decyzji wspomniane okno zamyka się z trzaskiem! To tutaj pełne pole do popisu ma dysonans poznawczy i racjonalizacja właściwego wyboru.

Moje techniki

Obecnie najsilniejszą znaną mi techniką odnośnie wpływania na własne przekonania jest medytacja połączona z wizualizacją. Jest to jednocześnie technika wymagająca pewnej wiedzy teoretycznej i poświęcenia czasu na ćwiczenia. Ostatnio spróbowałem z czymś łatwiejszym co można by nazwać realną wizualizacją na jawie (nie Javie). Generalnie polega to na skontruowaniu swojego pseudo alter-ego w potaci profilu na forum dyskusyjnym i działaniu na dwa sposoby

• Mini trolling - ponieważ to nie nasze ego będzie atakowane toteż nie powinny wystąpić reakcje obronne. Jednocześnie nasz umysł powinien być w stanie wyłapać argumenty za i przeciw danego przekonania.
• Trolling przeciwstawny - tutaj trollujemy na rzecz argumentu z którym się nie zgadzamy (czyli np "Od czego najlepiej zacząć naukę PHP po porzuceniu javy") i wtedy nasz umysł już kompletnie będzie zakręcony co pozwoli na wygodne metaprogramowanie

Na koniec plusy dodatnie. W innym eksperymencie studenci pierwszego roku zostali wkręceni, iż po zakończeniu pierwszego semestru ich oceny podskoczą w górę. Młodzi tak w to uwierzyli, że zapierdalali aż ich wkręcone przekonania się urzeczywistniły...