Wednesday, December 23, 2009

Tuesday, June 30, 2009

Javarsovia 2009

To już 3cia edycja największej w Polsce (a niektórzy twierdzą, że także w Europie) bezpłatnej konferencji poświęconej technologią z rodziny Java. Javowe święto odbędzie się poraz kolejny na Wydziale Biologii UW.
Tych którzy nie będą świętowali amerykańskiego dnia niepodległości lub bawili się przy dźwiękach festiwalu Open'er gorąco zapraszam na Javarsovie.


Dlaczego tak agituje ? Bo warto, a także dlatego, że w tym roku udało mi się znaleść w szacownym gronie organizatorów. I choć mój wkład w organizację jest niewielki, mogę Wam zagwarantować, że nie będziecie żałować poświęconego czasu.
W tym roku będą trzy równoległe sesje prezentacji oraz jedna sesja warsztatowa. Co ciekawe będziecie mogli posłuchać nie tylko o nowych frameworkach o których zwykle się mówi przy takich okazjach, ale także posłuchać prezentacji pragmatyków. Będzie można usłyszeć o technikach testowania, ciągłej integracji czy programowaniu w środowisku klastrowym. Prelegenci którzy wąchali już niejednokrotnie proch projektowych pól bitwenych odpowiedzą na drążące was pytania.

Miłośnicy nowych technologii będą mogli posłuchać o Androidzie czy witrualizacji. Nie zabraknie także prezentacji bardziej koncepcyjnych a dotyczących takich tematów jak kryptografia czy "cloud computing".


Po konferencji odbędzie się impreza integracyjna na którą zaproszenia będzie można zdobyć podczas Javarsovii. Będzie to kolejna okazja aby porozmawiać z prelegentami czy sponsorami. W końcu znajomości najlepiej zawiera się przy piwie.
Tak więc do zobaczenia na Javarsovii'09!


Wszelkie informacje znajdziecie -> tutaj

Wednesday, May 13, 2009

Produkt "szyty" na miarę...

Metafora


Wiele firm właśnie tak mówi o swoich aplikacjach, idąc tym tropem zacząłem się przyglądać bliżej tej metaforze.
Chcąc być posiadaczem ręcznie uszytego garnituru/sukni klient udaje się do zakładu krawieckiego. Tłumaczy krawcowi jakiego rodzaju ma być to garnitur (ślubny, zwykły etc.). Klient wybiera kolor, fason i fakturę materiału. Krawiec może w tym wyborze pomóc, doradzić, a czasem zasugerować. Następnie mierzy on klienta i przystępuje do pracy.
Po jakimś czasie klient przychodzi na przymiarkę. Sprawdza czy krawiec zastosował się do jego wymagań, a następnie przymierza "wyrób". Krawiec jeżeli to konieczne nanosi poprawki, wykańcza drobiazgi, a następnie dostarcza gotowy produkt.

Analogia


Czytając książki na temat metodyk tworzenia oprogramowania mam wrażenie, że ta metafora jest bardzo prawdziwa. Z jednym małym ale...
Przychodząc do krawca wierzymy, że jest on specjalistą w swojej dziedzinie. Z reguły ufamy jego radą i sugestią, a co najważniejsze pozostawiamy mu szczegóły techniczne. Wybraliśmy tego szewca, a nie innego. Polecił nam go znajomy, który był zadowolony, więc i my powierzamy w jego ręce wykonanie naszego zamówienia.
W świecie tworzenia oprogramowania zaufanie do wykonawcy to towar dość mocno deficytowy. Nie chodzi o zaufanie do firmy jako solidnego partnera w interesach, ale do ludzi tworzących produkt jako fachowców. Klient bardzo często nie mówi jedynie czego oczekuje od produktu i jakie jego potrzeby ma on zaspakajać. Klient często (bardzo często/przeważnie) decyduje o wszystkim od kolorów począwszy, a na układzie formularzy skończywszy. Nie było by w tym nic złego, gdyby klient był ekspertem od danego typu aplikacji, ale najczęściej nie jest.
Właśnie z tego powodu, gdy przychodzimy do krawca nie mówimy mu jakim ściegiem ma szyć, czy w jaki sposób kroić materiał. Wybieramy co prawda fason, ale nie projektujemy każdej kieszeni i kołnierza. Dlaczego ? Bo na tym zna się lepiej krawiec, który uszył już setkę innych garniturów. Ma on dostateczną wiedzę i doświadczenie, więc prawdopodobnie zrobi to lepiej.

Klient ma zawszę rację


Klient najczęściej wie wszystko najlepiej, przecież to on będzie korzystał z tego systemu (być może "do końca życia"). Dlatego specjalista od ubezpieczeń może zaprojektować formularz, a Pani Krysia określić przepływ stron.
Dlaczego klient nie ufa fachowcom ? Dlaczego klient chce wykonywać pracę projektanta ?
Po pierwsze: "Bo może". Czy gdyby producent samochodów poprosił nas o współpracę w tworzeniu nowego modelu. Czy nie kusiło by nas, aby zrobić to auto pod siebie ? Pewnie tak i każdy z nas zrobił by to czysto subiektywnie. Subiektywnie w tym wypadku nie znaczy lepiej. Dla kogoś innego ten produkt może nie być tak intuicyjny i wygodny jak nam się wydaję. Jak często nowy model samochodu/telefonu zaskoczył nas bardzo użyteczną funkcją, której sami byśmy nie wymyślili ? Zaufajmy tym ludziom ! To twórcy dla których jakość ich dzieła jest często nie mniej ważna niż dla klienta.

Po drugie: "Bo to Pani Krysia będzie całe życie kożystała z tego produktu i to dla niej ten system".
Twierdzenie często nieprawdziwe, ponieważ kadra się zmienia, ludzie przychodzą i odchodzą, a produkt zostaje. Co więcej pewne przyzwyczajenia Pani Krysi mogą być niewspółdzielone przez inne osoby (np. nie miały styczności z poprzednim oprogramowaniem używanym w firmie).

Po trzecie: "Bo już mamy taki jeden system i nikt nie umie się nim posługiwać. Dodatkowo jest strasznie nieintuicyjny".
Trzeba sobie postawić pytanie, dlaczego ten system jest taki "zły" ? Czy osoby korzystające z niego zostały należycie przeszkolone ? Jeżeli nie, to lepszym rozwiązaniem jest zorganizowanie szkoleń dla pracowników, zamiast angażowanie ich w "projektowanie" aplikacji. Jeżeli tak, należy zapewnić użytkowników, że podczas fazy analizy ich potrzeby i sposób pracy zostaną dokładnie zgłębione i uwzględnione w projekcie aplikacji. Co więcej można konsultować pewne rozwiązania z "biznesem".

To chyba najpopularniejsze powody dla których klient staje się projektantem. Czasami trzeba po prostu zastanowić się co za nimi stoi i poprzez ich zrozumienie przekonać klienta do zmiany podejścia. Czasami jednak nie mamy wpływu na klienta i wtedy wszystko staje się kwestią zaufania, dlatego apeluje do "klientów" zaufajcie fachowcom (sprawdzajcie, nadzorujcie, audytujcie ale ufajcie...).

Tuesday, May 5, 2009

Broken Window Theory...

Teoria


Nie pamiętam już gdzie ale jakiś czas temu czytałem o "teorii rozbitej szyby". Termin ten kojarzony jest przede wszystkim z Rudolphem Giulianim burmistrzem Nowego Jorku.
Teoria ta w skrócie mówi iż jedna zbita szyba pozostawiona w budynku sprawi że będzie on dalej niszczony w dużo szybszym tempie.
Sam widziałem zastosowanie tej teorii w praktyce widując pozostawione na długie tygodnie/miesiące samochody. Gdy były "całe" nikt ich nie dewastował, wystarczyło że ktoś wybił pierwszą szybę, reflektor (i nikt go nie wymienił,nie zakleił folią szyby), a dewastacja następowała lawinowo z dnia na dzień. Milczące przyzwolenie sprawiało, że ludzie czuli się mniej odpowiedzialni, a odpowiedzialność za zniszczenie samochodu stawała się coraz bardziej rozmyta na wiele osób.


Problem


W wielu projektach w których byłem widziałem rozwiązania mało eleganckie lub wręcz sprzeczne z powszechnie przyjętymi zasadami tego rzemiosła. Gdy po krótkim dochodzeniu udawało się zlokalizować winnego ten tłumaczył się, że zrobił tak samo jak było to rozwiązane w innym miejscu. Na argument, że jest to zrobione w sposób nieprawidłowy, odpowiadał, że jemu też się to rozwiązanie nie podoba, ale przecież w innych miejscach ktoś inny też tak postąpił, więc nie wpłynie to istotnie na jakość projektu. Gdy udało się znaleźć tego kto zapoczątkował złą praktykę okazywało się, że to było rozwiązanie "tymczasowe" i "później" miało być zrobione to lepiej (lub w inny sposób tłumaczone deadline-ami). Bardzo szybko jedna zbita szyba zamieniła się w 2, potem 3 i liczba ta stale rosła. Co więcej wszyscy zaczęli narzekać na wyjątkowo niską jakość projektu, któremu "nic" już nie zaszkodzi, więc wszystkie chwyty stały się dozwolone.


Rozwiązanie ?


Sam muszę przyznać że zdarzało mi się rozwiązywać problem "łatając" coś w sposób brzydki ("skoro wszyscy tak robią"). Ale gdy ktoś zwrócił mi uwagę na pierwszą rozbita przeze mnie szybę zwykle od razu starałem się ją naprawić. Większość programistów, gdy popełnią taki błąd i zostanie im zwrócona uwaga nie jest dumna z tego faktu. Taki "winny developer" stara się jak najszybciej poprawić swój błąd/niedopatrzenie/lenistwo.
Burmistrz Giuliani zwiększył uprawnienia Policji i wypowiedział bezwzględną walkę graficiarzom, a co może zrobić architekt/lead developer/kierownik projektu ?


Myślę, że powołanie "Policji projektowej" nie jest złym pomysłem ;) Być może brzmi to śmiesznie, biurokratycznie i formalnie ale można spojrzeć na to pod innym kontem.
Policjant będzie to rola odpowiedzialna za jakość kodu. Może być nią jedna osoba lub grupa osób, może być to także funkcja "przechodnia". Policjant nie musi całymi dniami przeglądać kodu w poszukiwaniu "zbrodni". Wystarczy, że gdy przypadkiem ją zauważy nie przejdzie obok niej obojętnie. Być może przydało by się miejsce w którym takie fragmenty były by wypisywane (np. bug tracker, tablica korkowa) nawet anonimowo bez dochodzenia kto je popełnił. Osoba mając w danej chwili więcej czasu mogła by je poprawić i zdjąć z tablicy, mógłby zrobić to także sam autor widząc swoje "dzieło" na tablicy. Czy takie rozwiązanie sprawdziło by się w praktyce ? Prawdopodobnie tak, ale pewności nie mam gdyż nigdy nie widziałem jego zastosowania.
Na pewno najlepszą metodą dbania o jakoś kodu jest pisanie kody wysokiej jakości, ale jak sami widzimy różnie z tym bywa. Czasami taki błąd może być źródłem pośpiechu, niezrozumienia danego fragmentu aplikacji czy braku umiejętności. Jak pokazuje praktyka takich sytuacji uniknąć się nie da, ale to nie znaczy, że nie można z nimi walczyć.
Inną metodą przeciwdziałania są rewizje kodu. W takim podejściu każdy kawałek kodu musi zostać zaakceptowany przez innego programistę. Jest to metoda bez wątpienia bardziej skuteczna ale zarazem wymaga poświęcenia większej ilości dodatkowego czasu oraz skutecznego jej egzekwowania (np. za pomocą odpowiednich narzędzi zintegrowanych z repozytorium).

Saturday, January 10, 2009

SpringSource w Warszawie

Przeglądając sobie stronę SpringSource trafiłem na informację, że jeden z kursów z podstaw Springa odbędzie się w Warszawie.
Szkolenie będzie miało miejsce w Warsaw Financial Center, a jego koszt to jedyne 2000 Euro i potrwa 4 dni.

Tutaj znajdziecie link do szkolenia:
http://www.springsource.com/training/spr001/waw-20090310

To chyba pierwsza tego rodzaju wizyta Panów ze SpringSource w Polsce.

PS. Jeżeli ktoś z Was będzie uczestniczył w tym szkoleniu zapraszam do podzielenia się wrażeniami.