Dysonans kognitywny

Normalny zdrowy i niewytrenowany umysł ma nie lada problem z jednoczesnym utrzymaniem się przy 2 ortogonalnych ideach. Nazywa się to dysonansem kognitywnym. Umysł ma tendencję do dorabiania sobie teorii i mitów aby tylko usprawiedliwić lenistwo intelektualne i trzymanie się tego co znane - wszystko w celu minimalizowania dysonansu. Wbudowane mechanizmy obronne chronią mózg przed przegrzaniem wybierając ideę bardziej znaną a inne odrzucając jako z gruntu złe.

Osobniki unikające myślenia krytycznego (myślenia nad tym co się myśli) mają łatwiej - są w stanie bez skrupułów odrzucić niewygodny pogląd i przy okazji stwierdzić, że osoba go głosząca "nie zna sie, jest gupia i filozuje". Wszyscy inni aby doraźnie zdusić to dręczące i nieprzyjemne uczucie napięcia psychicznego towarzyszące dysonansowi uciekają się do trików typu wysiłek fizyczny lub upojenie alkoholowe;)

Magicy od NLP zalecają strategię pytań w celu przebicia się przez mur uprzedzeń. Twierdzą oni, że nie da się kogoś przekonać do innych poglądów jedynie próbując je artykułować. Natrafiamy wówczas na opór wywołany dysonansem kognitywnym, który spowoduje jedynie mocniejsze utwierdzenia w przekonaniach - pomóc tu mogą jedynie elektrowstrząsy;)
Zamiast tego lepiej jest wczuć się w rolę osobnika którego chcemy przekonać, zacząć mówić jego językiem a później zacząć zadawać pytania. Pytania mają ogromną siłę zdolną rozbić mur uprzedzeń. Siła ta polega tym, że na pytanie zawsze zostanie udzielona odpowiedź - nie koniecznie jawnie, ale przynajmniej w środku, w Czesiu.


W poprzednim poście zachwalałem książkę, która wywarła ogromy wpływ na moje rozumienie procesu powstawania oprogramowania i myślenie o poziomach abstrakcji. Niedawno zainspirowany gorącą dyskusją o DDD na forum Springa i z polecania Rafała Barszczewskiego zacząłem czytać "Domain-Driven Design: Tackling Complexity in the Heart of Software" Erica Evansa.

Co prawda przeczytałem dopiero pierwszą (z 4) część ale już widzę, że zapowiada się dzieło na miarę Larmana. Evans dzieli się głębokimi i trafiającymi w sedno przemyśleniami o przyczynach niepowodzeń projektów (nawet tych, które w pierwszym roku wyglądały na wspaniały sukces), sięga do natury developerów i opisuje ich błędy od strony psychologicznej.

Póki co z lektury pierwszej części Okazuje się, że należy jednak utrzymywać jeden model łącząc poziom analizy i projektu - inaczej niż u Larmana.

Do nasilenia mojego osobistego dysonansu przyczynia się również praca nad architekturą nowego systemu. Z jednej strony chciało by się zaprojektować go inaczej niż do tej pory, uniknąć pułapek i bałaganu do którego w sposób nieunikniony prowadzą dotychczasowe doświadczenia. Może zastosować podejście Evansa... Z drugiej strony wymagania niefunkcjonalne takie jak integracja ze starymi systemami czy modularyzacja posunięta do granic absurdu uniemożliwiająca wypracowanie eleganckiej i prostej architektury - po prostu nakładanie gaci przez głowę.

Mało tego... okazuje się, że wspaniałe frameworki niezbyt wspierają DDD. Raczej anemiczny model domenowy. Springowcy coś ściemniają. Seam to wogóle szczyt prostactwa architektonicznego. Hibernate - diabeł tkwi w szczegółach i rozwala OO:/

Co więcej... potwierdzają się odczucia mojej kobiecej intuicji iż lansowana dotychczas architektura (czy to Springowa czy EJB) to po prostu proceduralne badziewie. Może to okaże się jakąś namiastką: Real Object Oriented.

Zachęcam do dyskusji... Czy macie jakieś doświadczenia z Domain Driven Deveopment? A może ktoś zechciałby podzielić się nimi w formie prezentacji na JUG?

//==============
W najbliższym czasie obiecuję recenzję książki Evansa. W nieco dalszej przyszłości spróbuję opublikować wyniki pracy nad opracowywaną architekturą.

5km biegu nie pomogło; może jutro low-level format w sprzyjających okolicznościach przyrody jeziora...