NIDE 1: Problem

Chciałbym poruszyć problem, który mnie dotyczy od pewnego czasu, a mianowicie pracy w środowisku, które nazywam NIDE. Wygląda na to, że wyjdzie z tego cały cykl. Zaczynajmy!

Photo by meantux

IDE są świetne. Uwielbiam środowiska, które pozwalają mi w jednym okienku robić wszystko, od designu po testy integracyjne i deployment (czyli zazwyczaj commit do repozytorium). Problem w tym, że nie zawsze mam możliwość pracy w takim środowisku, czyli w projekcie mamy odgórnie ustalone NIDE - Non-Integraied Development Environment.

Uroki NIDE wynikają zazwyczaj z pracy nad systemami wbudowanymi. W moim obecnym projekcie mamy następujące feature'y:

1. Brak odgórnie ustalonego edytora kodu i setki tysięcy (miliony?) linii kodu do ogarnięcia
2. Dość rozbudowany skrypt konfigurujący linię komend, w której możemy kompilować i przeprowadzać statyczną analizę kodu
3. Niezbyt popularny build toolchain i strukturę projektu opartą o coś na kształ makefile'ów
4. Testy modułowe odpalamy na emulatorze uruchamiany z Visual Studio
5. Za samo odpalenie testów odpowiedzialny jest program Rational Test Real-Time
6. Żeby przetestować kod na działającym systemie musimy go wrzucić na sprzęt docelowy np. przez Visual Studio
7. Informacje ze sprzętu trafiają do nas przez port COM, więc potrzebujemy jakiegoś programu do zbierania i przeglądania logów z portu szeregowego.
8. Repozytorium kodu zamknięte szczelnie jak radziecki słoik i obsługiwane przez klienta napisanego w Javie.

Punkty od 2. do 8. są poza jurysdykcją programisty - takie są wymagania, tak musimy pracować. Okej, z tym się jestem w stanie pogodzić, skoro mogę wybrać edytor! Czego bym wymagał od edytora? Bez szczególnej kolejności:

• Możliwości skakania pomiędzy plikami, w szczególności do definicji funkcji/zmiennych... i oczywiście możliwość automatycznego szukania tych definicji.
• Program ma być darmowy. To się nie wydaje takie oczywiste, ale przede wszystkim zależy mi na społeczności. Wokół zamkniętych programów rzadko organizuje się grupa zapaleńców, a kiedy napotykam na jakiś problem i próbuję googlać za rozwiązaniem, to słyszę świerszcze.
• Szybkości. Dużo czasu mi schodzi na obsługę całej reszty NIDE, nie chciał bym dodatkowo walczyć z narzędziem, w którym realizuję sedno mojej pracy.
• Możliwie dobrej integracji z build toolchainem. Większość osób w projekcie skacze pomiędzy oknami edytora i linii komend: Zmiana w kodzie, [Switch!] kompilacja, sprawdzenie ewentualnych błędów, [Switch! i to kilkukrotnie] lokalizacja w edytorze, poprawki, [Switch!] kompilacja. Przy dwóch monitorach da się z tym żyć, ale... mi szkoda życia.
• Niezawodności. Nie wyobrażam sobie, żebym stracił choćby pół godziny pracy w wyniku jakiegoś tyci problemiku.
• Rozszerzalności. Jeżeli edytor nie ma czegoś, czego będę potrzebował, to chcę móc to sobie dorobić; łatwo i przyjemnie.

Uff... sporo się zrobiło tych wymagań. W następnej części pokażę, jak tym wymaganiom sprostał uwielbiany przez niektórych Eclipse. Narzekaniom nie będzie końca. Oczywiście żartuję... ale czy na pewno?

Bezwzględne testowanie

O testach modułowych pisałem już wcześniej, tak jak i o DevDay, ale wykład Grega Younga wzbudził u mnie pewien rezonans. Ten sam wykład z innej konferencji można obejrzeć np. tutaj. Polecam wszystkim chętnym.

Greg Young otworzył mi oczy na zupełnie nowe spojrzenie na testowanie programów. Od pewnego czasu miałem wrażenie, że napisanie dobrych testów nie jest łatwe i że jeszcze trudniej zmierzyć jakość testów, ale to były tylko przeczucia, a Greg pokazał, jak można do tego podejść w sposób bardzo ścisły i konsekwentny. Jednak nie to przykuło moją uwagę najbardziej.

Photo by kabils

Najciekawszą częścią wykładu była dla mnie część, w której autor postulował celowe zmiany w kodzie aby sprawdzić, czy testy się wysypią. Bingo! Dodałeś do zmiennej 'x' 1? A jeżeli zmienię zamienię 1 na 5, to co się stanie? Program ewidentnie się zmieni, ale czy te super-testy które napisałeś się wysypią? A jeżeli zamiast dodać odejmę, co wtedy? Kiedy o tym poważnie pomyśleć, to jest jedyny sposób sprawdzenia, czy testy działają. Gdybym miał czujnik przeciwpożarowy, który nie podniesie alarmu, kiedy przytknę do niego zapaloną zapałkę... nie czuł bym się do końca bezpiecznie. Najbardziej Greg zaimponował mi kiedy powiedział, że pracują nad narzędziem, które będzie wprowadzało takie zmiany automatycznie. Wow.

Później przyszła jeszcze jedna refleksja: ja już o tym gdzieś czytałem. Pragmatyczny programista, porada 64: "Użyj sabotażystów żeby testować swoje testy". Po raz kolejny okazuje się, że w informatyce wymyślono już multum dobrych idei, które tylko czekają na swój czas.

Dwa wnioski na dziś:

1. Koniecznie przeczytać jeszcze raz Pragmatycznego programistę.
2. Przydałby się post na temat tej książki i innych, które miały na mnie największy wpływ.

Wielokulturowość, wielonarzędziowość

Już wcześniej pisałem o powiązaniach pomiędzy językiem a myśleniem i o tym, jak osoby bikulturalne potrafią myśleć inaczej na ten sam temat, w zależności od tego, w jakim języku zadamy pytanie. Te przemyślenia skorelowały mi się z wystąpieniem Martina Mazura na DevDay, o którym pisałem w zeszłym tygodniu. Jeżeli ktoś ma ochotę to można ten wykład obejrzeć tutaj, choć to nagranie z innej konferencji.

Myślę, że to kuszące, jeżeli jedynym narzędziem, jakie posiadamy jest młotek, aby traktować wszystko jak gwóźdź. -- A. Maslow 

Ten cudowny cytat z Maslowa pokazuje cały problem, jaki wynika z ograniczania zestawu narzędzi, których używamy; w życiu, w pracy, w myśleniu. Dodatkowa trudność polega na tym, że kiedy już widzimy dookoła tylko gwoździe, to ciężko się przekonać, że być może istnieją inne problemy i inne narzędzia do ich rozwiązania.

Ja miałem szczęście. Udało mi się znaleźć środowiska, które wymusiły na mnie poszukanie nowych narzędzi. Mówię między innymi o kursach on-line, w których wziąłem udział. Jednak wcześniej była jeszcze potrzeba przygotowania pewnego narzędzia wewnętrznego w moim obecnym projekcie, która wymusiła na mnie poznanie Perla i... to było olśnienie.

Zanim jeszcze zostałem zawodowym programistą (czyt. zaczęli mi za to płacić) poznałem Pascala, C, C++ i C#... pomijając pierwszą pozycję już na pierwszy rzut oka widać tu obrzydliwą spójność gatunkową. Poznanie Perla było dla mnie wejściem w zupełnie nowy wymiar w którym o dziwo poczułem się dobrze. Perl jest tak elastycznym narzędziem, że poczułem się jakbym zakładał na mózg dobrze dopasowaną rękawiczkę.

Photo by Bill Liao

Podczas kursów Coursery poznałem kolejne narzędzia, które może nie były do mnie już tak dobrze dopasowane, ale świetnie nadawały się do rozwiązywania problemów, które stawiali przed nami wykładowcy. Kiedy myślałem o tym, jak rozwiązywałbym te same problemy w językach, które już znałem, już na etapie koncepcji stawała mi przed oczami wizja wbijania śrubek młotkiem. Niepiękna to wizja.

Prawda jest taka, że moja skrzynka z narzędziami stała się ostatnio dużo cięższa i kiedy zabieram się dziś do nowego problemu robię wcześniej sumienny przegląd narzędzi.

Poza językami programowania odkryłem jeszcze inne narzędzia, ale to już temat na osobny post.

DevDay 2012, minirelacja

W zeszłym tygodniu byłem z kuzynem na konferencji DevDay 2012 w Krakowie. Jak ktoś nie wierzy, to może mnie poszukać na zdjęciach z konferencji. ;-)

Krótka relacja z kolejnych prezentacji tego dnia:

• Wykład otwierający w wykonaniu Scotta Hanselmana był dokładnie taki, jak oczekiwałem. Pogadanka o dbaniu o zdrowie psychiczne będąc programistą, dużo humoru, fajne rady i spostrzeżenia. Gdyby odwołano resztę konferencji nadal nie żałowałbym 22 godzin w pociągach.
• Na drugim wykładzie Mark Rendle pokazywał, w jak niepojęte sposoby można wygiąć C#  dla własnych potrzeb i jak ciekawe efekty można dzięki temu uzyskać. Interesujące i mocno techniczne.
• Dość dziwny wykład w wykonaniu Sebastiena Lambli. Może po prostu nie interesuje mnie cachowanie HTTP? Za to ciekawa uwaga ze strony prowadzącego - w jego opinii nikt na sali nie zajmował się "współczesną web-developerką" i wezwanie do obudzenia się: Guys, there's a world out there! Mocne.
• Występ Roba Ashtona z mocno komediowymi akcentami poświęcony javascript'owi. Ashton pokazał jak sobie radzić z niedogodnościami pisania w języku, którego się nie lubi i który rzekomo nie ma odpowiednich narzędzi. Fajny wykład i plus za Vim'a,
• Polsko-norweski kodujący wiking czyli Martin Mazur opowiadający o tym, co można wynieść z relacji międzykulturowych i obalenia podziału na "naszych" i "innych". Dobry balans pomiędzy techniczną i miękką stroną prezentacji. Sporo jego uwag pokrywa się z tym w co gorąco sam wierzę.
• Trochę irytująca samochwałka w wykonaniu Antka Piechnika. Każdy ma prawo chwalić swoją firmę, ale wyszło ciut zbyt nachalnie, szczególnie że wiele pomysłów mało oryginalnych. Jeden ciekawy pomysł na narzędzie typu fire-and-forget konfigurujące środowisko developerskie. Przy dużych projektach to może zaoszczędzić ogrom czasu podczas onboardingu.
• Trochę niespodziewany bardzo dobry wykład na zamknięcie konferencji w wykonaniu Grega Youga. Świetne przykłady data-miningu na systemach kontroli wersji i na zależnościach pomiędzy modułami. Dało mi sporo do myślenia i dużo funu.

Po wszystkim krótki wypad na after-party, gdzie można było się pointegrować z innymi uczestnikami konferencji, a potem niestety 11-godzinna randka z PKP.

Duży szacunek dla ABB, sponsora konferencji, za bardzo profesjonalne podejście poprzez brak nachalnego marketingu. Poza tym ekipa organizacyjna spisała się na medal. Pełny profesjonalizm. W przyszłym roku znów spróbuję się wybrać i polecam to samo każdemu.,

Coursera, minirecenzja

Pod koniec kwietnia 2012 zacząłem przygodę z serwisem Coursera, gdzie zapisałem się na dwa kursy on-line: o kompilatorach i o machine learning. Obecnie ciągnę kurs z algorytmów(który niestety chyba obleję...) oraz programowania funkcyjnego w Scali. Chciałem się podzielić skrótem z wrażeń:

• Machine Learning to bardzo fajny kurs. Niezbyt trudny, szczególnie jeżeli ma się podstawy algebry i znajomość octave albo matlaba. Kurs traktuje o bardzo ciekawych zagadnieniach i pokazuje praktyczne przykłady zastosowania technik z zakresu "machine learning". W ramach kursu napiszemy własny system rekomendujący filmy czy sieć neuronową do rozpoznawania zeskanowanych cyfer. Fun!
• Kompilatory to kurs, moim skromnym zdaniem, fundamentalny dla każdego programisty. Nie powtórzcie mojego błędu i nie bierzcie na siebie tego kursu wraz z innym albo jeżeli nie wiecie, czy będziecie mieli na niego czas. W ramach tego kursu napisałem swój własny kompilator i kompletnie zmieniłem sposób, w jaki myślę o programach. Kurs zaliczyłem z problemami, ale nie żałuję ani godziny na niego poświęconej.
• Algorytmy są bardzo ciekawym kursem, ale też wymagającym odrobiny czasu. Prowadzący są ewidentnie kompetentni i zadają bardzo ciekawe problemy do rozwiązania w ramach zadań domowych. Niestety nie udało mi się wyłuskać wystarczającej ilości czasu, żeby spokojnie zaliczyć kurs, ale już wiem, że go powtórzę przy następnej edycji.
• Programowanie funkcyjne w Scali to najlepsza rzecz, jaka zdarzyła mi się od sięgnięcia po Code Complete McConnel'a. Bardzo fajny kurs, który zmienia mózg w sposób, który ciężko opisać... jeżeli nigdy nie programowaliście funkcyjnie, a chcielibyście poćwiczyć szare komórki, to gorąco polecam. Dodatkowym plusem jest fakt, że kurs prowadzi jeden z autorów języka Scala, Martin Odersky.

Photo by Rickydavid

Poza tym staram się monitorować EdX i Udacity. Jeżeli znajdę któryś z tamtejszych kursów interesującym, to dam znać.

Ogólna rekomendacja brzmi: idźcie i uczcie się!

Testy modułowe albo mit pokrycia

Nie sądziłem, że ten post jest konieczny, ale wygląda na to, że dopadł mnie syndrom Blutfelda.

<dygresja>
Tych, którzy nie wiedzą, o co chodzi z Herr Blutfeldem, odsyłam do powieści Jacka Dukaja "Lód". W dużym skrócie Herr Blutfeld, jeden z drugoplanowych bohaterów wyżej wymienionej powieści, nie zabiera głosu w prawie żadnej dyskusji, których w opowieści jest naprawdę mnogo. W czasie, kiedy inni współpasażerowie Kolei Transsyberyjskiej spierają się żywo i efektownie, on woli oddawać się przyjemności jedzenia wszystkiego, co da się zjeść, od czego nabawił się paru dodatkowych podbródków.

Podczas jednego z postojów Herr Blutfeld nie wytrzymuje i wybucha. Okazuje się, że nie jest głupawy ani pozbawiony własnych poglądów - przeciwnie! Nie zgadza się z żadnym ze współpasażerów i uważa wszystkie ich opinie za głupie, nietrafione i kretyńskie. Problem w tym, że za każdym razem kiedy ma się już odezwać i wytknąć towarzyszom błędy w rozumowaniu, dochodzi do wniosku, że nie ma najmniejszego sensu się odzywać ponieważ wszystko, co ma do powiedzenia jest oczywiste! O-czy-wis-te! Nie ma sensu zużywać tlenu i drażnić neurony; tracić energię na tłumaczenie rzeczy tak prostych i po trzykroć oczywistych.

Podczas swojej przemowy nasz bohater ani na chwilę nie przestaje jeść. Priorytety!
</dygresja>

Przechodząc do rzeczy:
Ostatnio w rozmowie z dość kompetentnymi ludźmi usłyszałem taką opinię:

Nasze testy modułowe są dobre ponieważ mamy wysokie pokrycie kodu.

Photo by roxj

Na początku pomyślałem, że kolega sobie zażartował, ale ponieważ mój czujnik sarkazmu nawet nie drgnął, zapytałem czy oby na pewno nie raczył żartować... Niestety nie. Witki mi opadły. Gratulacje! Odkryliśmy pewną miarę jakości testów modułowych! Nie potrzebujemy o nich już żadnych książek, szkoleń ani dobrych praktyk! Wiemy już wszystko!


W dużym skrócie:
Dobre testy będą miały wysokie pokrycie kodu, ale wysokie pokrycie nie zagwarantuje nam, że testy są dobre. Dlaczego? Zastanówmy się, czym jest pokrycie kodu... to że linia kodu jest pokryta podczas testu oznacza, że w ramach wykonania testu ta linia została odwiedzona, nic więcej. Procesor przemielił instrukcje, które stały pod tą linią kodu. Nie ma tu mowy o sprawdzaniu, czy te instrukcje zrobiły to, czego się spodziewaliśmy. Nie ma nawet słowa o tym, czego się spodziewaliśmy.

Dobre testy dokładnie określają czego się spodziewamy, łącznie z tym, co się nie powinno wydarzyć... problem jest taki, że do tego opisu ciężko przypiąć liczbę.
Jest to zaleta, którą mierzenie pokrycia posiada i która jest niestety nadużywana.

Języki a Programowanie

Chodzi mi o to, żeby język giętki
powiedział wszystko, co pomyśli głowa.

-- Juliusz Słowacki

Jakiś czas temu został mi polecony artykuł "Mowa duszy" z Wiedzy i Życia (09/2011), który traktował o zależnościach pomiędzy myśleniem, a mówieniem. Jedna z ciekawych obserwacji dotyczyła osób bilingualnych, płynnie posługujących się dwoma językami, często wychowanych w dwóch kulturach w wyniku np. przeprowadzek. Eksperymenty pokazywały, że osoby te myślały na dwa różne sposoby, kiedy przedstawiło im się to samo pytanie w dwóch językach. Badania aktywności mózgowej pokazywały aktywacje innych obszarów w mózgu w odpowiedzi na pozornie tę samą treść. W moim mózgu pojawiła się iskierka.

Photo by Manjith Kainickara

Druga, równie ciekawa informacja dotyczyła pewnego chłopca z jakiegoś małego plemienia, gdzieś w inaczej cywilizowanym świecie. Badacz opowiadał, że dostrzegł wyjątkową płynność ruchów u jednego z młodych tubylców i postanowił nauczyć go tańczyć, ale jego wysiłki spełzły na niczym. Na czym polegała trudność? Naukowiec poległ, kiedy chłopak nie mógł zrozumieć, co to znaczy, że ma wykonać krok w prawo albo w lewo. Plemię, z którego młodzian pochodził nie znało pojęcia kierunków względnych. W ich kulturze wszystko znajdowało się na północ, wschód, zachód lub południe od punktu odniesienia. W takiej sytuacji dość ciężko opisać np. walca wiedeńskiego, który polega przecież na ciągłych obrotach. Nie chodzi o to, że nie da się tego zrobić, jest to po prostu bardzo trudne. Iskierka w moim mózgu przeskoczyła.

Z powyższych informacji i własnych doświadczeń mogę wysnuć pewien wniosek - warto uczyć się różnych języków, również programowania. Różne języki programowania uczą różnych idei; i nie chodzi o to, że program P napisany w języku A jest nie do napisania w języku B... ale często jest tak, że ten sam program w języku B jest najgorszym koszmarem programisty, podczas gdy w języku A to zaledwie parę prostych linijek kodu. Tak jak pewne tańce nie powstałyby w kulturze absolutnych kierunków, tak niektóre pomysły nie powstałyby w Assemblerze i C.

Do tematu jeszcze pewnie nie raz wrócę, bo czuję, że dotyka czegoś ważnego.

Jakość

Ten tekst jest wynikiem przeczytania książki "Zen i sztuka obsługi motocykla" Roberta M. Pirsinga i prawie roku przemyśleń własnych. Ze względu na brak przygotowania filozoficznego autora, tekst ma niezwykle mierną wartość merytoryczną. Zostaliście ostrzeżeni!

Jakość to subiektywna miara cukru w cukrze.

Photo by BrianScott

Niech powyższa myśl trochę powisi, a ja spróbuję nakreślić pewien obraz.

Znacie to uczucie, kiedy stoi przed wami dobrze znane zadanie? Dla osób sprawnych manualnie może być to opakowanie ładnie prezentu albo zrobienie wełnianego szalika. Jeżeli ktoś ma bardziej specyficzne zainteresowania, to może być to lutowanie dobrze przygotowanego układu albo zrobienie bukietu kwiatów z origami; sadzenie kwiatów w ogrodzie lub, wspomniana wcześniej, naprawa motocykla. Uczucie, o którym mówię rodzi się wtedy, kiedy wszystko idzie jak należy - wszystkie potrzebne elementy są zawczasu przygotowane i mamy dość czasu na całe zadanie - nic nas nie goni, nic nas nie popędza. Ruchy rąk są spokojne, ulubione narzędzia znajomo leżą w dłoni, tworzywo jest giętkie i posłuszne naszej woli. Powoli rodzi się wytwór naszej pracy - dokładnie taki, jaki powinien być. Znacie ten spokój umysłu? W takich warunkach dzieje się "dobra robota" i właśnie wtedy rodzi się wysoka jakość.

Podobne wrażenie możemy mieć, kiedy używamy porządnych rzeczy. Na przykład kiedy instynktownie wiemy co nacisnąć na naszym nowym odtwarzaczu, żeby znaleźć piosenkę, na którą mamy akurat ochotę; albo którą gałką nastawimy głośność radia, zamiast je rozregulować. Przedmioty, z których z łatwością korzystamy dają nam podobny rodzaj spokoju umysłu. Niemniej chciałbym się teraz skupić na jakości pracy, bo z niej wynika zazwyczaj jakość rzeczy.

Opisane powyżej wrażenie jest bezpośrednim przeżyciem jakości, która w mojej ocenie jest brakiem rozdźwięku pomiędzy tym, jak jest, a jak być powinno. To cukrowość cukru i nożowość noża jednocześnie. Nie ma mowy o żadnej konkretnej cesze, a o zbliżeniu do ideału. Pachnie trochę Platonem, ale to jest właśnie moim zdaniem Jakość.

Jest też zupełnie inne uczucie, które wynika z czegoś, co złośliwi nazywją połączeniem praktyki z teorią:

TEORIA jest wtedy kiedy wszystko wiemy a nic nie działa.
PRAKTYKA jest wtedy kiedy wszystko działa a nikt nie wie, dlaczego
U nas w firmie łączymy teorię z praktyką:
NIC NIE DZIAŁA I NIKT NIE WIE DLACZEGO.

-- autor nieznany

Z reguły zaczyna się zupełnie niepozornie - ot, zwykła niemożność skupienia myśli, lekka irytacja, że nie ma czasu nawet na porządne przygotowanie się do pracy. Potem papier rozcina skórę na palcu, który trzeba szybko opatrzyć i akurat teraz zabrakło plastra; albo okazuje się, że nożyczki są tępe i bardziej strzępią niż tną. Do mózgu ciągle puka wskazówka zegara i rosnąca świadomość innych obowiązków powoduje drenaż myśli. Stajemy się rozdrażnieni, efekty naszej pracy odstają coraz wyraźniej od naszych oczekiwań i z chaosu nigdy nie wyłania się porządek. Tym jest właśnie, dla mnie, brak jakości.

Zdaję sobie sprawę, że nie każdy się z tymi opisami zgodzi - są ludzie, którzy czują, żepowinno być inaczej, że prawda tkwi w ruchu, w dynamice, że autentyczna jakość może wynikać tylko z ciągłej zmiany. Każdy ma inaczej, ja mam akurat podejście rzemieślnicze. Jakość jest często subiektywna i, tak jak napisałem powyżej, chodzi o "brak rozdźwięku pomiędzy tym, jak jest, a jak być powinno". Każdy ma swoją wizję sytuacji idealnej, ale ten brak rozdźwięku uspokaja umysł - chyba każdy umysł.

Photo by MarkGrundland

Z powyższej subiektywności wynika jeszcze jedna rzecz -- odpowiedzialność za jakość leży też po stronie odbiorcy. Weźmy na przykład moją ignorancję w kwestii spawania. Nie mam o spawaniu zielonego pojęcia. Gdybyście pozwolili mi porównywać dwa spawy godzinami, to pewnie i tak nigdy nie doszedłbym do wniosku, który z nich jest lepszy. Znam za to osobę, która potrafiłaby dokonać takiego porównania w mig. Ja się na tym po prostu nie znam - nie mam pojęcia, jak być powinno. Potrafię ocenić szybko, czy design telefonu czy programu jest dobry, wiem na co zwracać uwagę, wiem czego się spodziewać po dobrym programie... ale na spawaniu, wybaczcie, nie znam się i pewnie nigdy się nie poznam.

Dlaczego o tym wszystkim piszę? Bo my, początkujący programiści, mamy dość często poczucie, że nie jest tak, jak być powinno; że spokój umysłu z nas ulatuje, kiedy zabieramy się do pracy... Dlatego chciałbym zostawić Was z poniższymi pytaniami:

• Czy kiedy zabierasz się do swojej codziennej pracy masz poczucie niepokoju, że coś się zaraz... khem... popsuje?
• Czy korzystając ze swoich codziennych narzędzi pracy masz wrażenie, że je znasz i że wiesz, czego możesz się po nich spodziewać?
• Możesz coś z tym poczuciem robić i uspokoić swój umysł? Robisz to?
• Czy dbasz o jakość?

Nie zawsze mogę szczerze odpowiedzieć "tak" na te wszystkie pytania... ale się staram!

Design of Everyday Things - recenzja

Zwróćcie uwagę na czajnik masochistów...

Do dzieła Donalda A. Normana podchodziłem z pewną rezerwą. Gdyby nie rekomendacja Joela Spolsky'ego, nigdy nie sięgnąłbym po książkę traktującą o projektowaniu rzeczy codziennych. Albo o psychologii, bo na dobrą sprawę nawet tematyka książki nie jest oczywista, ponieważ wcześniej była wydana pod tytułem "Psychology of Everyday Things". Czyli książka o psychologii, projektowaniu drzwi i telefonów, czy może o czymś więcej?

Ta książka jest definitywnie (o) czymś więcej. Chociaż rzeczywiście głównym tematem są przedmioty codzienne: ich wygląd, funkcjonalność i praktyczność, to centrum uwagi przesunięte jest na relacje pomiędzy tymi przedmiotami, a ich użytkownikami. Przecież takie kategorie jak "użyteczność przedmiotu" mogą rodzić się tylko na styku natury ludzkiej i używanego narzędzia. Książka pokazuje jawnie, jak my, ludzie, odnajdujemy się w rzeczywistości - jak nasze mózgi uczą się otaczającego ich świata, na co zwracamy uwagę i jakie błędy popełniamy najczęściej w interakcjach z przedmiotami.

Autor, wieloletni badacz psychologii poznawczej, jest według mnie wyjątkowo wiarygodny w tym co i jak pisze. Myśli zapisane zostały w sposób jasny, obrazowy i logiczny, bez niepotrzebnych dygresji czy nudnych wywodów teoretycznych. Sama książka jest przykładem dobrego projektowania - układ jest czytelny, struktura dobrze przemyślana i konsekwentna. Humor pojawiający się w tekście jest nienachalny i nie odwraca uwagi od sedna problemu.

Co jednak jest najważniejsze, ta książka zmienia życie czytelnika na zawsze. Naprawdę, to nie jest marketingowy slogan - jeżeli przeczytasz tę książkę, Twoje życie ulegnie zauważalnej zmianie. Po przeczytaniu jej, już nigdy nie spojrzysz na otaczające Cię przedmioty w ten sam sposób. Ma to w pewnym sensie wymiar terapeutyczny, bo przestaniesz obwiniać się za to, że nie wiesz jak obsłużyć swoje radio, telewizor czy firmowy ekspres do kawy. Nawet jeżeli natkniesz się na drzwi, których nie będziesz potrafił w pierwszej chwili otworzyć, będziesz widział(a) jasno i wyraźnie, na czym polega problem, a nawet będziesz miał świadomość co należałoby zrobić, żebyś się więcej nie pomylił.

Anegdotka: mój brat wraz ze swoją żoną mają piękną kuchnie - dizajnerską. Wszystko jest w niej ładne, estetyczne, minimalistyczne. Kiedy wszedłem tam po raz pierwszy, bardzo mi się to spodobało - wszystko było takie nieskazitelnie proste i piękne. Kiedy wszedłem tam kolejnym razem, tym razem po szklankę, a nie tylko w ramach zwiedzania, okazało się, że nie potrafię otworzyć żadnej z szafek. Żadnych uchwytów, rączek, klamek - niczego poza płaską powierzchnią drzwi. Dopiero brat musiał przyjść i uświadomić mi, że na drzwi trzeba nacisnąć (oczywiście należy też wiedzieć, po której stronie drzwiczek należy naciskać). Wtedy było mi trochę głupio, przecież to takie proste a ja, inżynier, nie potrafię tego zrozumieć. Dziś widzę to zupełnie inaczej. Kuchnia jest dla ludzi niewprawionych nieużyteczna. Za to wiem, jak można by to poprawić! Przeczytajcie tę książkę, a też będziecie wiedzieć. ;-)

Co jest szczególnie interesujące, autor pokazuje nam pewien wzór, który wyłania się z historii projektowania użytkowego - wzór, który powtarza się zawsze wtedy, kiedy nasza cywilizacja dokonuje wielkiego odkrycia technologicznego. Cykl ten miał miejsce już przy okazji pojawienia się na naszej planecie pierwszych telefonów, samochodów, odbiorników radiowych, a teraz także komputerów. Pierwsze egzemplarze tych urządzeń miały jedną wspólną cechę - były kompletnie nieużyteczne. Potem stopniowo stawały się coraz przyjaźniejsze w użyciu, aż do uzyskania optimum, kiedy absolutnie wszyscy potrafili je obsłużyć ... a co się działo potem? W wyniku konkurencji na rynku, chęci zadowolenia klientów i potrzeby innowacyjności, zaczynał się proces dokładania nowych, lepszych funkcjonalności... urządzenia puchły, stawały się coraz trudniejsze w obsłudze, coraz mniej dla ludzi i kiedy już tylko wąska grupka zapaleńców potrafiła je dobrze obsługiwać, trzeba było znów zacząć od początku. Już się nie mogę doczekać kolejnej generacji smartfonów!

Jest w tej książce zawarty kolejny aspekt terapeutyczny, tym razem skierowany do projektantów - twórców otaczającej nas rzeczywistości. Ta książka pokazuje, że projektowanie jest trudne. Ilość kompromisów i wyborów, które trzeba podjąć projektując zwyczajny kran, drzwi czy telefon jest zaskakująco duża... a liczba ta rośnie dla rzeczy bardziej skomplikowanych. Radia, telewizory, odtwarzacze multi-multimedialne i w końcu programy komputerowe. Tak więc projektowanie zawsze będzie wymagało kilku-kilkunastu podejść, zanim zrobi się to dobrze. Tak zwyczajnie jest, wzorzec się nie zmienia. Dlatego warto sobie czasem odpuścić - robić swoje, najlepiej jak się potrafi i cieszyć się z każdego małego sukcesu, a potem testować i poprawiać, testować i poprawiać, testować i poprawiać... ad mortem defecatum.

Podsumowując: polecam tę książkę każdemu. Jesteśmy otoczeniu oceanem przedmiotów - ta książka jest całkiem przyzwoitą mapą wskazującą bezpieczne przystanie i niebezpieczne rejony.

Jak łatwo ubić pomysł?

Przeczytałem jakiś czas temu podręcznik nowych pracowników Valve i byłem szczerze zachwycony. Polecam lekturę wszystkim chętnym. Wyciągnąłem z tej broszurki sporo przemyśleń, a jedno z nich dotyczyło tego, jak się rodzą projekty. O tym za chwilę, a teraz...

Modele powstawania oprogramowania

Photo by law_keven

Podręczniki i kursy programowania karmią nas modelami powstawania oprogramowania. Jest ich kilka, zazwyczaj nacisk kładzie się na Waterfall i na bazie jego wad i zalet omawia się inne. Kończymy studia, okazuje się że z Waterfall'a nie korzysta prawie nikt i po przeczytaniu paru ogłoszeń o pracę, nerwowo zaczynamy wyszukiwać hasła "scrum", "agile", "extreme programming", itd. Od paru lat na topie jest Agile Development, co dla niektórych oznacza "siadamy i napi***my" (autentyczny cytat). Oczywiście nie na tym polega bycie Agile, ale to już pozostawiam dociekliwym do sprawdzenia.

W końcu dostajemy jakąś pracę i jeżeli trafimy naprawdę dobrze, to okazuje się, że rzeczywiście jest Scrum Master, robimy Sprinty i cały ten jazz, ale... coś nie gra. Model nie przystaje do rzeczywistości, bo dzieją się rzeczy, które do niczego nie pasują. Pewnego wtorkowego poranka okazuje się, że córka siostry Stefana się rozchorowała i nie przyszedł do pracy, a trzeba koniecznie dostarczyć to, co akurat robił. Albo klient dorzucił najważniejsze wymaganie w środku sprintu, które oczywiście musi być dostarczone natychmiast. Wtedy okazuje się, że złotą regułą wszystkich modeli jest "jeżeli klient odpowiednio (do)płaci, to róbcie co każe".

Ja, o dziwo, obecnie pracuję w Waterfallu na sterydach: czystym, pięknym i objętym ogromną biurokracją. Rzeczywistość nadal obowiązuje i nadal dzieją się rzeczy, których nie da się łatwo opisać w kategorii jakiegokolwiek modelu. Nie oznacza to, że model od razu wyrzucamy do kosza. Model zostaje, my robimy to, co trzeba zrobić, a potem... zaczyna się naginanie trupa do trumny. Zdarzało się, że zmiana 3-4 linijek kodu generowała mi zajęcie na cały dzień pracy; bywało i więcej. Wydaje się chore, ale nawet za trzy lata, po chwili szukania, będę w stanie powiedzieć bardzo dokładnie dlaczego zmieniłem te linijki kodu i jakie konsekwencje dla całego projektu miała ta zmiana, a projekt mały nie jest. Nie jestem fanem tego wszystkiego, ale widzę zalety na tym etapie projektu.

Powstawanie oprogramowania

Jest jedna rzecz, której żaden model nie obejmie precyzyjnie, a mianowicie początek projektu. Kiedy program tak naprawdę się rodzi? Zazwyczaj dużo przed napisaniem pierwszej linijki kodu. Najpierw jest mglisty pomysł i pomysłodawca. Jeżeli pomysł wydaje się warty zachodu, to pomysłodawca zaczyna się zastanawiać nad realizacją. Pojawiają się pierwsze detale, wątpliwości - na tym etapie dobrze jest z kimś przedyskutować swoje przemyślenia, najlepiej z paroma osobami. Gdzieś w tych okolicach pojawiają się pierwsze próby implementacji, trochę odbijania się od ścian. Jeżeli do tej pory pomysłodawca się nie zniechęcił, to być może idea będzie już jasna.

Dopiero w tym momencie, kiedy pomysł jest jasny, można myśleć o wciąganiu ludzi do projektu. Dopiero na tym etapie możemy zacząć szukać modelu, według którego będziemy coś robić - kiedy wiemy dokładnie, co chcemy zrobić.

Więc jak ubić pomysł?

- Mam pomysł na fajny program!
- Okej, to przygotuj Project Plan i Cost& Time Assesment i mi podeślij.
- Aha, to ja już nie mam pomysłu

Żaden wykuwający się pomysł nie wytrzyma nakładu pracy, którego wymaga trzymanie się jakiegokolwiek modelu. Kreatywność nie potrzebuje Project Managera. Kreatywność wymaga elastycznego otoczenia, choćby takiego, gdzie biurka mają kółka.

Hello World!

Witam na moim blogu.

Będę pisać o programowaniu, pracy i życiu programisty; o rzeczach które mnie inspirują i o rzeczach, które sprawiają, że mam ochotę sobie podciąć żyły kantem klawiatury i powiesić się na kablu od myszki.

Żartuję, jestem programistą, więc nie używam myszki.

Będę się starał pisać krótko, ale niczego nie mogę obiecać.

Zapraszam do lektury!