Kto płaci za dobry kod?

Oświeciło mnie ostatnio...przynajmniej trochę.
Gdy pracuję z innymi programistami nad tematami związanymi z jakością kodu bardzo często uderza mnie fakt, że pod względem technicznym żadnego z nich nie jestem w stanie nic, ale to nic nowego nauczyć!

Programiści zazwyczaj wiedzą:

• jakie są słabe punkty ich kodu
• jak powinien wyglądać ich kod
• co dokładnie należy zrobić, aby ich kod wyglądał tak jak

Wiedzą to wszystko i...nic się nie dzieje! Nic się nie zmienia. Ciekawe jak to jest możliwe, że mimo tej ogromnej wiedzy, świadomości dobrych rozwiązań, znajomości wzorców projektowych, umiejętności tworzenia czytelnego kodu wciąż jest jak jest - czyli kod woła o pomstę do nieba, a my narzekamy.

Przeprowadziłem małe śledztwo, polegające głownie na zadawaniu pytań i nakłanianiu ludzi do wypełniania ankiet.

Podsumowując: nic się nie dzieje, ponieważ:

• za działający kod płaci każdy, za dobry nikt
• nacisk na jakość kodu powinien iść z góry, od menadżerów; programiści-idealiści w końcu zniechęcają
• długotrwała praca ze kodem o złej jakości, skutkuje tendencją do dopasowywania się do otoczenia; równamy w dół i tworzymy kod, którego jakość jest nie lepsza niż jego otoczenie
• obawiamy się, że radykalne decyzje projektowe okażą się niesłuszne w przyszłości

30 lat z życia programisty

Miałem ostatnio przyjemność pracować z programistami, które swoje pierwsze programy tworzyli korzystając z kart perforowanych lub kodu maszynowego procesora. Tak istnieją jeszcze tacy...

Zastanawiałem się w jaki sposób Ci ludzie utrzymali się w tej branży tak długo, gdzie przecież co chwila jesteśmy świadkami skoków technologicznych, gdzie wciąż trzeba poszerzać swoje umiejętności albo przekwalifikowywać się. Pewnie pomyślicie, że Ci ludzie zachomikowali się gdzieś na wygodnych stanowiskach i dłubią swoje w COBOLu (nawiasem mówiąc stawka programisty COBOLa to $5000/m-c). Otóż nie, jest zupełnie inaczej.

Najczęściej spotykam programistów w wieku do 30 lat z doświadczeniem od 0 do 8 lat. Większość z nich jest absolutnie przekonana, że OOP rulez! Bardzo wielu nie widzi świata poza Javą, .NETem albo C/C++ - w zależności od tego co piszą. Są absolutnymi fanami tego co robią. I dobrze!
Czym zatem różnią się od programistów z 30 letnim stażem? Przede wszystkim tym, że Ci drudzy są absolutnymi fanami pragmatyzmu.Wciąż tworzą rozwiązania, które zaspokajają potrzeby klientów. Dla wielu z nich OOP albo Java to kolejna nowinka technologiczna. Z mojej perspektywy mają oni niemal ponadczasowe spojrzenie na branżę IT.

Gdy tak roztrząsaliśmy wspólnie różne rozwiązania w systemach IT i próbowałem przekonywać ich do moich ulubionych wizji i ulubionych technologii, jeden z nich uśmiechnął się i powiedział wiesz, z tego co obserwuję co 8-10 lat następuje jakiś gwałtowny zwrot w technologii, jakaś nowinka, która zupełnie odmienia sposób w jaki programiści myślą i tworzą; przeszedłem już przez kilka takich zmian, teraz kończy się mniej więcej 8 lat od dżawowego szału i jestem bardzo ciekaw co będzie dalej...

Moi rozmówcy wieszczyli, że zbliża się era języków funkcyjnych, no zobaczymy czy mają rację.

Życzę sobie, abym kiedyś również potrafił patrzyć na swoją pracę i pracę innych z takim dystansem i trzeźwością co programiści z trzydziestoletnim stażem.

Conversation Patterns: Kilka spraw, o których powinien wiedzieć analityk

This article is part of my work on Conversation Patterns for Software Professionals

---

Gdy wchodzisz do firmy jako zewnętrzny analityk, czasem dzieją się dziwne rzeczy...Zebrałem parę punktów, o których warto wiedzieć przed przystąpieniem do pracy. (to luźne, nieposegregowane notatki, więc bez pedantyzmu, pliz ;))

1. Rozpoznaj strukturę organizacyjną - przed spotkaniem warto wiedzieć kto jest kim i za co odpowiada; pozwoli to lepiej ułożyć grafik rozmów
2. Ustal wcześniej grafik spotkań - w większości firm nie można wyciągnać ludzi na rozmowę ot tak sobie, trzeba się najpierw umówić
3. Zawsze ustalaj, czego chcesz się dowiedzieć - bo może się zdarzyć, że po całym dniu spotkań, będziesz przeglądać notatki i zastanawiać się, czego się właściwie dowiedziałeś
4. Trudno wyciągnąć wymagania od osoby nastawionej na różnice - czasem zdarzy się klient, który wymagania formułuje poprzez wyjątki od reguł; baaaardzo trudno ustalić jak właściwie ma działać wspomagający go system, bo w sposobie myślenia klienta większość rzeczy, którymi zajmuje się w pracy nie ma ze sobą nic wspólnego (np.: nastawiony na różnice doradca bankowy "potrzebuje" oddzielnego systemu dla każdego klienta
5. System wciąga - gdy przebywasz więcej niż 1 dzień w firmie klienta, zaczynasz wciągać się w ich problemy; ludzie z którymi się spotykasz bezwiednie próbują umieścić w środowisku, w którym się znajdują, próbują cię zaklasyfikować, nadać jakąś etykietkę, jakąś rolę; np. zaczynają cię traktować jako podwładnego Dyrektora IT; jeśli dasz się wciągnąć w tę grę to po tobie, bo stracisz perspektywę "kogoś z boku"
6. Prowadź spotkanie - bo jeśli ty nie będziesz kierował jego przebiegiem, to na pewno zrobi to ktoś inny; nie osiągniesz wtedy swoich celów
7. Odróżniaj fakty od emocji - Niektórzy ludzie mówią o swoich odczuciach związanych z oprogramowaniem; pamiętaj, że opiniom nie przysługuje atrybut prawdy; jeśli będziesz wystarczająco długo zadawał pytanie po czy konkretnie poznasz, że...? (np.: po czym konkretnie poznasz, że GUI jest ładne), to dojdziesz do użytecznych faktów
8. Bądź wyczulony na relacje międzyludzkie - w każdej grupie ludzi, ktoś kogoś lubi albo nie, ktoś z kimś trzyma albo wojuje, ktoś rządzi, a ktoś słucha; rozpoznając relacje w firmie skuteczniej zidentyfikujesz interesariuszy (osoby, które mają odnieść korzyść z powstania systemu), mocnych interesariuszy (osoby, które mają rzeczywistą moc powiedzieć, że system ma wyglądać i działać tak, a nie inaczej) oraz oponentów (tych, którzy będą negować idę powstania systemu); czasem trafnie rozpoznając relacje międzyludzkie możesz odgadnąć, że właściwie nie masz nic do roboty w tej firmie zanim zapadnie taka decyzja
9. W miarę możliwości porozmawiaj z każdym - jeśli kogoś pominiesz, to mogą przychodzić mu do głowy różne myśli, np.: a może chcą mnie zwolnić?
10. Ludzie mają przyzwyczajenia - i prędzej wyjmą twoje serce łyżką niż z nich zrezygnują; jeśli nowy soft nie będzie podobny do czegoś, co już znają albo widzieli, to nie będą go używać
11. Podczas zbierania wymagań koncentruj się na...zbieraniu wymagań - choć chęć zastanawiania się nad tym jak to zrobić jest bardzo silna; to nie jest jeszcze ten moment
12. Wysyłaj podsumowania po spotkaniu - po pierwsze uporządkujesz wiedzę, po drugie sprawdzisz, czy dobrze zrozumiałeś, po trzecie dostaniesz dodatkowe informacje (a może ktoś coś sobie przypomni?), po czwarte podkreślisz wagę spotkania, po wtóre to jest odbierane jako oznaka profesjonalizmu
13. Rób notatki podsumowujące spotkanie - i to jak najszybciej po jego zakończeniu! wtedy masz spostrzeżenia na gorąco; rewelacyjnie sprawdza się w tym zakresie mind mapping
14. Nie daj się uwieść narzędziom - narzędzia w stylu EA i podobne są pożyteczne jak już dokładnie wiesz czego potrzebuje klient i chcesz to zgrabnie zebrać do kupy; korzystanie z nich na wczesnym etapie (choć twórcy wbudowują zachęcające funkcjonalności) ogranicza i usztywnia kreatywność; zamiast zastanawiać się nad potrzebami klienta, zaczniesz rozgryzać narzędzie (a każde z narzędzi ma inaczej zaprojektowany proces pracy, a tenże proces pracy zupełnie nie pasuje to tego w jaki sposób działają nasz mózgi)
15. Poznaj procesy biznesowe - przed spotkaniami bardzo korzystnie jest poznać specyfikę pracy i procesy biznesowe, które ma wspierać nowe oprogramowanie

http://www.roseindia.net

Bardzo krótki post, bo mam intensywny tydzień:)
Polecam portal http://www.roseindia.net może nie wygląda najlepiej, ale dawno nie widziałem tylu przykładów w jednym miejscu!

P.S. Lektura uzupełniająca Comparing web frameworks