poniedziałek, 21 stycznia 2013

Nocna zmiana

Mój ojciec pracował niegdyś w trybie zmianowym (zmiana poranna, popołudniowa i nocna). Wynikało to wówczas z utrzymania ciągłości produkcji w fabryce i realizacji planów gospodarki sterowanej centralnie.

Bez obaw - nie zamierzam pisać o polityce i centralnym sterowaniu gospodarką:)

Wielu programistów pracuje po nocach - niektórzy sobie to chwalą, inni przeklinają nie mogąc wyrwać się z tego programu dobowego. Mnie również się to zdarza.

Do tej pory myślałem, że są tego 3 (mniej lub bardziej) powszechnie znane przyczyny (które zapewne się nakładają na siebie):

  1. doświetlenie szyszynki przez matryce naszych komputerów, co w efekcie rozregulowuje wydzielanie melatoniny
  2. brak energii o poranku (a kumulacja wieczorem) spowodowany rozregulowaniem wydzielania kortyzolu - wynik diety opartej na węglowodanach
  3. po prostu rozproszenie przez to co dzieje się dookoła nas (to zależy jeszcze od wyczulenia percepcji któregoś ze zmysłów)
Dziś w mailingu z linkedin dostałem linka do ciekawego artykułu: Why Programmers Work At Night, w którym to autor integruje całość:
  • odnosząc się do pierwszeej przyczyny
  • odnosząc się do przyczyny trzeciej: nazywa dwa rodzaje skupienia: ludzi zarządzających vs ludzi wytwarzających (coś wartościowego;) Ludzi zarządzający dzielą czas na odcinki, ludzie tworzący kreatywne połączenia muszą "załadować sobie kontekst" - ciekawe zwerbalizowanie tego co każdy jakoś tam intuicyjnie czuje
  • podaje kolejną hipotezę: zmęczenia mózgu, która gdy się nad nią zastanowić ma "intuicyjny sens"
Kolejna hipoteza zakłada, że hiper-aktywność mózgu, która nie pozwala się nam skupić na jednej rzeczy i prowokuje do "skoków w bok"  (powszechnie znany problem) znika jeżeli mózg jest dostatecznie zmęczony. Daje to możliwość "załadowania kontekstu" i wykonania na nim operacji.

Zatem wieczorem, gdy jesteśmy już zmęczeni na tyle, że nie możemy się rozpraszać i możemy skupić się na jednym wątku następuje czas, gdy można zrobić coś sensownego:)

Szkoda tylko, że w artykule nie ma odnośników do badań:P

//=======================

O różnicach w wewnętrznym modelowaniu czasu pisałem dawno temu.

A jak to jest w Waszym przypadku?

niedziela, 13 stycznia 2013

100 mandaysów za dodanie jednego checkboxa?!?

Standardowa scenka: spotkanie tak zwanego "biznesu" z tak zwanym "IT"; dyskusja nad "małą kosmetyczną zmianą" polegającą na "dodaniu jedynie małego checkboksa".

Na minach "IT" najpierw pojawia się grymas namysłu, a następnie ekspresja (nie mikro-ekspresja) zagłady i katastrofy. W wyobraźni ujrzeli trzęsienie ziemi, która kruszy katedrę, którą budują od x miesięcy/iteracji/cokolwiek. "IT" przełyka ślinę i odpowiada: "zajmie nam to 100 mandaysów".

Mina "biznesu":

Dalszy rozwój scenariusza może przebiegać różnie w zależności o relacji - czy mamy negocjacje klient-dostawca, dział biznesowy-dział it, itd.
Typową dziecinną techniką jest zaniżanie o połowę, ale IT już wie, że "oni zawsze zaniżają", więc defaultowo  zawyża, jednak biznes, wie, że "oni defaultowo zawyżają", więc zaniża 4-krotnie, itd... wszyscy traktują się nawzajem jak by druga strona była opóźniona.

W każdym jednak przypadku "IT" jest na przegranej pozycji. Podczas gdy "my" doskonalimy się we frameworkach, wzorcach i architekturach, "oni" zdobywają siódmy czarny pas w NLP i technikach manipulacji wszystkim czym da się manipulować...

Skąd bierze się takie niezrozumienie powagi zmiany?
Najprawdopodobniej obie strony mają w swoich umysłach inne modele mentalne problemu oraz jego złożoności.

Bywalcy konferencji oraz czytelnicy książek przyprawionych nutką Agile próbują posiłkować się metaforą "Długu technicznego", który został kiedyś zaciągnięty i oto nadeszła chwila, kiedy trzeba go spłacić. "Ale jaki dług, przecież działa!" - możemy usłyszeć w odpowiedzi.

Gdyby istniał wspólny model domeny problemu, wówczas każdy uczestnik projektu "czułby" intuicyjnie powagę zmiany. Ew. naiwne uproszczenia dokonywane z wielu (zwykle racjonalnych) powodów, mogłyby być dokonywane ze świadomością konsekwencji. Uświadomiony dług techniczny.


Dla przykładu: powyżej widzimy model budynku wydrukowany przez drukarkę 3D. Nawet osoba nietechniczna intuicyjnie poczuje, że "postawienie o tutaj (wskazuje palcem na dach) lądowiska dla helikoptera" będzie "nieco" kosztowne. Trzeba przecież znacznie rozbudować konstrukcję nośną albo jeżeli chcemy ją zachować wymienić słupy na tworzywo wykradzione z NASA;)

Spróbujmy osiągnąć taki poziom świadomości gdyby obie strony siadły do: a) rysunków technicznych, b) dokumentów wizji, przeczuć i życzeń zwanych czasem dumnie artefaktami analitycznymi.

Ten przydługi wstęp miał być zachętą do zapoznania się z ostatnim z publikowanej w programistamag.pl serii "DDD krok po kroku": Modeling Whirlpool – iteracyjny proces modelowania (dostęp jest całkowicie darmowy).

Modeling Whirpool jest zwinnym procesem tworzenia wspólnego modelu, który jest zrozumiały również dla Eksperta Domenowego oraz implementowalny 1:1 w kodzie źródłowym - żadnych poziomów abstrakcji, które tworzą luki semantyczne.

//====================================

W styczniowym numerze rozpoczynam nową serię: "Niezbędnik początkującego Architekta", wktórej znajdziecie systematyzację (mam nadzieję) wiedzy bazowej oraz kilka sprawdzonych receptur.

Zainteresowanych DDD i Modeling Whirlpool zapraszam na konferencję 33rd Degree - prezentacja i warsztaty.